BGN
Beginning segment: transaction purpose, reference identification, and date.
A business-level accept or reject of a received document, with the reasons, beyond what a 997 can say. Receiver back to sender, for any document that failed or passed application-level checks. This page covers what the 824 is for, the segments you meet when you open one, the documents it travels with, where it tends to go wrong, and how it moves over AS2 into your systems on Files.com, which receives, parses, validates, and routes it as configuration.
No credit card required · 7-day free trial · Live in minutes
The 824 reports what the receiving application did with a document after the translator accepted it. Where the 997 says the syntax was fine, the 824 says the content was, or was not: an invoice rejected because the PO number is unknown, a ship notice accepted with a warning about a quantity, a remittance whose totals do not add up.
It identifies the original transaction, states the result, and lists the errors with codes and free text. Trading partners use it to close the loop on documents that have no natural business reply, and to explain rejections that would otherwise arrive as an email or a phone call days later.
In document order, the segments that carry the 824's meaning. A partner's implementation guide says which are required and which fields each must hold.
Beginning segment: transaction purpose, reference identification, and date.
The parties: who is reporting and who sent the original.
Original transaction identification: the application acknowledgment code (accepted, rejected, accepted with errors), the original transaction set and its control number.
Technical error description: the error code, the segment or element, and free text.
Notes with additional explanation.
Nobody reads them. An 824 rejection that lands in a folder no process watches is a lost document with a receipt attached. The second problem is partners who use the 824 in place of a 997, or vice versa; the trading-partner agreement has to say which acknowledgments are expected for which documents.
The 824 rarely moves alone. These are the documents that precede, answer, or settle it.
The receipt that says an EDI transmission arrived and was parsed, with any syntax errors found.
See The 997The supplier’s bill for goods or services delivered against a purchase order.
See The 810The advance ship notice: what is in the shipment, how it is packed, and how it is labeled, sent before it arrives.
See The 856A payer’s notice of payment: which invoices are being paid, for how much, and how.
See The 820A partner sends the 824 over AS2, SFTP, or FTPS, and it lands in that partner’s inbox folder on Files.com with the transport receipt recorded. From there it is a workflow, not a project: TransformScript parses the X12 natively into the JSON, CSV, or XML your ERP or WMS reads, content validation flags a document whose contents are wrong before anything ingests it, and an automation routes the result to the system and the people who act on it.
Outbound is the mirror image. Your system exports its record, TransformScript builds the 824 the partner’s guide specifies, and the file dropped in the partner’s outbox goes out over AS2 with automatic retries until the MDN confirms delivery. Every transmission in both directions is in the audit log, and delivery monitoring alerts when a 824 that was due never arrives. The full picture is on the EDI software page.
What teams ask about the 824 and how it moves on Files.com.
An EDI 824 is the X12 Application Advice. The receiver of an EDI document sends it to report the business-level result of processing that document, accepted, rejected, or accepted with errors, with the reasons, which the syntax-only 997 cannot express.
The 997 confirms a transmission parsed correctly. The 824 reports what the receiving application concluded about the content: an invoice referencing an unknown PO passes the 997 and fails on the 824.
Yes. Files.com is a standards-compliant RFC 4130 AS2 endpoint, and a 824 sent by a trading partner lands in that partner’s inbox folder with a signed MDN receipt returned to the sender. Partners who exchange over SFTP or FTPS connect to the same platform and the document lands in the same place.
Yes. TransformScript parses the X12 824 natively and writes the JSON, CSV, or XML your systems ingest, as a step in the workflow that fires when the document arrives. Outbound, the same engine builds a 824 from your system’s export and drops it in the partner’s outbox for delivery.
Start the 7-day trial, turn AS2 on, and exchange certificates with your partner. The 824 lands in their folder, parses into the record your system reads, and every transmission carries a signed receipt.
No credit card required • Free for 7 days • Live in minutes