EDI 864 Text Message: BMG, MIT, MSG and MTX Segments

An EDI 864 text message is the X12 transaction trading partners use to send free-form text: an exception notice, an allocation cut, a policy change, a note that fits no coded document. Unlike a 997 or an 824 it carries no status field a program can branch on. The verdict lives in prose inside MSG or MTX segments, BMG03 is optional, and MIT01 is only a message number. That is why 864s are received, acknowledged with a clean 997, and never read by anybody.

Last updated September 2026

Every EDI integration has a folder like this. Files land in it, the translator writes a row in a log, a 997 goes back within the hour, and no human being has opened it since the trading partner went live. Usually it is the 864 folder. The partner on the other end believes they told you the item was discontinued, the allocation was cut, or the receiving hours changed for the holiday. On paper they did. The message is sitting in the folder in plain English, in a document format designed to be printed on a line printer in 1985.

This is a reference for the segments, the elements and the code lists in an 864, and for the specific reasons this transaction set behaves differently from every other document in your EDI flow.

What an EDI 864 actually contains

The 864 is one of the smallest transaction sets in X12. There are six segment types you will realistically encounter, and only three of them are mandatory.

The MIT loop is mandatory and it must contain at least one MSG or MTX segment. That is the only content rule the standard imposes. Everything about what the message means, who should act on it and by when is left to prose.

The BMG header, and why BMG03 will not route your messages

BMG is the beginning segment for a text message. It has three elements and people reasonably assume the third one lets them classify inbound 864s automatically. It does not, and the reason is worth understanding before you build anything on top of it.

BMG01 uses element 353, the same generic purpose code list used across X12, and it has 74 values. On an 864 you will mostly see a handful of them.

BMG03 is where the classification would have to live, and it uses element 755, the report type code. That list runs to more than 500 values covering everything from bills of lading to autopsy reports to voter registration applications. There is no subset of it that means supplier exception notice or delivery schedule change. In practice partners either leave BMG03 empty or pick a value that made sense to whoever wrote their implementation guide, which means two partners sending you the same kind of notice will not agree on the code. Any routing rule built on BMG03 is a rule that works for exactly one trading partner.

MIT, and the two fields that give the 864 away

MIT is the message identification segment. It opens the detail loop and it holds the message number and subject line, plus two fields that tell you a great deal about when this transaction set was designed.

MIT03 and MIT04 default to 80 characters wide and 66 lines long. That is a sheet of continuous stationery on a line printer. The 864 was not designed to be parsed, filtered or routed. It was designed to be printed and handed to somebody, and the standard says so through its own field defaults. Once you accept that, the integration problem stops being how do I parse this and becomes how do I get it in front of the right person, which is a different and much more solvable problem.

MIT01 is the one element worth indexing. It is the message number, and it is what a purpose code of 05 Replace or 07 Duplicate refers back to. Store it and you can deduplicate and supersede correctly. Ignore it and a partner who resends a notice three times has told you three different things.

MSG and MTX: where the text lives, and the 264 character trap

The message body sits in MSG or MTX segments. MSG is the older of the two and it is the one most partners still use.

MSG01 caps at 264 characters. A message longer than that gets split across several MSG segments, and there is no field that numbers them or tells you how many to expect. Sequence is positional: the segments are in order in the file and that order is the message. A parser that reads the first MSG in the loop and stops, which is a very common shortcut when someone assumes one message equals one segment, silently truncates the notice at 264 characters. The half that mattered is usually in the second segment, because the first one is the greeting and the reference numbers.

MTX exists for exactly this reason and the standard describes it as preferred when a large quantity of text is being sent. Not every partner has moved to it. Handle both, and concatenate every segment in the loop rather than taking the first.

All 7 MSG02 printer carriage control codes

MSG02 uses X12 element 934 and it controls the line feed of the receiving printer. There are seven values and they are the clearest surviving evidence of what this document was for.

Two rules go with it. MSG03 can only be present when MSG02 is present, and when MSG02 is AA the number of lines in MSG03 becomes required. If you are rendering an 864 into a readable form rather than printing it, LC is the code that matters most: it means this segment continues the previous line rather than starting a new one, so joining every segment with a newline mangles the layout the sender intended.

Why a clean 997 on an 864 tells you nothing

This is the failure that makes the 864 worth writing about at all. The acknowledgment chain looks complete and it is not.

An AK901 of A on the 997 answering an 864 means the segments parsed. It is the same misreading as treating a clean functional acknowledgment on a purchase order as a business confirmation, which our reference on EDI 997 error codes covers in detail. With an 850 the misreading is at least recoverable, because the order eventually turns into a shipment or an obvious silence. With an 864 there is no downstream event at all. Nothing ever happens as a result of an unread 864, which is precisely why nobody notices.

