The EDI 864 text message is the escape hatch of retail EDI: free-form notices a retailer cannot send any other way. Compliance warnings and rejection notices arrive here, and most suppliers never read them.
Every other EDI document has a structure, and therefore a system that acts on it. The 864 is free-form text, which means most trading partners receive them into a folder that nobody has opened since implementation. That is fine right up until the message is a compliance warning or a notice that your files are being rejected.
The EDI 864 carries free-form text between trading partners. It exists for communication that does not fit any structured transaction set: notices, warnings, explanations and announcements.
Structurally it is simple. A beginning segment identifies the message and its type, party segments say who it is from and to, and one or more message segments carry the actual text. There is no item, no quantity, no amount. Nothing a system can act on without a human reading it.
That is its whole character, and the reason it behaves differently from every other document on this site. A 850 creates an order. An 820 creates a cash application. An 864 creates nothing, so unless somebody has deliberately built a place for it to land, it lands nowhere.
| EDI error notices | Your file was received but could not be processed for a reason the 997 cannot express. Application level rejections often arrive this way. |
| Compliance warnings | Notice that a shipment, label or document was non-compliant, sometimes before a deduction is raised. Reading this one early is worth actual money. |
| Program announcements | Changes to vendor standards, new requirements, holiday schedules, cutover dates for a new mapping version. |
| Order or shipment queries | Free text questions about a specific purchase order or load where the retailer's system has no structured way to ask. |
| Testing and onboarding notes | During certification, messages about what passed and what needs correcting. |
The failure mode is not technical. Nothing breaks when an 864 is ignored, which is precisely the problem: there is no error, no alert and no missing document to notice. The message simply sits there.
A 997 confirms a file was syntactically valid. It can still fail the retailer's business rules afterwards, and on some accounts that failure is communicated in an 864. Nobody reading it means an invoice that never entered their system and a payment that never arrives.
Where a retailer warns before it charges, the warning is the cheapest thing you will receive all quarter. Missing it converts an avoidable process fix into a deduction and a dispute.
Standards change. A cutover date to a new mapping version announced in an 864 and never read produces a wave of rejections on the day it takes effect, usually blamed on the retailer.
When a dispute turns on whether you were told, an 864 sitting unopened in a raw file directory is not a defensible position, and it is also not evidence you can find quickly.
AIMS360 captures inbound 864s against the trading partner and, where the message references one, against the order it relates to. They appear as items requiring attention rather than as files in a directory, and they are retained so that a question about what a retailer communicated has an answer.
An inbound text message becomes something a person is asked to look at, which is the only handling that works for unstructured content.
Messages are retained per trading partner, so onboarding notes and compliance warnings stay findable.
Every inbound and outbound document is retained, which matters when a dispute turns on whether you were notified.
AIMS360 charges no per document or per kilocharacter fees of its own, so capturing low value traffic costs nothing.
It carries free-form text between trading partners for communication that does not fit a structured transaction set. In retail that usually means EDI error notices, compliance warnings, program announcements, questions about a specific order, and messages during onboarding and certification. There is no item, quantity or amount in it, so nothing can act on it automatically.
No. The 997 is a structured technical acknowledgment reporting whether a file was syntactically valid. The 864 is free text a human wrote or a system generated in prose. Where they overlap is application level failures: a file can pass the 997 and still fail the retailer's business rules afterwards, and on some accounts that is communicated in an 864.
Usage is inconsistent. Some use it heavily and expect suppliers to act on it, many never send one, and some send them only during onboarding and certification. It is worth asking during setup whether an account uses it, because finding out two years later usually means finding an inbox with something important in it.
The standard allows it, and some partners accept one. In practice most retail communication from a supplier goes through a vendor portal, an EDI support address or a buyer, so outbound 864 usage is rare. If you have something to tell a retailer, check what channel they expect rather than assuming a text message will be read.
Route them to a person, not a folder. Because they carry no structured data, no automation will act on them, so the only handling that works is surfacing each one as something requiring attention and retaining it against the trading partner. If your current answer is that they land in a directory nobody opens, that is the same as not receiving them, except that the retailer believes you were told.
Last reviewed 7 August 2026 by the AIMS360 EDI team. The 864 carries unstructured text, so what a given retailer sends in one varies entirely by account and can change. Confirm whether your trading partners use it during onboarding.
See AIMS360 surface trading partner messages against the account and the order, in a 30 minute demo.
