The EDI 864 text message is a standardized ASC X12 document that carries free-form, human-readable text between trading partners. It travels on the same electronic channels as purchase orders and invoices, but its contents are meant to be read by a person, not parsed by a computer. The X12 standard describes its intent as providing “electronic communication (messages) for people, not for computer processing.”1Defense Logistics Agency. DLA BSM 864 IC
Why the 864 Exists
Most EDI transaction sets are rigid by design. A purchase order has fields for item numbers, quantities, and prices; an invoice has fields for line totals and tax. When something needs to be communicated that doesn’t fit those slots, companies have historically fallen back to email or phone calls. The problem is that those conversations live outside the EDI audit trail.
The 864 solves that. It gives trading partners a container for plain-language explanations, alerts, and instructions that stays inside the same system logging every order and shipment. The result is a time-stamped record tied to the broader trade relationship. During audits or disputes, retrieving the exact wording of a notification sent three years ago can resolve a disagreement before it escalates.
No automated data update fires when an 864 arrives. The receiving system stores the message and a person reads it.
How an 864 Is Structured
Every 864 is built from a small set of data segments. Not every implementation uses every segment, and trading partners define which ones are mandatory in their own implementation guides, so the layout in one supply chain may differ from another. The core segments are:
- BMG (Beginning Segment for Text Message) opens the transaction and carries a purpose code identifying whether the message is an original transmission, a replacement, or something else. Purpose code “00” signals an original message.1Defense Logistics Agency. DLA BSM 864 IC
- DTM (Date/Time Reference) records when the message was created. Some implementations mark this segment as mandatory; others skip it entirely.2Wakefern Food Corp. EDI Reference Guide 864 Text Message
- N1 (Name) identifies the parties involved using standardized entity codes, such as “VN” for vendor or “FR” for the sender.2Wakefern Food Corp. EDI Reference Guide 864 Text Message
- MIT (Message Identification) marks the beginning of an individual message block and assigns it a unique reference number. A single 864 can contain multiple MIT loops, each with its own subject. In some implementations the MIT reference ties directly to a document like a vendor invoice number.2Wakefern Food Corp. EDI Reference Guide 864 Text Message
- MSG (Message Text) is where the free-form text actually lives. Each MSG segment holds up to 264 characters, and the segment can repeat up to 100,000 times within a single transaction.1Defense Logistics Agency. DLA BSM 864 IC
The 264-character limit per MSG line catches people off guard. Long explanations aren’t typed into a single field. Translation software splits the text across multiple MSG segments, and the receiving system reassembles the block for display. The standard allows enough repetitions that message length is almost never a practical constraint.
When Companies Send One
The 864 shows up wherever a structured transaction set can’t carry the nuance a situation demands. A few patterns come up repeatedly.
Purchase order exceptions are a common trigger. When an automated system flags errors in an order but can’t resolve them, a buyer sends an 864 with a narrative explanation so the vendor understands exactly what went wrong before resubmitting.
Invoice rejections work the same way. Some trading partners use the 864 to communicate why an invoice was rejected, with the specific invoice number and the error description carried in the MIT and MSG segments.2Wakefern Food Corp. EDI Reference Guide 864 Text Message In practice, the 864 often accompanies another document: a rejected invoice triggers both an automated rejection response and an 864 that explains the reason in plain language.
Policy and contract updates also travel well through this channel. A company can formally notify a partner about a new shipping location, a revised return policy, or an upcoming price change. Sending the notice through EDI creates a defensible record rather than relying on a phone call nobody documented.
Operational alerts round out the list: warehouse closures, holiday schedules, system maintenance windows, and similar notices that affect the timing of other transactions.
The common thread is information that matters enough to put on the record but doesn’t warrant its own transaction set.
How It Moves and Gets Acknowledged
An 864 file travels the same way as any other EDI document. Three transmission methods are common.
A Value Added Network, or VAN, acts as a clearinghouse. It routes documents between partners regardless of what protocol each partner uses internally. You configure your data mapping once and the VAN handles the routing. Pricing varies widely and can be per-kilocharacter, a flat subscription per trading partner, or a custom arrangement.
AS2 (Applicability Statement 2) is a direct, encrypted connection between two systems using digital certificates. It provides non-repudiation through Message Disposition Notifications, meaning both sides receive cryptographic proof that the file was sent and received. AS2 is the standard in retail and healthcare.
SFTP (Secure File Transfer Protocol) is a batch-oriented approach over an encrypted SSH channel. It’s simpler to configure than AS2 but lacks built-in delivery receipts, so you rely on your own logging to confirm transmission.
Once the receiving system ingests an 864 and validates the segment structure, it typically generates an EDI 997 Functional Acknowledgment in return.3IBM Documentation. 997 – Functional Acknowledgment The 997 is a receipt confirming that the file arrived intact and passed the translator’s formatting checks. It does not mean anyone has read the message. It only proves that the data made it through the door without structural errors. Companies keep these acknowledgments for years because they serve as evidence that a communication was delivered.
What You Need Before Sending One
Trading Partner Agreement
Before exchanging any EDI documents, both parties sign a Trading Partner Agreement. The contract spells out which transaction sets will be used, the technical standards both sides follow, and the legal weight of the electronic communications.4U.S. Department of Agriculture. Basic Trading Partner Agreement It also defines mapping requirements, telling each company’s translation software exactly how to structure the BMG, MIT, MSG, and other segments for that specific relationship. If your partner’s implementation guide treats DTM as mandatory and yours treats it as optional, the agreement is where that gets reconciled.
Translation Software and Mapping
Your EDI translation software converts outbound messages into X12 format and converts inbound files back into something your internal systems can display. The mapping configuration is partner-specific. Each partner may use different segments, require different codes, or expect the MIT reference to contain a particular document number. Mapping errors are the most common source of rejected transmissions, so expect testing time with each new partner before going live.
Access to the X12 Standards
The official X12 implementation guides that define the syntax rules for the 864 are available through X12’s licensing program. Access is not free. A Licensed User subscription runs $180 per year, a Development License costs $1,200 per year, and an Internal Use Partner license is $3,600 per year.5X12. Licensing Program Commercial Use pricing is negotiated individually. Many companies work from their trading partner’s implementation guide rather than purchasing the full standard, since the partner guide narrows the spec to the segments and codes relevant to that relationship.
The Catch With Free-Form Text
The MSG segment’s flexibility is also its biggest weakness. Because the field accepts any text up to 264 characters per line with virtually unlimited repetitions, nothing in the format stops someone from typing a Social Security number, a bank account, or other sensitive information into the message body. Structured transaction sets constrain what data goes where. The 864 has no such guardrails.
Organizations handling protected health information, financial records, or consumer data should set clear internal policies about what can and cannot appear in an 864. Encryption in transit, which both AS2 and SFTP provide, protects the data on the wire. It doesn’t help if the message is stored unencrypted in an EDI archive. Role-based access controls on your EDI system limit who can view incoming 864 messages, and that layer matters more here than it does for a routine purchase order where the data fields are predictable.
The broader point is that the 864’s free-form nature shifts compliance responsibility from the system to the user. Typing sensitive details into an EDI text message creates the same regulatory exposure as putting those details in an email, and the usual data-handling rules for HIPAA and state privacy laws still apply.
Retention and Evidentiary Value
EDI 864 messages and their corresponding 997 acknowledgments should be retained under your organization’s broader document retention policy. In regulated industries, those retention periods are often defined by law. Even outside regulated sectors, keeping several years of 864 records is standard practice because the messages serve as evidence that a communication occurred on a specific date.
If a dispute reaches litigation, EDI records generally face the same admissibility hurdles as any other electronic evidence. The records need to be authenticated as genuine, relevant to the matter, and either non-hearsay or covered by an exception such as the business records rule. Time stamps, segment structure, and 997 acknowledgments all help establish authenticity. Companies with clean EDI archives and intact audit trails are in a stronger position than those reconstructing communication histories from scattered emails and phone logs.