EDI 810 validation is a three-way money-path reconciliation

An invoice can be structurally valid and mathematically balanced while billing the wrong item, purchase order, quantity, unit, party, or shipment. The safe gate joins the invoice to procurement and fulfilment evidence before transmission.

Direct answer: Resolve every 810 line to the active purchase order and eligible shipped quantity, subtract prior invoices and credits, verify product identifiers and units, independently recalculate prices, charges, allowances, tax and totals, validate controlled party and payment data, enforce invoice-ID uniqueness, and keep monitoring after technical acceptance.

Eligible-to-bill ledger

For every PO item, calculate:

eligible to bill = accepted and shipped quantity
                 - quantity already invoiced
                 + valid reversed or credited quantity

Claim eligible quantity atomically when an invoice is created. A timeout followed by retry must not create a second financial claim. If the channel supports correction using the same identity in a documented case, model that as a state transition instead of issuing an arbitrary duplicate.

Checks before serialization

• Invoice number is unique under the documented correction policy.
• Invoice date is valid and not in the future where prohibited.
• PO, item identifier, and unit match the order source.
• Quantity does not exceed eligible shipped quantity.
• Unit price and payment terms match the commercial agreement.
• Each line extension is recalculated from quantity and price.
• Charges, allowances, tax, subtotal, and total reconcile independently.
• Header tax equals the appropriate aggregation of detail tax.
• Remit-to, ship-to, and bill-to values come from controlled current master data.
• A zero invoice total is rejected where Amazon documents it as invalid.

Amazon’s current Vendor Invoices guidance also notes parallel testing, item-identifier matching, total and tax consistency, party-address requirements, and the distinction between successful submission and later rejection.

Why an acknowledgement is not payment status

A 997 or accepted API response proves only the state it explicitly describes. Amazon documents asynchronous transaction status and notes different success behavior by operation. Keep four separate facts:

1. bytes transmitted;
2. translator or API request accepted;
3. downstream invoice accepted into the payee workflow;
4. payment or deduction reconciled.

An expected-state watchdog should alert when a technically accepted invoice never progresses by its normal operational deadline.

Adversarial tests

• two concurrent invoices claim the same shipped quantity;
• timeout after upstream success followed by retry;
• price or unit differs from the active PO;
• line totals add correctly but header tax does not;
• invoice bills an ASN replacement plus the superseded ASN;
• corrected invoice identity used in a case where a new identity is required, and vice versa;
• valid party name with an address that does not match controlled master data;
• technical acknowledgement accepted, downstream status later failed.

Support boundary

Shipment Sentry’s live EDI 810 validator checks the X12 envelope, controls, transaction identity, segment counts and high-value invoice anchors. It does not yet automate the complete PO-to-shipment-to-invoice money path described above or claim licensed partner conformance. Exact requirements remain guide, account, region, tax and licence dependent.