The EDI 810, Decoded: What an Invoice Actually Looks Like on the Wire

Every EDI series I write eventually gets to the invoice, because the 810 is where integrations stop being an IT project and start being a money project. A purchase order with a typo is an inconvenience. An invoice with a typo is a dispute, a delayed payment, and — if it drags past the retailer's payment window — a chargeback conversation nobody wants.

Here's what an 810 actually looks like, segment by segment, and where integrations quietly go wrong.

The shape of an 810

The 810 (Invoice) answers the 850 (Purchase Order) and pairs with the 856 (Advance Ship Notice). Together they're the order-to-cash spine of retail EDI: you ordered this, we shipped this, now pay us for this.

The header starts like every X12 transaction:

ST*810*0001~
BIG*20261004*INV-88412*20260928*PO-4471~
N1*ST*ACME DISTRIBUTION*92*ACMEWHSE~
N1*BT*BIGBOX RETAIL*92*BIGBOX01~
ITD*2*10*30~
DTM*011*20261002~

BIG is the beginning segment and it carries the two dates and numbers that matter most: your invoice date and invoice number, plus the buyer's PO date and PO number. Get the PO number wrong — even by one character — and many buyers' systems can't three-way match the invoice against the PO and the receiving record. The invoice doesn't get rejected loudly. It just sits in a queue aging past its discount window.

ITD carries the payment terms: discount percent, days to earn it, net days. This is the segment small suppliers most often hard-code from a spreadsheet that went stale two contract renegotiations ago.

The detail loop: where invoices actually break

Line items live in the IT1 loop:

IT1*1*24*EA*18.50**UP*012345678905*VN*ACME-WIDGET-BLU~
PID*F****WIDGET BLUE 24CT~
TDS*44400~
SAC*A*D240***1500~

A few things worth knowing:

• The buyer item number is not optional decoration. UP (UPC) and VN (vendor number) are how the buyer's AP system matches your line to their item master. Send only your internal SKU and the match fails silently into manual review.
• TDS is the invoice total in implied-decimal cents — 44400 means $444.00. This single field causes a disproportionate share of 810 defects: send dollars-and-cents with a decimal point and some parsers read it as 100× the amount. A $440,000 invoice gets attention, just not the kind you want.
• SAC segments carry allowances and charges — freight, promotional allowances, handling. If it isn't in the 810, the buyer deducts it anyway and you eat a short-pay you can't reconcile.

The part nobody reads: matching

Buyers increasingly run three-way (or four-way, counting the 856) matching automatically. Your 810 is compared against the original 850 prices and quantities, the 856 ship quantities, and the physical receiving record. Tolerances are tight and they're contractual: a price variance of a cent per unit times 10,000 units is a $100 short-pay with a paper trail you have to unwind by phone.

The integration lesson generalizes beyond EDI: the invoice is a claim about three other documents. If your system generates the 810 from the order alone — ignoring what actually shipped — every partial shipment becomes a matching exception. Generate invoices from shipment data, price them from order data, and the exceptions mostly evaporate.

Functional acknowledgments still apply

Like every X12 transaction, the 810 gets a 997 back. An accepted 997 means the file parsed — it says nothing about whether AP will pay it. The real signal is the payment itself (the 820) or, in healthcare, the 835. Teams that treat "997 accepted" as "invoice accepted" discover the difference around day 45.

If you're generating 810s from an API-first stack

You don't need to think in segments all day. You need three things from your tooling: totals computed in integer cents end-to-end, item numbers mapped bidirectionally (yours ↔ the buyer's), and a pre-send validation pass that mirrors the buyer's matching rules — price, quantity, and total tolerances — before the file leaves. That's the difference between an invoice that's a formality and one that's a monthly reconciliation project.

I'm Chris, founder of SignalEDI — we built the platform I wished existed when I was hand-checking TDS totals at midnight. Flat monthly pricing, AI-assisted mapping, and healthcare sets included in every plan.

Tomorrow: the healthcare pair — 837 claims and 835 remittances, and why eligibility (270/271) is the cheapest integration you'll ever build.

— Chris, founder of SignalEDI