EDI 824 Application Advice: Reading Rejections Before Chargebacks

The invoice left the ERP on Monday, the trading partner's 997 came back accepted within the hour, and accounts receivable marked it sent. Three weeks later the remittance arrived without it. The retailer had rejected the invoice on Monday afternoon through an 824 application advice, the message landed in a translator mailbox that nobody read, and the clock on payment terms never started because the retailer never held a valid invoice.

An 824 is the trading partner telling you that a document passed the syntax checks but failed its business rules. Reading it the same day, routing it to the person who owns the rejected document, and resending inside the partner's window turns most rejections into a same-week fix instead of a short payment, a deduction or a compliance fine.

• What this guide covers: the BGN, OTI and TED segments, the TA, TE and TR outcomes, generic and partner-specific error codes, how to match an 824 to the document it judges, and where resubmission deadlines come from.
• What it adds: a sample 824 with a matching query, a dollar and rupee cost of an unread rejection, an hour-by-hour incident and an operating checklist.

An 824 judges content after the 997 has already said yes

A 997 confirms that a functional group could be read; an 824 reports whether the receiving application accepted the data inside it. Treating a positive 997 as acceptance is the root of most missed rejections, because the business edits run later and report separately.

X12 describes the 824 Application Advice as a way "to report the results of an application system's data content edits" of transaction sets. In practice retailers, distributors and carriers send it after their invoice, ship notice, price or order systems have checked the content against their own records. Our guide to the EDI 997 functional acknowledgment covers the earlier syntax layer; this article starts once the 997 has passed.

The last row is where an ignored 824 often reappears. Our guide to the EDI 812 credit and debit adjustment explains how those deductions arrive; reading the 824 promptly is how you stop many of them from being raised at all.

Reading BGN, OTI and TED in the order a reviewer needs them

Read the OTI first to learn which document was judged and the verdict, then the TED loops for each error, and the BGN last for the partner's own reference and date. That order gets a reviewer from "something failed" to "this invoice, this field" in seconds.

• BGN beginning segment: BGN01 is the purpose code, BGN02 the partner's reference and BGN03 the date; Kroger's 5010 map sends 00 (original), while Walmart's published 824 uses 11 (response) and puts the original ISA13 interchange number in BGN02.
• N1 party loop: N101 codes FR (message from) and TO (message to) identify the rejecting division and the sender of the original document.
• OTI original transaction: OTI01 holds the verdict, OTI02 and OTI03 a reference qualifier and number such as an invoice number, OTI08 the original GS06 group control number, OTI09 the ST02 set control number and OTI10 the set identifier such as 810 or 856.
• TED technical error: TED01 is the application error condition code, TED02 a free-form message of up to 60 characters, and in Kroger's map TED07 carries a copy of the bad data element and TED08 related new content.
• NTE notes: some partners add NTE segments with longer debugging text; Walmart's guide uses NTE01 code ERN for error notes of up to 80 characters each.

ST*824*0001~
BGN*00*RJ240611*20261103~
N1*FR*RETAILER DC 6040*9*0012345670000~
N1*TO*SUPPLIER INC*9*0987654320000~
OTI*TR*IV*INV-558210*****48213*482130001*810~
TED*010*TOTAL DOES NOT BALANCE TO DETAIL*****48600.00*48599.80~
SE*7*0001~

-- Find outbound documents rejected by an 824 (TR) with no later resend
SELECT d.doc_type, d.doc_ref, d.gs_control, d.st_control,
       a.received_at, a.ted01, a.ted02
FROM outbound_docs d
JOIN app_advice a
  ON a.gs_control = d.gs_control
 AND a.st_control = d.st_control
 AND a.set_id     = d.doc_type
WHERE a.oti01 = 'TR'
  AND NOT EXISTS (
        SELECT 1 FROM outbound_docs r
        WHERE r.doc_ref = d.doc_ref
          AND r.sent_at > a.received_at)
ORDER BY a.received_at;

The sample says the retailer rejected invoice INV-558210, sent in group 48213 as set 482130001, because the invoice total did not balance to its detail lines: the header said 48,600.00 and the lines summed to 48,599.80. The query lists every rejected document still waiting for a corrected resend, oldest first, which is the work queue an analyst should open each morning.

Accept, accept with error, reject: what TA, TE and TR mean

TA means the document was used as sent, TE means it was used but something should be fixed before the next one, and TR means the partner discarded it and you must resend. Only TR stops a payment clock or a receipt, but repeated TE results usually feed the partner's compliance scorecard.

Kroger's 824 map lists exactly these three OTI01 values for its retail application: TA Transaction Set Accept, TE Transaction Set Accept with Error and TR Transaction Set Reject. Its error documentation adds a W or F suffix to its own codes, where W is a warning and the document is processed, and F is fatal and the document "will not be processed" and must be resent.

EDI 824 application advice handling should treat OTI01 code TR as a discarded document requiring a corrected resend from the billing or warehouse system, TE as accepted with a defect to fix, and TA as final; Kroger's published code list marks fatal errors with an F suffix and warnings with a W suffix.

Not every partner uses the same three codes. Walmart's published 824 lists BP, batch partial accept or reject, in OTI01 and sets OTI03 to a default 00000, relying on TED02 and NTE text for the detail. Map the OTI01 values each partner actually sends to your own three outcomes rather than assuming TA, TE and TR everywhere.

Generic condition codes versus a partner's own error numbers

TED01 tells you the class of problem; the partner's own code or text in TED02 tells you the rule that failed. Build your routing on TED01 and your fix instructions on the partner code, and keep each partner's code list as a versioned table.

