Implementation reference
EDI document reconciliation catches what syntax validation cannot
The commercial workflow has a conservation rule: the supplier should not accept more than the active order, ship more than accepted, or bill more than eligible shipment evidence. Corrections, partial fulfilment, cancellations, credits, and retries complicate that rule, but they do not remove it.
Direct answer: Normalize every 850, 855, 856, and 810 into versioned business records; join them by partner, PO, qualified item, shipment, and invoice identity; use atomic reservations for accepted, shipped, and billed quantities; preserve corrections as state transitions; and surface every unexplained difference in one exception queue.
The quantity ledger
For one PO line, retain these totals and their source events:
current ordered
accepted / rejected / changed
reserved for shipment
shipped / reversed
eligible to bill
invoiced / credited
received or disputed (when available)
The invariant is more useful as an event-backed ledger than a collection of mutable counters. It must answer not only “what is the remaining quantity?” but “which document and state transition created that answer?”
Stable matching keys
Use explicit, qualified identities:
- partnership and vendor code;
- purchase-order number and revision/change state;
- buyer item, vendor item, GTIN/UPC, and their qualifiers;
- shipment identity and replacement state;
- carton/pallet/container identity;
- invoice identity and correction state.
Never join primarily on descriptions, filenames, line order, or a value whose qualifier was discarded during mapping.
Concurrency controls
Two warehouse jobs can try to ship the same remaining quantity. Two invoice workers can try to bill the same shipment after a timeout. Use an atomic database claim or reservation rather than read-modify-write application logic.
The outbound document should reference the reservation version. If serialization or transmission fails, release or retry through a named state transition. If the remote side may have succeeded, reconcile before creating a new business identity.
Exception classes
| Difference | Default action |
|---|---|
| 855 accepts above current 850 | block acknowledgement |
| 856 ships rejected/cancelled line | block dispatch |
| cumulative 856 above accepted | block dispatch and review prior replacements |
| 810 above eligible shipped | block invoice |
| unknown item identifier | quarantine; do not guess |
| technical accepted, business stalled | alert and investigate status |
| physical receipt differs | preserve evidence; route operational dispute |
Each exception needs the two source values, exact locations, version timestamps, evidence links, and a prescribed next action. “Documents differ” is not sufficient for an operator.
Why this is defensible
Basic parsing is increasingly commoditized. A durable product accumulates partner profiles, anonymized failure fixtures, source-system connectors, exception-resolution patterns, and measured outcomes. Cross-document reconciliation sits above any one syntax, which means the same engine can support X12, Amazon API JSON, and later EDIFACT messages.
Test properties
- accepted quantity never exceeds the active ordered quantity;
- cumulative shipped quantity never exceeds eligible accepted quantity;
- cumulative billed quantity never exceeds eligible shipment quantity;
- retries do not consume quantity twice;
- a correction cannot silently erase evidence used by a completed downstream document;
- concurrent claims cannot both succeed for the same remaining amount;
- every exception resolves to exact source records and locations;
- no raw EDI payload is required in analytics or operational alerts.
Primary sources
- developer-docs.amazon.com ↗
- developer-docs.amazon.com ↗
- developer-docs.amazon.com ↗
- developer-docs.amazon.com ↗
Public sources cannot establish every account-specific EDI rule. Current Vendor Central documentation and your trading-partner agreement remain controlling.