The EDI 824 · Application Advice is how a trading partner reports, in structured form, the errors it found when it applied your document to its business system. A 997 · Functional Acknowledgment says your file arrived and parsed. An 824 says whether the content inside it was acceptable — and if not, which element, which value, and why.
That distinction is the whole point. Most integration failures that cost real money are not syntax failures. The file was well-formed, the envelope was correct, and the acknowledgment came back clean — and then the order, claim, or invoice was quietly rejected downstream because a price, a code, or a reference did not match what the receiver's system expected. The 824 exists to make that rejection explicit, machine-readable, and fixable, instead of leaving it to surface weeks later as a missing payment or a chargeback.
What is the EDI 824 · Application Advice?
The 824 is an X12 transaction set a receiver sends back after application-level validation of a document you sent. It can report acceptance, rejection, or acceptance with errors noted, and it can do so for a whole transaction or for individual elements inside it.
Three ideas define it:
- It reports business validation, not transport or syntax. Prices that do not match the catalog, item codes the receiver does not recognize, quantities outside tolerance, references that do not resolve — these are application errors, and they are what the 824 carries.
- It points at the problem. A useful 824 identifies the offending segment and element and carries a coded description of the error, so the fix is a specific edit, not an investigation.
- It closes the loop the 997 leaves open. The 997 · Functional Acknowledgment answers "did it parse?" The 824 answers "did it pass?" A flow that only watches the first question will call rejected documents successful.
The healthcare world has its own specialized cousin — the 277CA for claim acknowledgments — but the 824 is the general-purpose version used across retail, distribution, and manufacturing flows, often returned for 850 · Purchase Order, 810 · Invoice, and other inbound documents a partner validates before posting.
How is the 824 different from the 997?
The 997 · Functional Acknowledgment works at the envelope and syntax layer. It confirms receipt of a functional group and reports structural errors: bad segments, wrong element types, broken control counts. It says nothing about whether the business content was right.
The 824 · Application Advice works one layer up. The document parsed fine; the question is whether the receiver's application accepted it. An 810 · Invoice can be syntactically perfect and still earn an 824 rejecting it because the billed price disagrees with the purchase order it references.
Treating a clean 997 as success is one of the most common EDI design mistakes. The acknowledgment ladder is: transport receipt, then syntax acknowledgment, then application advice. Each rung answers a different question, and stopping at rung two leaves the most expensive failures invisible.
Why do application rejections go unnoticed?
Because they arrive as a document type nobody wired into the workflow. The sender's system posts the outbound file, records the 997, marks the exchange complete, and moves on. The inbound 824 lands in a mailbox or a folder, unparsed, while the business assumes the invoice is in the payment queue or the order is in production.
Weeks later the truth arrives in the worst possible form: a payment that never comes, a shipment that never started, a partner asking why you never fixed the errors they sent you. They did tell you — in the 824, on the day it happened. The failure was not communication; it was that nobody built the step that listens.
Where do 824 flows usually break?
The first break is the unmonitored inbox. Inbound application advices are received but never translated into work — no alert, no ticket, no owner. The fix is to treat an 824 reporting rejection like an operational alarm, because that is what it is.
The second break is advice without context. An 824 references the original document by its control or reference numbers; if your system cannot join the advice back to the exact outbound transaction and version, the error report is unactionable. Joining must be by construction, not by someone searching folders.
The third break is partial rejection read as total success — or total failure. An 824 can accept most of a transaction and reject individual lines or elements. Systems that collapse that into a single pass/fail either resend good data (creating duplicates) or discard good lines with the bad. Read the advice at the level it was written.
The fourth break is fixing the instance, not the cause. A rejected price gets manually corrected and resent, while the catalog mismatch that caused it produces the same rejection on the next invoice. Every recurring 824 error code is a defect in a map, a master-data record, or a partner agreement — fix it there and the stream of advices dries up.
The fifth break is never sending advices yourself. If you receive documents, your partners deserve the same clarity: validate at application level and return specific, element-level errors promptly, while the sender can still correct and resend inside the business window.
What should you check in an 824 flow?
Five checks keep application advice working:
First, coverage: for every outbound document type that matters, do you know whether your partner returns an 824, a proprietary report, or silence — and is silence being mistaken for acceptance?
Second, routing: does every inbound 824 get parsed, joined to its original transaction, and turned into an owned task the same day it arrives?
Third, granularity: can your handling act on line- and element-level results, accepting what passed and correcting only what failed?
Fourth, recurrence: are you counting 824 errors by code and partner, so the top causes get fixed at the map or master-data level instead of one document at a time?
Fifth, symmetry: do you return equally specific application advice for the documents you receive, promptly enough for your partners to act on it?
A flow that runs those checks turns rejections from surprises into same-day corrections: the partner told you exactly what was wrong, in a format your system can act on — all you had to do was listen at the right layer.
Frequently asked questions
Who sends the EDI 824 · Application Advice?
The receiver of a document sends it to the original sender after application-level validation. It reports whether the document was accepted, rejected, or accepted with errors, and identifies the specific segments and elements involved.
What is the difference between the EDI 824 and the EDI 997 · Functional Acknowledgment?
The 997 reports receipt and syntax: whether the file arrived and parsed correctly. The 824 reports business acceptance: whether the content passed the receiver's application checks. A document can earn a clean 997 and still be rejected by an 824.
Which documents does an 824 usually report on?
Any document a partner validates before posting — commonly the 850 · Purchase Order and the 810 · Invoice in retail and distribution, and a range of documents in manufacturing and healthcare-adjacent flows that use the general-purpose advice instead of a specialized acknowledgment.
What should happen when an 824 reports a rejection?
The advice should be joined automatically to the original transaction, routed to an owner the same day, and corrected at the level reported — resending only the failed lines where the advice is partial, and fixing recurring causes in the map or master data.
Can an 824 accept part of a document and reject part of it?
Yes. That partial reporting is one of its strengths: it can accept a transaction while flagging specific elements or lines. Handling that ignores the granularity either duplicates good data or discards it.
I build SignalEDI, an EDI and API integration platform for SMBs — application-level error reporting is exactly the layer we think most integrations under-build. If your team only watches functional acknowledgments, it is worth asking what your partners have been trying to tell you: signaledi.com
— Chris, founder of SignalEDI
Top comments (0)