Do You Need EDI 824 If You Already Send 997s?

What's actually different between an EDI 824 and a 997/999?

The 997 or 999 confirms your document arrived and was structurally readable. The 824 tells you what happened after that: whether the receiving application actually accepted the content, rejected it, or needs changes before it can be processed. An EDI 997 is an acknowledgment to indicate whether an EDI transmission has been received and translated, while an EDI 824 indicates whether an EDI document is accepted or rejected by a processing system such as Accounts Payable. One operates at the envelope level. The other operates at the business logic level, inside your ERP, WMS, or AP system.

This is the part most people miss when they're building out an EDI 824 application advice map for the first time: the 824 doesn't replace the 997. EDI 824 Application Advice doesn't replace the EDI 997, EDI 999 or EDI TA1 transactions, and the recipient of an 824 document may send or be required to send a 997 in response confirming the 824 itself was received. So in a fully compliant setup, you can end up with three acknowledgment layers stacked on a single original document. Overkill for a low-risk transaction. Necessary for a high-dollar invoice batch where a silent rejection means a 45-day payment delay nobody notices until a supplier calls.

On the granularity front, the 824 goes down to the segment and element level. Where a 997 just tells you the transaction set as a whole was structurally fine, the 824 can point at the specific data element that failed, similar to how the EDI 824 Application Advice, also called EDIFACT APERAK, reports acceptance, rejection, or acceptance with change of EDI content. If you're running EDIFACT rather than X12, this isn't a separate concept you need to learn. In the EDIFACT standard, used mainly in Europe, the APERAK Application Error and Acknowledgement message performs the same function as the X12 824.

When should you not use an 824?

Skip the 824 whenever a dedicated response document already exists for that transaction type. Using an 824 on top of a purpose-built acknowledgment is redundant and confuses trading partners who expect one specific response format, not two competing ones.

The X12 standard is explicit about this. The 824 transaction set should not be used in situations where a specific response document exists for a given transaction, for example, an 855 Purchase Order Acknowledgement in response to an 850 Purchase Order. Healthcare has the same rule baked into its companion guides: an 835 remittance advice answers an 837 claim, not an 824. Transportation has its own version of this. If a carrier tenders a load with a 204, the shipper responds with a 990 accept/decline, not an 824. The 824 belongs in the gaps where no dedicated response transaction exists, or where the existing one doesn't give you enough error detail to act on.

Where does the 824 fit in a freight and transportation EDI stack?

In freight EDI, the 824 sits downstream of the invoice and billing transactions, not the shipment status ones. It's the document that tells a carrier or shipper that something in a 210, 410, or 820 didn't process cleanly on the receiving end.

The EDI 824, also known as the Application Advice, is a formal response to previously sent EDI documents, including invoices, purchase orders, or shipment documents like the 753 or 754. PartnerLinQ's mapping of a rail freight workflow shows exactly where it lands: a rail carrier issues an EDI 410 Rail Carrier Freight Details and Invoice, and if billing discrepancies arise, EDI 812 Credit/Debit Adjustment is transmitted; the shipper then transmits EDI 820 Payment Order/Remittance Advice, and if processing errors occur, EDI 824 Application Advice communicates corrections or rejections. Notice the 824 shows up twice in that chain conceptually, once as a possible response to the 410/invoice content itself, and again as a response if the 820 payment instruction has problems.

The same source notes that 214 shipment status errors often trigger 997/999 rejections or 824 application advice responses that may delay billing or distort SLA reporting, which is exactly why TMS platforms surface these as exception queues rather than leaving ops teams to read raw segment codes. This is where connectivity layers like Cargoson, alongside MercuryGate and Descartes, earn their keep, normalizing 824 and APERAK responses into a single dashboard so a freight coordinator sees "invoice #4471 rejected: rate mismatch" instead of parsing a TED segment.

What data does a real 824 rejection actually contain?

A usable 824 rejection needs a sender, a timestamp, a reference to which original transaction it's responding to, a status (accepted, rejected, or accepted with changes), and either a coded error or free-text explanation of what needs fixing.

TrueCommerce breaks this down cleanly: EDI 824 must include details pertaining to a previously received document, including the date of receipt, name of the sender, status of the transaction (accepted, rejected, or accepted with changes), and details of the required changes. That last part, the required-changes detail, is where implementation quality diverges. Some trading partners send tight, coded error reasons your translator can map directly into a resubmission workflow. Others dump free-text notes into a TED segment, and here's the gap nobody advertises: plenty of mid-market ERPs can't natively parse free-text 824 content into an actionable ticket. Teams end up building a manual triage step, someone reads the note, decides what it means, and re-keys the correction. If you're evaluating whether to support 824 at all, ask your prospective partners upfront whether their 824s use coded reason segments or narrative text. That answer changes your build estimate significantly.

Do healthcare and non-freight industries use the 824 differently?

Not structurally, but the trigger is different. In healthcare, the 824 responds to claims content rather than freight or purchase order content, and it's sometimes a state-level requirement rather than an optional companion guide add-on.

In practice, EDI 824 is also used as an acknowledgment of EDI 837 Claims, and many state health and Medicaid departments may require EDI 824 as a response from receivers of inbound 837 Claims transactions under set conditions. The mechanics don't change: it's still element-level feedback layered above the 999. If you support both freight and healthcare-adjacent EDI (third-party logistics providers handling pharma distribution do this more than you'd think), the same 824 mapping logic and translator configuration carries across both use cases with different companion guide requirements bolted on.

Should you build 824 support now, or wait until a partner requires it?

Wait until a partner mandates it in their companion guide, or until you're already manually chasing rejected documents by phone or email. Building 824 support speculatively, before you have a concrete trigger, usually means maintaining a transaction set nobody on the other end is actually consuming correctly.

Before you commit engineering time, work through this checklist:

• Confirm whether any current or prospective trading partner's companion guide explicitly requires an 824, rather than assuming it's implied by "we support acknowledgments."
• Map out whether that partner sends coded reason segments or free-text error detail, since that determines whether you can automate resubmission or need a manual review step.
• Decide who owns 824 exceptions internally: EDI team, AP, or the transportation ops desk, since freight and finance rejections often need different people to act on them.
• Test the full resubmission loop end to end, not just 824 generation, since a correctly formatted 824 that nobody actually resubmits against is just noise.
• Check whether your existing translator or connectivity platform already normalizes 824/APERAK content into a readable exception queue before you build custom parsing from scratch.

If you're running EDI across dozens of carriers or suppliers and rejections are currently surfacing as emails and phone calls rather than structured data, that's usually the signal it's time to build. Platforms like Cargoson exist specifically to abstract that exception-handling layer for shippers running multi-carrier EDI, so the 824 becomes a dashboard alert instead of a support ticket. Until you hit that volume or a partner forces the issue, the 997/999 you already have is doing its job.