EDI 824 Application Advice: OTI01 Codes and TED Errors

An EDI 824 application advice reports whether the receiving business application accepted, changed or rejected the content of a document you sent. It is the layer above the 997: a 997 says the file parsed, an 824 says the order, invoice or ship notice inside it was usable. OTI01 carries the verdict, from TA for transaction set accept through TR for transaction set reject, and the TED segments underneath list what went wrong and where. An 824 saying IC means your data was accepted after the receiver changed it, which is the quietest outcome in the whole exchange.

Last updated August 2026

Most EDI monitoring stops at the 997. That is understandable, because the 997 comes back fast and it is the one every trading partner agreement requires. It is also the reason orders vanish. A functional acknowledgment reports on syntax and nothing else, so a file can pass it cleanly and then be thrown out by the application that receives it because the purchase order number does not exist, the item is not on the order, or the ship to location was never set up. The 824 is the document that tells you that happened, and it is the one most teams either do not receive or do not parse.

What an 824 tells you that a 997 does not

The two documents answer different questions and they can disagree. Understanding the split is the whole reason the 824 exists.

The sequence that matters is this. You send an 850. A 997 comes back with AK901 of A, so you mark it delivered. Six hours later the receiver runs the job that loads orders and finds the buyer part number does not exist in their item master. If your partner sends an 824, you learn that. If they do not, the only signal is that nothing ships, and you find out from a phone call three days later. Our reference on EDI 997 error codes covers the syntax layer in full, including why an AK901 of A is not a business confirmation.

The segments in an 824 and what each one reports

An 824 is a small document. The whole thing is a header, a party identification, then a repeating loop of one OTI per document being acknowledged with TED segments underneath it.

The important structural point is that TED sits inside the OTI loop. A TED without an OTI above it is meaningless, and an OTI with no TED underneath is usually a clean accept. That relationship is what tells you which error belongs to which document when a single 824 acknowledges twenty of them at once.

OTI01 application acknowledgment codes

OTI01 is X12 element 110 and it is mandatory. There are 22 values in the standard and they are organized in four families by the granularity of what is being judged: batch, functional group, transaction set and item. Within each family the suffix letter carries the same meaning.

Reading the suffix is faster than memorizing 22 codes. A means a clean accept. C means accepted after the receiver changed your data. E means accepted with errors recorded. P means part of it went through and part did not. R means rejected. H means neither, it is sitting waiting for a human.

Two of those deserve more attention than they usually get.

The C codes are the dangerous ones. TC, IC, GC and BC all say the receiver accepted your document after changing its data content. Nothing failed, no alert fires, and the document is now different in their system from what it is in yours. A price you sent as 12.50 might be stored as the contract price of 11.80. The TED segments underneath usually say what was changed, and they are the only record you will ever get of it. If your integration ignores accepts, you will never see this and your invoice will not match their receipt.

The H codes are neither pass nor fail. TH and GH mean the document is on hold, typically pending a credit check, an approval or a manual review. A monitor built as a two state accept or reject switch treats a hold as an accept, so the order sits in someone else's queue indefinitely and your side shows it as confirmed.

Why the granularity of OTI01 changes what you should do

The same underlying problem can be reported at four different levels depending on how the partner built their advice, and each level implies a different response.

The item level is where most of the real damage happens. When a partner sends IA for eight lines and IR for two, the order exists on their side with eight lines. Resending the corrected full order then creates either a duplicate or a rejection for duplicate purchase order number, which is TED code 111. The correct response is almost always a change document rather than a resend, which for a purchase order means an EDI 860 purchase order change rather than another 850.

The TED segment: where the fault actually is

TED is the technical error description and it is the part of the 824 that earns the document its keep. Its job is to identify the error and, where possible, the exact segment and element that caused it.

TED07 and TED08 together are the most useful pair in the segment and the most commonly ignored. TED07 echoes back the value that failed, so you do not have to guess which of forty lines carried the bad part number. TED08 carries the replacement, which on a TC or IC accept with data content change is the only place the receiver records what they overwrote.

Most teams read only TED02, the free form message, because it is the human readable one. TED02 is optional. Plenty of partners never populate it, and an integration that logs TED02 and drops the rest will show you a wall of blank error messages.

TED01 application error condition codes, and why there is no universal list

TED01 is X12 element 647 and it has well over two hundred values. That is because the same element is used across industries that have nothing in common, so the code list is really several unrelated lists sharing one element number. This is the single biggest practical difference between reading a 997 and reading an 824.

The consequence is concrete: do not build one global TED01 lookup table and reuse it across partners. Scope the translation to the trading partner and the transaction set. A retail partner sending 133 means the item is not on the purchase order. A financial partner sending 824 in TED01 means a payment passed credit approval, which is not an error at all. Those are different code lists that happen to occupy the same element.

The codes that matter most for purchase order flows are the retail block and the alphabetic block. If you are only going to translate a dozen values, translate 108, 111, 133, 136, 138, 141, MB, ME, MG, POI, IQT and UNP. Between them they cover most real order rejections.

How to read a rejected 824 in the right order

Work from the OTI outward, exactly the way you work from AK9 outward on a 997. The advice below acknowledges one purchase order that was partly loaded.

