EDI 824 Application AdvicePublished Mar 10, 2026 · Updated May 9, 2026

EDI 824 Application Advice: Complete Guide

How the EDI 824 Application Advice transaction works. Learn error reporting, segment structure, and how to use 824s for EDI troubleshooting.

The EDI 824 Application Advice is the X12 transaction set that trading partners use to report business-level errors in a document they already acknowledged as syntactically valid. It is the document that arrives after you get a clean 997 and tells you the invoice PO number does not exist, the price does not match, or the item is not in their catalog.

What is an EDI 824?

An EDI 824 Application Advice is a structured error notification defined by the ASC X12 standards body that a trading partner sends when the content of a received document fails application-level validation, even after the 997 syntax check passed.

Authoritative sources for 824 implementation:

  • The X12.org Transaction Sets reference defines the OTI, TED, and NTE segment structure used in all 824 implementations
  • Retailer-specific 824 error code lists are published in their vendor implementation guides (Walmart SupplierOne, Target Partners Online, Amazon Vendor Central)

An 824 is sent by a trading partner (usually a retailer or buyer) when they find problems with the content of your EDI document, even though the syntax was valid.

The key difference from a 997:

997 Functional Acknowledgment824 Application Advice
ChecksSyntax and structureBusiness content and data
TimingSent immediately on receiptSent after processing
Example error"Missing required N1 segment""Invalid PO number - not found in our system"
ScopeEnvelope and segment validationApplication-level validation

A document can pass the 997 check (valid syntax) but still fail the 824 check (bad business data). You might send a perfectly formatted 810 Invoice, get an accepted 997, and then receive an 824 saying the invoice references a PO number that does not exist.

When Do Retailers Send 824s?

Retailers and buyers send 824s when they process your EDI documents and find data problems:

  • Invalid PO numbers - Your 810 Invoice references an order they cannot find
  • Duplicate submissions - You sent the same 856 ASN twice
  • Price mismatches - Your invoice price does not match the agreed contract price
  • Invalid item numbers - UPC or SKU does not exist in their system
  • Quantity issues - Invoiced quantity exceeds the ordered or received quantity
  • Missing required data - A field the retailer needs is present but empty or wrong

These are all problems a 997 would never catch because the EDI file itself is structurally valid.

Key Segments Explained

OTI - Original Transaction Identification

The OTI segment identifies which original transaction the 824 is reporting on:

OTI*TR*IA*000001234*VENDOR123*BUYER456*20260301*IN*810*0001
  • OTI01: Application Acknowledgment Code
    • TR = Transaction Accepted with Errors
    • TA = Transaction Accepted (no errors)
    • TN = Transaction Not Accepted (rejected)
    • TE = Transaction Accepted, Content Not Accepted
  • OTI02: Reference Identification Qualifier (IA = Internal Vendor Number)
  • OTI03: Reference Identification (original control number or PO number)
  • OTI04: Application Sender's Code
  • OTI05: Application Receiver's Code
  • OTI06: Date
  • OTI07: Functional Identifier Code (IN = Invoice)
  • OTI08: Transaction Set Identifier Code (810)
  • OTI09: Transaction Set Control Number

TED - Technical Error Description

The TED segment carries the actual error detail:

TED*020*Invalid purchase order number referenced on invoice
  • TED01: Application Error Condition Code
  • TED02: Free-form text describing the error

Common TED01 Error Codes:

CodeMeaning
001Unrecognized interchange sender ID
002Unrecognized interchange receiver ID
009Unknown transaction set
015Duplicate control number
018Invalid date
019Invalid time
020Invalid data value
023Data element missing
024Duplicate data
025Invalid characters
028Invalid price

NTE - Note/Special Instruction

The NTE segment provides additional context about the error:

NTE*ERR*PO number 4500012345 not found in system. Verify PO was transmitted and accepted.
  • NTE01: Note Reference Code (ERR = Error description)
  • NTE02: Free-form message text

The NTE segment is where you often find the most useful troubleshooting information. Retailers will spell out exactly what they expected vs. what they received.

Real-World 824 Example

Here is a complete 824 rejecting an 810 Invoice due to an invalid PO number:

