What Is EDI 864 and When Do You Need It?
Learn what EDI 864 does, when retailers require it over email, and how it differs from EDI 997 and 824 acknowledgments.
EDI 864 is the X12 "Text Message" transaction set: a document designed to replace an email, fax, or phone call, but delivered through the same AS2 or VAN channel as your structured EDI traffic. Retailers and 3PLs use it for invoice disputes, compliance notices, and announcements that don't fit a purchase order, invoice, or ASN format. Unlike an 850 or 856, nothing inside it is meant for a parser.
That's the part people miss. An 864 carries message date and time, sender and receiver identification, and free-form message text inside segments like BMG, DTM, N1, and MSG, and that's intentional. The whole point of the transaction set is to hand a human-readable note to a person, while still keeping it inside an auditable EDI exchange.
Is EDI 864 the Same as Sending an Email?
Functionally, yes. Structurally, no. The content looks like something you'd put in an email, but it travels through the same audited, logged channel as your 850s and 856s instead of a mail server that nobody archives for compliance purposes.
That distinction is why some trading partners mandate it. Wakefern's ShopRite EDI spec puts it bluntly: when a live invoice fails data content validation, the trading partner must accept and acknowledge the 864 Text Message in order to be moved into production. Wakefern also warns that receiving a 997 from them doesn't mean the invoice was accepted by their reconciliation application, only the 864 confirms that. If you've ever had a supplier insist an invoice "went through" because they saw a functional acknowledgment, this is exactly the gap that causes the argument. An email thread doesn't get logged against your EDI control numbers. An 864 does, and that matters when a dispute ends up in front of an auditor or a deduction appeal six months later.
How Does EDI 864 Differ From EDI 997 and 824?
The 997 confirms a transmission arrived and parsed correctly. The 824 reports business-level errors in structured data fields. The 864 is the only one of the three actually meant to be read by a person rather than processed by a system.
Each sits at a different layer:
| Transaction | What it confirms | Who reads it | Format |
|---|---|---|---|
| 997 | Whether the interchange or transaction set was received and accepted, or rejected with error details | EDI translator / integration system | Fully structured, coded |
| 824 | Whether a document is accepted or rejected by a processing system such as Accounts Payable, with segment/element-level error detail | ERP or AP automation, sometimes a human reviewing error codes | Structured, with coded reason fields |
| 864 | Nothing programmatically; it's a note, not a verdict | A person on the supplier or retailer side | Free-form text, unstructured |
Here's where it gets concrete. An 824 can tell a supplier that invoice line 14 has a quantity mismatch, using a coded data segment note. It can't tell them, in plain language, that the pricing team flagged a contract violation and needs a call before resubmission. That's an 864 job. Wakefern's spec actually files its 864 under invoice rejection with a transaction purpose code of 44 (Rejection) and a BMG02 description of "REJECTED_INVC", paired with free-text MSG segments explaining the specific violation. It's an 824-shaped problem wrapped in 864-shaped delivery, because the retailer wants a person reading it, not just a system logging an error code.
Do Major Retailers Like Walmart or Target Require EDI 864?
Yes. Walmart lists 864 among its supported transaction codes alongside 850, 856, 990, and 997, and Target maintains a dedicated 864 implementation guide covering both its Retail and Drop Ship programs through its EDI portal.
Target's guide follows the same skeleton most retailers use: a required BMG segment to open the message, an N1 loop to identify sender and receiver, and an MIT loop with a Message Identification segment and up to 100,000 MSG lines for free text. That upper bound on MSG occurrences tells you something: these aren't meant to be short. Retailers use them for genuinely detailed rejection explanations, not a one-line "call us" note.
The operational mistake is treating an inbound 864 like any other EDI document, routing it straight into the ERP queue where nobody looks at it until a deduction shows up on the remittance. If a partner spec requires 864 for compliance notices or invoice rejections, that message needs to land in front of an actual AP or EDI analyst, not sit in a mapping log.
Can an EDI 864 Trigger Downstream Automation?
Technically, yes. In practice, you shouldn't build logic around it. X12's own transaction set definition is explicit that the 864 exists to provide electronic communication for people, not for computer processing, and that using it to transmit quasi-standard data is discouraged.
The temptation is obvious. You get a flood of 864s with a consistent pattern, "INVOICE ERRORS... VIOLATION(S) OF THE MAPPING SPECIFICATIONS," and someone on the integration team writes a keyword parser to auto-flag them. That works until the retailer tweaks their wording, reorders the MSG lines, or a different DC template gets used, and now your parser silently misses half the rejections. Free text isn't versioned the way a segment schema is. There's no implementation guide enforcing exact phrasing, so there's nothing stable to parse against long-term.
This is the right place to draw a line between what the 864 is for and what belongs in structured transport data. When dispatchers or carriers need real-time exception visibility, tender status, delivery delays, appointment changes, that data should come through structured transactions like the 214 or 990, fed into a TMS rather than scraped out of free text. Platforms like Cargoson, MercuryGate, Transporeon, and Descartes all handle that structured side of exception visibility, and it's a more durable integration point than reverse-engineering retailer prose.
Is EDI 864 Still Used in 2026, or Has It Been Replaced?
Still active, and not close to retired. Grocery networks, general merchandise retailers, and pharma trading partners continue to require it specifically because it stays inside the audited EDI channel, something a Slack message or portal upload doesn't guarantee the same way.
Major EDI providers keep documenting and supporting it for exactly this reason. SPS Commerce describes it as the channel for announcements, explanations, and administrative instructions between trading partners, while Cleo and TrueCommerce both maintain dedicated implementation references for it. If a vendor's EDI reference guide still lists 864 in 2026, it's not legacy cruft, it's an active compliance requirement on their side.
How Do You Structure a Compliant EDI 864 Message?
A minimum viable 864 needs an ST header, a BMG segment stating transaction purpose, optional DTM for date/time, an N1 loop identifying sender and receiver, and one or more MSG segments carrying the actual text.
- ST: transaction set header with the 864 identifier and control number
- BMG: purpose code (common values include Notification and Rejection) plus a short description field
- DTM: date/time reference, often tied to the invoice or document being referenced
- N1 loop: identifies the message sender ("FR") and recipient ("TO"), sometimes by GLN
- MIT loop (where required, as in Target's and Wakefern's specs): message identification tied to the original document number
- MSG: the free-form text itself, repeatable across as many lines as needed
Before you send one, check whether a structured code already fits. If you're reporting a syntax failure, that's a 997's job. If you're flagging a specific data element violation like a mismatched price or invalid UPC, that's what the 824 exists for. Reach for the 864 when the message genuinely needs a sentence a person can read, not a code a system can route. Pull up your partner's actual implementation guide, Target's and Wakefern's are both publicly posted, before you assume your existing 864 template will pass their validation the first time.