Kroger publishes its partner codes in ranges by document: 0300 to 0399 for 810 and 880 invoices, 0400 to 0499 for 856 ship notices, 0600 to 0699 for 879 price changes, and 1100 to 1199 for 997 issues. Examples include 0381F, invoice total does not balance to detail, and 0417F, a missing SSCC-18. Codes beginning with E indicate translation errors, usually syntax.

Matching an 824 to the invoice, ship notice or price change it judges

Match on the original group and set control numbers first and the business reference second. Control numbers are unique per transmission; invoice and PO numbers repeat across resends, so they cannot tell you which version was rejected.

Kroger's map carries the original GS06 in OTI08, the original ST02 in OTI09 and the set identifier in OTI10, and puts a division, PO or invoice number in OTI03; if the rejected document had no usable reference, it sends the transmission control number instead. Walmart puts the original GS06 in OTI08 and the original ISA13 in BGN02. A matcher that stores all three control levels for every outbound document can therefore pair almost any partner's 824 with its source.

• Store control numbers outbound: keep ISA13, GS06 and ST02 against each invoice, ship notice and catalogue record when it is sent, not only in translator logs.
• Prefer set-level matches: a GS06 and ST02 pair identifies one document; a GS06 alone may cover hundreds of invoices.
• Flag orphans: any 824 that matches nothing within one hour goes to the EDI analyst, because it usually means a control number was reused or a resend overwrote history.
• Keep the verdict on the document: write the OTI01 result and TED codes back to the invoice or shipment record so billing and warehouse users see it without opening the translator.

Envelope control numbers are usually generated by the translator, so make sure they are copied back to the business record when the file is built. The 824 is only as useful as your ability to find the document it refers to, and that link is lost the moment a resend reuses a set control number.

The resubmission window is set by the partner, not by X12

X12 defines the message, not a deadline to fix what it reports. The time you have comes from the partner's invoice terms, its routing guide and its scorecard, plus any tax deadline on the corrected document, so record each partner's window next to its code list.

The deadlines that matter are commercial. A retailer's payment terms usually run from receipt of a valid invoice, so a TR result pauses the clock until the corrected document arrives. A ship notice rejected after the truck has delivered may not be replaceable at all; Kroger's error documentation says no capability exists to alter, replace or delete an ASN already received, which turns a rejected 856 into a receiving and deduction problem.

Resubmission windows for documents rejected by an X12 824 come from each trading partner's invoice terms and routing guide, not from the standard; Kroger states that a received 856 ship notice cannot be altered or replaced, so a TR on an ASN after delivery leaves only receiving evidence for any later deduction dispute.

India adds a hard tax deadline where the corrected document is a domestic GST e-invoice. A GSTN advisory dated 5 November 2024 stated that from 1 April 2025 taxpayers with aggregate annual turnover of ₹10 crore or more cannot report invoices, credit notes or debit notes older than 30 days on the invoice registration portals. An invoice dated 1 April 2025 could not be reported after 30 April 2025.

Pricing an unread rejection in dollars and rupees

An 824 that sits unread costs working capital, partner fees and analyst time, and the figures grow with every day of delay. The ledger below uses illustrative figures for a US supplier invoicing a US retailer and an Indian exporter invoicing a US buyer.

Multiply by volume to see the case for a work queue. A supplier with 10 rejections a month at the US figure loses about $56,700 a year in avoidable cost before counting any deduction that follows. The Indian line carries exchange-rate exposure too, because the dollar receipt lands 25 days later than planned.

An unread EDI 824 rejection on a $48,600 retail invoice cost $472.50 in the illustrative ledger, from 20 extra days of working capital at 9%, a $150 handling fee and analyst time; reading TR results the same day keeps that loss near zero because payment terms restart only on a valid resend.

A rejected invoice that resurfaced as a short payment

The opening case followed a common path: a positive 997, an ignored 824 and a remittance that did not include the invoice. Each step below shows where a rule or an owner would have caught it.

1. Day 0, 09:12: ERP releases invoice INV-558210 for $48,600 to the translator; it leaves in group 48213, set 482130001.
2. Day 0, 10:05: Partner's 997 accepts group 48213; the ERP status changes to "transmitted", which billing reads as delivered.
3. Day 0, 15:40: Partner's 824 arrives with OTI*TR and TED*010, header 48,600.00 against detail 48,599.80, caused by rounding on a 2% allowance line; the translator files it under an unmonitored inbound mailbox.
4. Day 21, 11:30: Remittance for the week omits INV-558210; the collector opens a dispute ticket assuming a deduction.
5. Day 22, 14:10: EDI analyst finds the 824, billing corrects the allowance rounding rule, and the corrected invoice is resent; payment terms restart from day 22.

Two changes closed the gap: the ERP stopped treating a 997 as delivery and waited for either an 824 TA or the partner's documented silence period, and every TR created a task for the billing team with the TED text attached. The rounding rule fix stopped the same rejection recurring on the next 300 invoices.

Translator rules, analyst judgment and where AI helps with TED text

Let the translator and ERP do the matching, routing and status changes, and keep people for deciding what the partner actually wants changed. AI is useful for turning free-text TED02 and NTE notes into a suggested fix, not for resending documents on its own.

Partner code lists change with every guide release, so keep them under the same version control as your maps; our EDI mapping specification guide shows how crosswalk tables are versioned alongside field rules.

Running an 824 work queue with owners in billing and the warehouse

Give every rejected document a business owner, a deadline and a reason code within an hour of the 824 arriving. The checklist below is what we review first when a supplier's deduction rate rises without an obvious operational cause.

More EDI and freight document guides are on the logistics and supply chain hub, and the retailer chargeback mechanics that follow an unresolved rejection are covered in our vendor compliance chargeback math guide, which deals with disputing deductions after the fact rather than reading the 824 that precedes them. If you want 824 matching and routing built into your ERP or translator, you can send us your partner list and volumes.