The 810 invoice: where the three-way match happens
The 810 is how you bill Walmart — and it only gets paid cleanly when it agrees with two other documents: the 850 you were sent and the 856 you shipped against. That agreement is the three-way match, and disagreement is a paid-late-or-short outcome.
What's inside an 810
| Segment | Carries |
|---|---|
| BIG | Invoice number + date, and the PO number it bills |
| IT1 | One billed line: quantity, unit price, item identifiers — mirroring the PO's PO1 lines |
| TDS | Total invoice amount (in cents-precision — rounding differences are rejection bait) |
| SAC | Allowances/charges (freight, promo) — where negotiated deductions are declared, not surprised |
| CTT | Line count check |
The matching rules that get invoices rejected
- Bill only what shipped: invoice quantities > ASN quantities is an instant flag — see PO/ASN/invoice mismatches
- Price = PO price: unit-price drift from the 850 (even a cent, even from rounding) creates a discrepancy queue entry
- One PO per 810 unless the guide explicitly allows consolidated billing
- Totals must foot: TDS must equal the sum of lines ± declared SAC amounts
Generating 810s from your billing spreadsheet
Like the ASN, the 810 is mechanical: your billing export already has invoice number, PO, quantities, prices. FluentEDI's generator (in build, same engine as the856 generator) maps those columns once and produces a validated 810 — with the three-way check against the parsed 850 and generated 856 runbefore transmission, because that's exactly the check Walmart's AP system will run after.
Start from the inbound side today: parse your 850s free, and get on the generator waitlist — 810 support ships with it.