There is also no 864 equivalent of the 824 application advice. An 824 exists to say the receiving application looked at your content and had an opinion about it. No application forms an opinion about a paragraph of English. If a partner needs a structured answer they have to ask for a different document.

What partners actually send in an 864

The categories below cover most real 864 traffic. None of them are distinguishable from each other without reading the text.

The price and terms category is the one most worth a control. A supplier notice that moves a committed cost arrives here as prose weeks before it appears on an invoice, and the gap between the notice and the invoice is the only window in which anybody can act on it. Treating those notices as something to catch against the budget when they happen rather than at month end is the difference between a negotiation and a variance report.

Reading an 864 from the outside in

The file below is a short exception notice from a supplier. Read it in the order the segments make sense, not top to bottom.

ST*864*0001~
BMG*00*Allocation notice*ZZ~
DTM*007*20260901~
N1*FR*NORTHFIELD SUPPLY CO*92*NSC001~
MIT*MSG-2026-0912*Q4 allocation on part 44-8820*80*66~
MSG*Effective 15 September 2026 part 44-8820 moves to allocation.~
MSG*Open orders will ship at 70 percent of confirmed quantity until further notice.~
MSG*Substitute part 44-8825 is available at the same price and is not allocated.~
SE*9*0001~

BMG01 first. It is 00, so this is an original message rather than a replacement or a duplicate. BMG03 is ZZ, mutually defined, which is the value partners fall back on when nothing in element 755 fits. It tells you nothing, which is the normal case.

MIT01 next. MSG-2026-0912 is the handle. If a follow-up arrives with BMG01 of 05 and the same MIT01, it replaces this message and not some other one.

Then MIT02. The subject line is the only field in the whole document you can realistically use for triage, and it is optional. When a partner populates it, index it.

Then every MSG in order. Three segments here, and the commercially important sentence is in the second one. A parser that took only the first MSG would have recorded that a part moved to allocation and missed that open orders are about to ship 30 percent short. That is not a hypothetical failure mode. It is the default behaviour of code written by somebody who assumed one message was one segment.

Making an 864 channel usable

You cannot automate a judgment on prose, but you can stop the prose from disappearing. Four things work.

Route by sender and subject, not by report type code. N1 with a qualifier of FR gives you who sent it and MIT02 gives you the subject when populated. Those two fields decide who should read it far more reliably than BMG03 ever will.

Concatenate every MSG and MTX segment in the loop. Respect LC in MSG02 so continued lines join rather than break. Never take the first segment and stop.

Alert on arrival, not on a schedule. An 864 has no due date field and no response document, so there is no system anywhere that will chase it. If nothing notifies a person when one lands, nothing will.

Keep MIT01 and BMG01 together in your index. That pair is what lets you tell an original from a duplicate from a replacement, which is the only structured logic the document actually supports.

What is the difference between EDI 864 and EDI 824?

An 824 application advice reports a machine verdict on a document you sent, using coded values in OTI01 and structured error detail in TED segments. An 864 text message carries human prose with no verdict field at all. An 824 answers a specific transaction; an 864 usually is not answering anything, it is announcing something. Automated handling is realistic for an 824 and is not for an 864.

Is an EDI 864 machine readable?

Only its envelope is. ST, BMG, MIT and the party segments parse into fields like any X12 document, so a translator will validate an 864 and acknowledge it without difficulty. The content is different: MSG and MTX hold unstructured text with no schema, so nothing downstream can decide what the message means or what to do about it. An 864 is machine deliverable and human readable, which is not the same thing as machine readable.

Do I have to respond to an EDI 864?

Almost always no. Most trading partner agreements require only a 997 functional acknowledgment, which your translator sends automatically. There is no standard business response document for an 864 in the way an 855 answers an 850. If a partner needs an answer they normally ask for it in the text and expect an email or a phone call, which is one more reason an unread 864 goes unnoticed on both sides.

How many segments are in an EDI 864?

A minimal valid 864 has four: ST, BMG, MIT and SE, plus at least one MSG or MTX inside the MIT loop, so five in practice. Real files usually add DTM for the effective date and one or more N1 loops for the parties. The MIT loop can repeat, so one 864 can carry several separate messages, each with its own number and subject.

Where the 864 sits in a working EDI flow

The 864 is the channel of last resort, and it is used most heavily by partners whose business reality does not fit the coded documents they have available. That makes it disproportionately valuable per message and disproportionately likely to be ignored. It is worth handling for the same reason it is worth reconciling the shipping documents nobody automated: the exceptions are where the money is.

If you are working through the surrounding transaction sets, the EDI 850 to Excel converter covers the purchase order itself, the EDI 940 to Excel converter covers warehouse shipping orders and the 945 advice that answers them, and the EDI to Excel converter guide covers the envelope and delimiter rules that apply to every file including this one. For the exception traffic that never arrives as EDI at all, which for most desks is the larger half, our purchase order PDF to Excel converter turns the documents partners email into the same columns your EDI feed already writes.