EDI 810 (Invoice)
EDI 810 is the ANSI X12 transaction set for an electronic invoice — a supplier's request for payment, sent after goods ship or services are delivered, most often in direct response to the EDI 850 purchase order that started the order. It carries the invoice number and date, line-item quantities and prices, and payment terms, and on most trading-partner setups it is followed by a 997 functional acknowledgment and, eventually, an 820 remittance advice recording how the buyer paid it.
What EDI 810 actually is
EDI 810 is the X12 transaction set (functional group code IN) that replaces a paper or PDF invoice with a structured electronic document. A supplier sends it to a buyer, typically after the goods have shipped or the service has been rendered, as a formal request for payment.
Most trading relationships generate an 810 off the back of an EDI 850 purchase order: the PO number and date travel through the invoice so the buyer's accounts payable system can tie the bill back to the order that authorized it. Where an EDI 856 Advance Ship Notice preceded the shipment, AP systems often run a three-way match — PO, ASN/receipt, and invoice — before releasing payment, which is why an 810 that doesn't reference the right PO number or ship quantity routes straight to an exceptions queue instead of paying automatically.
The segments that carry the invoice
An 810 is built from a small set of segments, and most disputes trace back to one of them:
- BIG (Beginning Segment for Invoice) — the invoice number and date, and the purchase order number and date it's billing against.
- IT1 (Baseline Item Data) — one occurrence per line item: item number, quantity invoiced, unit price, and the identifiers (UPC, buyer's item number, vendor part number) that tie the line back to a catalog record.
- TDS (Total Monetary Value Summary) — the invoice total, expressed with implied decimals in the raw EDI (1200 means $12.00).
- SAC (Allowance, Charge, or Service) — optional allowances, charges, or freight added at the summary or line level; many trading partners only accept a narrow set of SAC codes and reject the rest.
Trading-partner implementation guides vary on which of these are required, which codes are valid, and whether credit invoices use a different BIG07 value than standard invoices — the base X12 standard sets the segment structure, but the retailer or distributor's own guide sets the rules an 810 actually has to pass.
Why 810s fail to auto-match
A three-way match compares the invoice against the PO it cites and the ASN or receipt for the same shipment. It fails, and the invoice stalls for manual review, for a short list of recurring reasons: the invoiced price doesn't match the price the buyer has on file (often because a price change sent as an EDI 832 never made it into the buyer's system), the item number on the IT1 line doesn't match the identifier on the original PO or the catalog record behind it, the quantity invoiced is higher than the quantity shipped or received, or the PO number is missing, mistyped, or references an order that's already closed.
None of these are EDI problems in the narrow sense — they're product and pricing data problems that happen to surface as a rejected invoice. A catalog where item numbers, units of measure, and current pricing are consistent across the PIM, the ERP, and the EDI feed is what keeps 810s matching without a human in the loop.
Frequently asked questions
What's the difference between EDI 810 and EDI 850?
EDI 850 is the purchase order — the buyer telling the supplier what to ship. EDI 810 is the invoice — the supplier telling the buyer what to pay, sent after the order has been fulfilled. They travel in opposite directions and at opposite ends of the transaction.
Does an EDI 810 always reference a purchase order?
In most B2B trading relationships, yes — the BIG segment carries the PO number the invoice is billing against, which is what lets the buyer's AP system match it automatically. Some service or non-PO invoices omit it, but then the invoice has to be matched and approved manually rather than cleared by a three-way match.
What is a three-way match in EDI invoicing?
It's an automated comparison of the purchase order (850), the shipment notice or receipt (856 or a dock receipt), and the invoice (810) before payment is released. If the item numbers, quantities, and prices agree across all three, the invoice pays without a person touching it; any mismatch routes to an exceptions queue.
What EDI document typically follows an 810?
A 997 functional acknowledgment confirms the invoice was received and syntactically valid. Later, an 820 remittance advice tells the supplier how and when the buyer paid it — in full, in part, or with deductions.