Logistics and distribution
EDI transaction histories (204, 214, 210, 856): what they show AI teams
By SourceX Editorial · Updated
Short answer
An EDI transaction history is the archive of documents a company exchanged with trading partners, such as 204 load tenders, 214 status messages, 210 freight invoices and 856 advance ship notices. One message says little. Linked by shipment or order reference, the history shows the plan, what happened and what was billed, the sequence AI teams value.
Key takeaways
- A 204, 990, 214 and 210 chain for one load shows the tender, the acceptance, the movement and the bill in order.
- An 856 advance ship notice becomes useful when matched to the purchase order before it and the receipt and invoice after it.
- Raw X12 files keep detail that ERP and TMS integration tables often drop, such as segment codes, control numbers and failed messages.
- Partner identities, consignee addresses and contract rates sit inside EDI segments and are handled in rights review and preparation.
What do the 204, 214, 210 and 856 transaction sets record?#
The 204, 214, 210 and 856 are ANSI X12 transaction sets that record the core events of moving goods: the load tender, shipment status, the freight invoice and the advance ship notice. Each is a structured message with defined segments, so the same fields appear in the same place across years and trading partners.
On their own, these messages are routine paperwork. Their value appears when related sets are linked through a shared reference such as a shipment ID, bill of lading number, PRO number or purchase order number, because the link turns separate documents into a timeline.
| Transaction set | What it records | What a linked history shows |
|---|---|---|
| 204 Motor Carrier Load Tender | A shipper's or broker's offer of a load: stops, dates, equipment and references | Which loads were offered to which carriers, and how plans changed through updates and cancellations |
| 990 Response to a Load Tender | The carrier's acceptance or decline | Acceptance patterns by lane, season and notice time |
| 214 Shipment Status Message | Events such as pickup, in transit, delay with a reason code, and delivery | Planned versus actual timing, and which delay reasons came before late deliveries |
| 210 Freight Details and Invoice | Line haul, fuel and accessorial charges billed for the shipment | Where billed charges departed from the tender, and which accessorials were disputed |
| 856 Ship Notice/Manifest | What shipped: packs, pallets, items, quantities and labels | Gaps between what was announced and what the receiver counted |
| 997 Functional Acknowledgment | Whether the partner's system accepted or rejected a message | Where transactions failed and how errors were corrected |
Why does a linked history matter more than single messages?#
A linked history matters because AI teams learn from the difference between what was planned and what happened, and that difference only shows when documents are joined. A 204 says a load should deliver on a given date; the 214 messages say when it did; the 210 says what it cost; a short payment or a dispute says who was right.
On the distribution side, the same logic runs from the 850 purchase order to the 856 ASN, the warehouse receipt, the 810 invoice and the 820 remittance. A receiving discrepancy, a deduction or a chargeback closes the loop and labels the outcome.
Unlinked archives lose most of that signal. A folder of 214 files with no tender or invoice behind them can describe traffic, but it cannot show whether a delay changed the bill or how the team responded.
Where EDI histories are stored, and what each copy keeps#
EDI histories are usually spread across more than one system, and each copy keeps different detail. Knowing which copy survives decides what can be reconstructed later, so the IT director should map them before any translator, VAN or ERP change.
Retention varies by provider and plan, so check the documentation and the contract for each copy. If raw files exist only at the VAN or managed EDI provider, export them before the subscription ends or the provider changes.
- Translator or EDI platform archives: raw X12 files with envelopes, control numbers and every segment as sent or received.
- VAN or managed EDI provider mailboxes and portals: message copies and delivery logs, often kept only for a limited period under the service agreement.
- ERP, TMS and WMS integration tables: parsed fields mapped into orders, loads and invoices, with unmapped segments usually dropped.
- Error and acknowledgment logs: 997 or 999 results, rejected files and reprocessing notes.
- Email and shared drives: manual corrections, partner emails about failed documents and the spreadsheets used to fix them.
What AI teams can learn from transportation and ASN histories#
AI teams use EDI histories to train and test systems that read structured business documents, predict exceptions and check invoices. The fixed format makes the records easy to parse, and the linked outcomes make them useful for evaluation, because a model's answer can be compared with what actually happened.
Workflow and computer-use agents are another use. An agent that handles tracking updates or freight invoice audit needs examples of the documents a human analyst actually saw and the decisions made after seeing them.
| Question an AI system works on | Transaction sets that answer it |
|---|---|
| Will this load deliver late? | 204 plan, 214 status sequence and the delivery outcome |
| Is this freight invoice correct? | 204 or rate confirmation, 210 charges, and the payment or dispute record |
| Which accessorials are likely to be disputed? | 210 accessorial lines with dispute and credit outcomes |
| Will this receipt match the ASN? | 850 order, 856 ASN and the receiving discrepancy record |
| How should a failed document be fixed? | 997 or 999 rejection, corrected resend and partner correspondence |
What to check before treating EDI history as licensable#
EDI history is licensable only after a rights and privacy review, because the messages contain other companies' identities and terms. Trading partner agreements, carrier contracts and shipper agreements may restrict the use or disclosure of transaction data, and those terms differ partner by partner.
Preparation usually replaces party identities with consistent tokens, so a lane or partner can still be followed across messages without being named. Rates may be removed, grouped into ranges or kept, depending on the agreements and the buyer's intended use.
- Trading partner agreements and EDI implementation guides that mention confidentiality or data use.
- Party identities in N1 loops and envelope sender and receiver IDs, which name shippers, consignees and carriers.
- Residential ship-to names and addresses, which are often personal information.
- Contract rates and accessorial schedules in 210 messages and rate-bearing 204 tenders.
- Retailer or client data inside 856 ASNs that a 3PL processed on a client's behalf.
Illustrative: a regional carrier finds its EDI archive#
Illustrative: a fictional regional truckload carrier receives 204 tenders from shippers and brokers and sends 990, 214 and 210 messages back through an on-premises translator. Its TMS stores loads and stops but keeps only the latest status for each load.
The IT director discovers that the translator has kept raw inbound and outbound files on a file server since the last TMS change. Using the shipment ID and PRO number, the team joins tenders, status messages and invoices into one timeline per load and links short-paid invoices from the accounting system.
The carrier scopes a possible package around complete tender-to-payment chains only. Shipper and consignee names are tokenized, and rate fields are held back until counsel finishes reviewing its largest shipper agreements. Loads with missing links are left out rather than patched.
How SourceX approaches EDI archives#
SourceX starts with metadata: which transaction sets exist, roughly which years are accessible, whether raw files or only parsed tables survive, and how documents link. No files are shared during that fit check.
If the archive proceeds, the SourceX five-step transaction moves it through Supply, Rights, Preparation, Approval and Delivery. The SourceX Evidence Packet records the archive's provenance, the trading partner terms reviewed, the permitted use, the privacy record for party and address data, and the company's release authorization.
Frequently asked questions
Do we need the raw X12 files, or is parsed ERP data enough?
Parsed data is often enough to analyze loads and orders, but raw files keep detail that mappings drop, such as segment codes, control numbers and messages that failed to load. Keep raw files when they still exist, since they are the most complete record of what partners actually sent.
Does EDIFACT or API-based exchange count the same way?
Yes. EDIFACT messages such as DESADV, the counterpart to the 856, and API events from carriers or visibility platforms record the same kinds of events. What matters is whether the messages are retained, time-stamped and linkable to orders, shipments and invoices.
Who owns EDI messages exchanged with a trading partner?
Both parties usually hold copies, and ownership is often not spelled out. Use may be governed by the trading partner agreement, the underlying commercial contract and any confidentiality terms. Those documents should be reviewed before EDI history is used for anything beyond the original transaction.
Are 997 acknowledgments worth keeping?
Usually, yes. Acknowledgments show which documents were accepted or rejected and when, and rejections paired with corrected resends show how errors were fixed. That makes them useful for exception analysis and for testing automated document handling.
Will AI agents make EDI history irrelevant?
Not the history itself. Even if new exchanges move to APIs or agents, past EDI records remain a structured account of how orders, loads and invoices actually behaved, which is exactly the kind of record used to test new automation before it goes live.
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.