EDI 824: How to Read the Rejection Codes

You’re looking at a shortage deduction on this week’s remittance, and the invoice behind it went out clean. The 997 came back accepted. No red flags, nothing bounced, nothing in the EDI log to explain why a check just landed short.

You might be the one who owns that exception queue, supply chain, finance, or IT, at a $10M-$500M CPG supplier. If so, you’ve probably already pulled the invoice and the ASN and found nothing obviously wrong with either. The deduction doesn’t add up, and neither the clean 997 nor the warehouse floor can tell you why.

Chase enough of these, and the real cost stops being any single write-off. It becomes the line you’ve learned to expect coming off the check every month, disputed one at a time on a hunch instead of evidence. The explanation was probably already in your EDI mailbox, weeks before the deduction ever posted. It just wasn’t in the 997.

A clean 997 feels like confirmation. The transmission went out, the retailer’s system took it, nothing bounced back red.

It isn’t confirmation. It’s a receipt.

The 997 Functional Acknowledgment checks one thing: did the envelope you sent parse as valid EDI syntax. Right segments, right order, right delimiters. It has no opinion on whether the invoice total adds up, whether that PO number is still open, or whether you’re billing for something already paid.

That opinion, when a retailer bothers to send one, is the 824. (For the complete breakdown of what each document proves, what it doesn’t, and the monitoring rules that catch the gap between them, see EDI 997 vs. 824: which acknowledgment tells you what.)

Where does the 824 fit between the 997 and a deduction?

The 997 fires first, automatically, usually within minutes. It’s a syntax check, not a business check.

The 824 Application Advice comes after, once the retailer’s system has actually tried to process the document’s content. That can be minutes later or overnight, depending on the retailer’s batch cycle.

A clean 997 followed by a rejected 824 is a specific, common pattern: the envelope was fine, the content wasn’t. Two separate documents, two separate questions, and only one of them tells you anything useful about whether the transaction will actually go through.

What do the OTI codes TA, TE, and TR mean?

Every 824 carries an OTI segment, Original Transaction Identification, that links the advice back to the document it’s responding to: an 850 purchase order, an 810 invoice, an 856 ASN, whatever was submitted.

OTI01 carries the outcome, and it only has three values:

• TA: Transaction Set Accepted. No content errors found.
• TE: Transaction Set Accepted with Error. It’ll be processed, but something’s flagged and worth checking.
• TR: Transaction Set Rejected. The retailer’s system will not process this document as submitted.

TE is the one people miss. It reads as a pass because the document technically went through, but it’s carrying a real error message alongside the acceptance. Filtering your monitoring to TR-only misses every TE.

What do the common TED error codes mean?

When something’s wrong, the detail lives in the TED segment, Technical Error Description. One TED loop per error, so a single 824 can carry several if the source document had multiple problems.

TED01 is a numeric error condition code from a small, generic X12 list. TED02 is free text, and it’s usually where the actually useful explanation lives. TED03 identifies which segment of the original document the error points to.

That generic list is the X12 standard’s floor, not a retailer’s actual vocabulary. Individual retailers layer their own, much longer error catalogs on top of it, usually delivered through TED02’s free text or a retailer-specific reference number rather than a different TED01 value.

Kroger’s public EDI documentation is a useful, publicly visible example of that layering: its own error catalog runs from 0000 to beyond 1200, organized in ranges by which source document triggered the error, envelope errors in the 0000s, invoice errors in the 0300s, ASN errors in the 0400s, purchase order errors in the 0700s, and so on. Nothing about that scheme is universal to X12; it’s Kroger’s own numbering. But it shows the general pattern: the standard gives you TA/TE/TR and five generic codes, and the retailer’s implementation guide is where the real specificity lives.

Kroger is also a useful example of what an ignored 824 costs later. An unresolved EDI failure at Kroger surfaces on the remittance as deduction code 5, EDI non-compliance, one of the numeric codes in the Kroger supplier deductions guide.

What does a rejected 824 look like in practice?

A rejected invoice might come back looking like this, in plain terms rather than raw segment syntax:

• OTI: Code = TR. References the original 810 invoice by its control number.
• REF: Cites the PO number the invoice was billed against.
• TED: TED01 = 010 (Total Out of Balance). TED02 free text: line extensions total $4,812.00; invoice header total shows $5,212.00. TED03 points to the invoice detail segment.

Read cold, that’s an accounting error, a four-hundred-dollar gap between what the line items add up to and what the header claims. Read against the shipment it describes, it’s usually a pricing table that changed after you generated the invoice, or a discount you applied at the header level that never got distributed down to the lines.

Either way, it’s fixable in minutes if someone sees it the day it arrives.

An 824 today is a deduction next month

Most systems don’t automatically re-check a rejected invoice a week later. If you don’t make the correction and resend it, the underlying mismatch, the one the TED segment named precisely, doesn’t go away. It just changes form.

A total-out-of-balance invoice that never gets corrected and resent eventually gets paid against whatever the retailer’s system decided was right. Or it gets flagged for a pricing deduction once someone in accounts payable reconciles it manually. A duplicate invoice that triggered a 006 and got ignored can surface later as a separate billing dispute entirely.

The Walmart deduction code 22 entry covers one specific downstream shape this takes: a quantity mismatch that started as a documented, named error and ended up looking like a physical shortage by the time it hit a remittance. The 824 is very often the earlier point where that mismatch was already on record, in writing, weeks before the deduction.

How do you monitor 824s instead of reading them by hand?

Reading 824s by hand, one at a time as they land in an inbox, is exactly how a rejected invoice or a flagged ASN turns into an unexplained deduction a month later. If you want the early warning the 824 is built to give you, the fix is a validation you build once, not a habit you have to keep up.

• Parse every inbound 824 automatically and branch on OTI01 yourself. TR obviously needs attention. But build a queue for TE too, instead of letting it pass as a shrug. It’s an acceptance carrying a live error.
• Key the exception record to the OTI segment’s reference back to the original document. That way, a flagged invoice or ASN shows up next to the transaction it came from on your side, not as an orphaned message in an EDI mailbox.
• Set an age-based alert. An 824 exception you leave untouched for more than a few business days is exactly the kind of thing that turns into an unexplained remittance line a month later.
• Route TED03’s segment reference to whoever on your team owns that part of the document: pricing errors to the team that sets pricing, quantity errors to the team that confirms picks. Don’t let everything land in one generic EDI inbox.

This is the same category of gap a data-bridge assessment is built to find: the distance between a system that received a clear, written explanation of what went wrong and a process that never routed it to a person who could act on it.

The data-bridge calculator gives a rough sense of what that gap is worth before committing to finding it.

Sources

• “EDI 824 Application Advice,” Stedi, for OTI/REF/TED/NTE segment structure and OTI01 code values.
• “824 Application Advice Error Codes,” Kroger EDI Portal, for the real-world example of a retailer-specific error catalog organized by source-document range.
• “What’s an EDI 824 Transaction? The Application Advice Document,” LearnEDI.org, for the 997-versus-824 relationship and TED-segment error examples.

Segment names and structure are the public X12 standard. Retailer-specific error catalogs, like Kroger’s, are that retailer’s own implementation and will differ elsewhere. If a detail here doesn’t match your own trading partner’s guide, tell us and we’ll correct it.