ISA*00*          *00*          *ZZ*BUYER456       *ZZ*VENDOR123      *260305*0930*U*00401*000000042*0*P*:~
GS*AG*BUYER456*VENDOR123*20260305*0930*42*X*004010~
ST*824*0042~
OTI*TN*IA*000001234*VENDOR123*BUYER456*20260301*IN*810*0001~
TED*020*Purchase order number 4500012345 not found~
NTE*ERR*The PO number on your invoice does not match any active order. Check for typos or confirm the PO was transmitted.~
SE*5*0042~
GE*1*42~
IEA*1*000000042~

Translation: "We rejected your 810 Invoice (control #0001, sent March 1) because PO number 4500012345 does not exist in our system."

How to Troubleshoot 824 Errors

When you receive an 824, follow this process:

  1. Read the OTI segment to identify which original transaction is affected
  2. Check the TED code to understand the error category
  3. Read the NTE text for specific detail on what went wrong
  4. Pull up the original transaction and compare it against the error
  5. Fix the data in your source system (ERP, WMS, etc.)
  6. Resubmit the corrected transaction

Use the EDI Inspector to parse and validate your original transaction side-by-side with the 824 to pinpoint the problem fast.

824 vs. 997: Which One Should You Expect?

Here is a typical flow showing how both work together:

1. You send 810 Invoice
2. Partner sends 997*A       (syntax is valid - good)
3. Partner processes invoice
4. Partner sends 824*TN      (business data rejected - problem)

The 997 and 824 are not mutually exclusive. You will often receive both: first the 997 confirming receipt, then the 824 reporting content issues found during processing.

When you only get a 997 rejection (no 824): The problem is structural. Your file could not even be parsed. Fix the EDI syntax first.

When you get 997*A followed by an 824: Your syntax is fine, but the data inside is wrong. Fix the business content (PO numbers, prices, quantities, item codes).

Common 824 Scenarios

Scenario 1: Duplicate Invoice

OTI*TN*IA*000001234~~~IN*810*0001~
TED*024*Duplicate invoice number INV-2026-0042~
NTE*ERR*This invoice number was already submitted and processed on 2026-02-28.~

Fix: Check your invoice numbering. Resending the same invoice number triggers a duplicate rejection.

Scenario 2: Price Mismatch

OTI*TR*IA*000001234~~~IN*810*0002~
TED*028*Unit price does not match purchase order~
NTE*ERR*Line 3: Invoice price $14.99, PO price $12.99 for item UPC 012345678901.~

Fix: Compare your invoice prices against the original 850 Purchase Order. Update your price file if the contract changed.

Scenario 3: Invalid Item

OTI*TN*IA*000001234~~~SH*856*0003~
TED*020*Unrecognized item identifier~
NTE*ERR*UPC 999999999999 on line 5 is not set up in buyer item master.~

Fix: Confirm the UPC or SKU is active in the retailer's system. You may need to complete item setup before shipping.

Best Practices

1. Monitor 824s daily

Do not let 824s pile up. Each one represents a transaction your trading partner could not process. Unresolved 824s lead to payment delays and compliance issues.

2. Build a response workflow

Assign 824 errors to the right team:

  • Invalid PO/item errors go to order management
  • Price mismatch errors go to pricing or contracts
  • Duplicate errors go to your EDI team to check transmission logs

3. Track error patterns

If you keep getting the same TED code from the same partner, there is a systemic issue. Fix the root cause in your ERP or mapping configuration instead of correcting each transaction one at a time.

4. Use the EDI Inspector

Paste your 824 into the EDI Inspector to quickly identify the referenced transaction and error codes. Cross-reference with your EDI compliance checklist to prevent recurring issues.

FAQ

How quickly should I respond to an 824?

There is no universal SLA for 824 responses, but you should fix and resubmit the corrected transaction within 24-48 hours. Delays can hold up payments (for invoices) or cause order fulfillment problems. Check your trading partner agreement for specific timelines.

Can I send an 824 back to my trading partner?

Yes. The 824 is bidirectional. If you receive an EDI document from a partner and the business content has errors, you can send an 824 back to report those issues. This is common when receiving inbound 856 Ship Notices or 850 Purchase Orders with data problems.

Do I need to send a 997 for an 824 I receive?

Yes. The 824 is itself an EDI transaction, so your system should send a 997 Functional Acknowledgment confirming you received the 824. This follows the same rules as any other inbound transaction. For a full walkthrough on setting up your acknowledgment process, see the EDI implementation guide.

Related Transaction Sets

Need Help?

Try the EDI Inspector to parse your 824 Application Advice documents, or review the EDI compliance checklist to prevent common errors before they happen.

James Darby
Last updated: 5/9/2026

Related Resources