Reports data-level errors and business rule violations in received EDI transactions - going beyond the structural acknowledgment of a 997 to tell senders exactly which data values were rejected and why, at the application level.
The EDI 824 Application Advice fills the gap between structural validation (handled by the 997 Functional Acknowledgment) and true application-level processing confirmation. A 997 tells you whether the EDI envelope was syntactically valid - correct segment IDs, proper delimiters, required elements present. But a 997 cannot tell you that the purchase order number you referenced doesn't exist in the buyer's system, or that the UPC you billed for isn't set up in their item master. The 824 handles those business-rule rejections.
When a receiving application processes an inbound EDI transaction and finds data that violates business logic - an unknown item number, an invalid ship-to location, a duplicate document, or a price that doesn't match the contract - it generates an 824 back to the sender describing the error in detail. Unlike the 997 which operates at the functional group/transaction set level, the 824 can pinpoint errors at the individual segment and element level, specifying the exact segment name, element position, loop iteration, and a plain-language description of what was wrong.
The 824 is widely used in healthcare EDI (for HIPAA transaction rejections), retail (for 856 ASN content errors), and financial EDI (for payment rejection notices). The key distinction: receiving an 824 means your document was structurally valid (you got a 997 Accepted) but the application rejected it. Both must be resolved before resubmitting - sending a corrected document without addressing the 824 rejection often results in a duplicate-rejection loop.
Any organization with a sophisticated EDI implementation can use 824 to give senders actionable error feedback. Retailers use it to reject 856 ASNs with unknown items before they hit receiving systems. Suppliers use it to reject 850 POs with invalid ship-to codes. The 824 is the EDI equivalent of an API 422 Unprocessable Entity response.
In healthcare EDI, the 824 is critical for rejecting 837 claims and 820 payment orders at the application level. HIPAA transaction sets generate two levels of acknowledgment: 999 (structural) and 824 (application). A provider may get a 999 Accepted but an 824 Application Error when the claim's procedure code isn't covered under the plan.
Retailers use 824 to reject inbound 856 ASNs where the carton or item data fails business rule validation - unknown GTINs, quantities exceeding PO quantities, invalid SSCC-18 labels, or shipments referencing canceled POs. An 824 rejection before receiving prevents bad data from entering the WMS and causing inventory errors.
Banks and payment networks generate 824s when 820 payment orders contain invalid routing numbers, closed account references, or amounts that exceed transaction limits. The 824 in financial EDI often has regulatory significance - a rejected payment must be re-initiated within prescribed timelines to avoid penalties.
Opens the 824. BGN01 = transaction set purpose code: 00 (original), 11 (response). BGN02 = reference identification (the 824 document number). BGN03/BGN04 = date and time of issuance. BGN05 = time zone code. This segment establishes whether the 824 is a standalone error notice or a direct response to a specific inbound transaction inquiry.
Identifies the specific EDI transaction being reported on. OTI01 = application acknowledgment code: TA (accepted), TR (rejected), E (accepted with errors). OTI02 = reference identification qualifier, OTI03 = the transaction control number from the original document. OTI04/OTI05 = the original ISA/GS interchange and group control numbers for precise document tracing.
Present in some implementations to clarify the business action being taken. BGS01 = status code (AA = accepted, AE = accepted with errors, AR = rejected), BGS02 = reference number (the originating transaction's document ID). Retail implementations often extend this segment with partner-specific codes indicating the reason category for the rejection.
The core error-detail segment. ERR01 = copy of the segment in error (echoes back the segment tag and position), ERR02 = error condition code from X12 standard error code list (e.g., 1 = unrecognized segment ID, 5 = wrong segment order, 8 = segment has data element errors). ERR03 = free text description. Multiple ERR segments can be nested under a single OTI to report all errors in one transaction.
Carries detailed application-level error messages beyond what structured codes allow. TED01 = application error condition code (partner-specific), TED02 = free-form description text up to 264 characters. This is where you get the human-readable explanation: "Item 00012345678901 is not set up in vendor item master for account 12345" rather than just an error code number.
Links the 824 back to the specific document line or element in error. REF01 qualifiers: TX (transaction set ID of the document), SI (service item number referencing the erroneous IT1 line), PO (purchase order number). Including REF segments with loop-level references allows the sender to pinpoint exactly which line item in a 200-line document caused the rejection.
The 997 is the structural acknowledgment that validates EDI syntax. The 824 complements it by addressing application-level rejections. A 997 Accepted + 824 Rejected means: "The envelope was valid, but we can't process the content." Both must be received before a transaction is considered complete.
One of the most common subjects of 824 rejections. An 850 with an invalid ship-to location, unauthorized item, or expired trading partner agreement will generate a 824 from the supplier's order intake system indicating the PO cannot be processed as-is.
Retailers frequently generate 824s for inbound 856 ASNs with content errors - wrong GTINs, SSCC label format violations, quantity mismatches, or unknown carrier SCAC codes. An 824 rejected ASN must be corrected and resubmitted before the shipment can be received in the WMS.
Better EDI handles 824 mapping, testing, and trading partner certification so you don't have to.
Talk to an EDI Expert