ST*824*0001~
BGN*11*ADV20260831*20260831*1432~
N1*FR*ACME DISTRIBUTION*92*AC1042~
OTI*TP*PO*PO-88471*ACMEDIST*BUYERCO*20260830**000000123*0002*850*004010~
TED*133*ITEM NOT ON ORDER*PO1*7*7*234*8846-BLK~
TED*IQT**PO1*9*2*380*0~
SE*7*0001~

Read it in this order:

OTI01 first. TP means transaction set partial accept or reject. Part of this purchase order loaded and part did not. A monitor watching only for TR would have marked this document successful.

OTI02 and OTI03 next. The qualifier is PO and the value is PO-88471, so this advice is about that purchase order number. Read the qualifier, never just the value. The same position carries an invoice number when the qualifier is IV and a shipment identifier when it is SI, and the qualifier is the only thing that tells you which.

OTI08 through OTI11 next. Group control number 000000123, transaction set control number 0002, transaction set 850, version 004010. That is the GS06 and ST02 you sent, and it is how you find the exact original document rather than the right PO number from the wrong day.

TED segments last, one at a time. The first has TED01 of 133, item not found on purchase order, in segment PO1 at position 7, element 7, which is element 234, product or service ID, and TED07 echoes back the value 8846-BLK. That line was rejected because the part number is not one the receiver recognizes. The second has TED01 of IQT, invalid quantity, in the PO1 at position 9, element 2, element 380, and the offending value was 0. Someone sent a line with a zero quantity.

Then decide the response. Because OTI01 was TP and not TR, eight of the ten lines are now live on the receiver's system. Resending the corrected 850 would produce a duplicate purchase order number rejection, TED code 111. The right move is an 860 change document adding the two corrected lines.

What is the difference between an EDI 824 and an EDI 997?

A 997 confirms that a file was syntactically valid X12 and was received by the translator. An 824 confirms whether the business application could actually use the content. A document can pass the 997 and still be rejected by the 824, which happens whenever the file is well formed but refers to a purchase order, item or location that does not exist on the receiving side. They are complementary, not alternatives.

Does an EDI 824 always mean something was rejected?

No. An 824 is an application advice, not an error report, and OTI01 can carry an accept just as easily as a reject. TA, IA, GA and BA are all clean accepts. Many partners only send an 824 when something went wrong, but the standard does not require that, and some send one for every document as a positive confirmation that the order loaded.

Is an EDI 824 required?

It is required only when your trading partner agreement says so, which is much less often than for a 997. That is precisely why it is worth asking for. If a partner will send one, you get application level confirmation instead of inferring it from silence. If they will not, you need your own control: a report of documents acknowledged by a 997 that never produced a downstream event such as an 855, an 810 or a receipt.

What does OTI mean in EDI?

OTI stands for original transaction identification. It is the segment in an 824 that both delivers the verdict and points back at the document being judged, using the group control number, the transaction set control number, the transaction set identifier and the version. Without OTI you would know something failed but not which of the fifty documents you sent that morning it was.

Can an 824 acknowledge an invoice or a ship notice?

Yes. The 824 is deliberately generic and OTI10 carries the transaction set identifier of whatever it is acknowledging, so the same document type reports on an 850 purchase order, an 810 invoice, an 856 ship notice or an 850 in a different version. That is also why the TED01 code list is so large: it has to cover the failure modes of every one of them.

Five facts that decide whether you are reading 824s correctly

• A clean 997 is not an accepted order. The 997 reports syntax. The 824 reports whether the application could use the content. Two different systems, two different verdicts, hours apart.
• C codes are accepts that changed your data. TC, IC, GC and BC mean the receiver overwrote something and kept the document. TED08 carries what they substituted, and it is the only record you will get.
• P codes mean part of it is live. On a TP or IP, resending the whole document creates a duplicate. Send a change document instead.
• H codes are neither accepted nor rejected. TH and GH sit in a human queue. A two state monitor silently counts them as successes.
• TED01 is not one code list. Element 647 pools rail, retail, identity and ACH code sets in one element. Translate it per trading partner, never globally.

Where this sits in the order cycle

Trace one purchase order end to end and the acknowledgment layers stack up like this. You send an 850 purchase order. A 997 comes back confirming the syntax parsed. An 824 comes back, if your partner sends them, confirming the application loaded the content. An 855 purchase order acknowledgment comes back carrying the commercial answer line by line. If something has to change after that, an 860 goes out and an 865 answers it. Four of those five documents are acknowledgments of one kind or another, and each one confirms something different from the others. Treating any of them as a proxy for the rest is how orders end up confirmed on one side and absent on the other.

None of this helps with the partners who never joined the EDI channel at all. For those, the rejection arrives as a reply in a shared mailbox saying the order could not be processed, and the practical control is making sure a person actually reads that shared inbox rather than assuming that no news is good news. Same failure mode, different transport.

Whichever channel a document arrives on, the columns you need out of it are the same: document number, date, partner, then one row per line with quantity, unit of measure, price and part number. When the source is a PDF rather than X12, that is the job PurchaseOrders does, and lining both channels up on one column layout is what makes a single exception report possible. For the wider picture of flattening X12 into rows, see the EDI to Excel converter guide.