What Is an EDI 810 Invoice? A Segment-Level Guide
What an EDI 810 invoice is, how its BIG/IT1/TDS segments work, and how it differs from EDI 210 and EDIFACT INVOIC, with a worked example.
What Is an EDI 810?
An EDI 810 is the ANSI X12 transaction set a seller sends to a buyer to request payment for goods shipped or services rendered, functioning as the electronic replacement for a paper, PDF, or emailed invoice. An EDI 810 invoice is an electronic billing document sent by a supplier to a buyer to request payment for goods or services delivered, formatted according to the ANSI X12 standard as the electronic equivalent of a traditional paper invoice.
It doesn't arrive out of nowhere. It is typically sent in response to an EDI 850 Purchase Order as a request for payment once the goods have shipped or services are provided. If you're mapping an 810 for the first time, that PO linkage is the single most important thing to get right, and it's also where most rejections originate.
Where the 810 Sits in the Order-to-Cash Cycle
The 810 is the billing checkpoint in a longer document chain, not a standalone message. It is one step in the order-to-cash cycle, a sequence of EDI transaction sets that automate the full procurement and payment lifecycle, which begins when a buyer sends an EDI 850 purchase order to the seller.
- Buyer transmits the EDI 850 purchase order.
- The supplier sends a 997 acknowledgment to confirm receipt of the order, then fulfills and delivers it to the buyer along with the 810 invoice.
- The 856 Advance Ship Notice usually travels ahead of or alongside the shipment, giving the buyer's system something to reconcile the invoice against.
- Upon receiving the EDI 810, buyers acknowledge it with an EDI 997 Functional Acknowledgement.
- Once the invoice clears validation, the buyer eventually issues payment, often paired with an 820 Payment Order/Remittance Advice.
Notice the acknowledgment loop appears twice: once for the PO, once for the invoice. Skip building the second 997 and you'll have suppliers calling to ask why their invoice "disappeared" into your system.
EDI 810 vs the Documents It Gets Confused With
The 810 is a general-purpose invoice. Several other transaction sets look similar but exist because a plain 810 doesn't carry the right fields for that use case.
| Document | Standard | What it bills | Typical sender |
|---|---|---|---|
| EDI 810 | ANSI X12 | Goods or services against a PO | Manufacturer, distributor, supplier |
| EDI 210 | ANSI X12 | A completed shipment, itemizing the line-haul charge, fuel, and accessorials | Motor carrier |
| EDIFACT INVOIC | UN/EDIFACT | Goods or services (international equivalent of the 810) | Seller, typically outside North America |
Unlike other specialized EDI invoicing documents such as the EDI 210 (freight invoice), EDI 880 (grocery products invoice) or EDI 894, the EDI 810 is a general-purpose invoice that works across industries: retail, manufacturing, distribution, automotive and healthcare. That versatility is exactly why it's the one most mapping teams touch first.
The 210, by contrast, is a different animal entirely. The 810 bills a buyer for goods; the 210 bills a shipper for transporting them, and the 210 carries freight-specific detail, line-haul rate, fuel surcharge, and accessorials, that a goods invoice does not. Don't try to force freight charges into an 810's SAC segment as a workaround. Trading partners that require both documents expect them to arrive separately, from separate systems.
Outside North America, the naming and syntax change entirely. EDIFACT uses letters to define documents while X12 uses numbers, so EDIFACT and X12 use INVOIC and 810 for the invoice, respectively. The underlying business content is nearly identical, but the delimiters, envelope segments (UNH/UNT instead of ST/SE), and qualifier codes are not interchangeable without a translation map.
Two more cousins worth knowing: the EDI 811 Summary Bill provides customers with a broad summary of invoice information, while an EDI 811 Detail Bill provides complete billing information for detailed analysis of service levels and charges, and it's common in telecom and utilities. The EDI 812, meanwhile, is a correction mechanism. The EDI 812 Credit/Debit Adjustment transaction set is used to communicate an adjustment to the charges for products or services, functioning as the equivalent of a paper credit or debit memo. You should use EDI 812 as a stand-alone credit or debit adjustment notification, since this EDI document allows more flexibility for complex billing needs.
Required Segments in an EDI 810
An 810 is built from a fixed set of segments, most of them mandatory in every version from 4010 forward. The core required segments are ISA/GS (interchange and group headers), ST (transaction set header), BIG (invoice number, date, and PO reference), N1 (party identification), IT1 (line-item detail), TDS (total dollar summary), CTT (transaction totals), SE (transaction set trailer), and GE/IEA (group and interchange trailers).
| Segment | Role in the transaction |
|---|---|
| ISA / GS | Interchange and functional group envelope |
| ST | Marks the start of the 810 transaction set |
| BIG | Invoice date, invoice number, PO number, PO date |
| N1 | Buyer, seller, ship-to, remit-to party identifiers |
| ITD | Payment terms |
| IT1 | Line-item quantities, unit price, product/UPC codes |
| TDS | Total invoice dollar amount |
| CTT | Line count and hash total for validation |
| SE / GE / IEA | Trailers closing the set, group, and interchange |
The BIG segment deserves special attention because everything downstream depends on it. The BIG segment opens every 810 transaction with the invoice date, invoice number and the original purchase order number. That purchase order reference is what lets the buyer's AP or ERP system auto-match the invoice to the 850 it already has on file. Get the PO number wrong, or drop a leading zero the buyer's system expects, and the invoice sits in an exception queue instead of a payment run.
Worked Example: A Supplier Billing a Retailer
Real trading partner guides show how thin the actual data footprint can be. Kroger's own implementation guide for a minimum 810 shows the shape clearly: ST*810*0001~ BIG*20210520*5615789**900000004801~ N1*VN*VENDOR NAME*92*123456~ N1*ST*KROGER OCADO - MONROE*9*1178579681001~ IT1**2*CA*9.6**UK*10120009998646~ Strip away the specifics and you can read the whole story: a transaction set opens, the BIG segment carries the invoice number and the PO it references, N1 segments name the vendor and ship-to location, and IT1 segments carry quantity, unit of measure, price, and a UPC.
Big-box retail is where the 810 sees the most volume in North America. Major retailers including Walmart, Target, Amazon, and Home Depot mandate X12 850, 856, and 810 for all vendors. A manufacturer shipping against a Walmart PO will generate the ASN first, then follow with the 810 referencing that same PO number in BIG04, list each shipped SKU in an IT1 loop, and close with TDS carrying the total dollar amount that IT1 lines and any allowances should sum to.
Consolidation rules aren't universal, either. Invoice-to-shipment alignment typically follows one invoice per shipment, though consolidation practices vary by partner relationship. Some retailers want one invoice per PO; others want one invoice per shipment, or a consolidated invoice covering several POs on the same truck. That's a trading partner agreement detail, not something the X12 standard dictates, so check the retailer's implementation guide before you assume.
Where this gets genuinely confusing is freight. If that same shipment involves a motor carrier billing separately for the haul, that's an EDI 210, not an 810, and it runs through an entirely different reconciliation path, usually a TMS or freight-pay system rather than the ERP that's processing the invoice. Carrier-connectivity platforms like Cargoson, alongside tools like MercuryGate, Transporeon, and OrderSync's 210 freight invoice matching, exist precisely because that freight-billing thread needs its own audit trail against the agreed rate, separate from whatever your AP team is doing with the 810.
Frequently Asked Questions
Is an EDI 810 the same as an invoice? Yes, in function. The EDI 810 replaces the need for sending a paper, email, or PDF-based invoice. The content is equivalent; the format and transmission method are what change.
What's the difference between EDI 810 and EDI 210? The 810 Invoice bills the buyer for the goods while the 210 bills the shipper for moving them. They're generated by different parties, for different services, and almost never reconciled against the same system.
Does the EDI 810 replace the EDI 820? No. The 811, 812, and 820 Payment Order/Remittance Advice work together to provide a complete and accurate picture of the invoice and payment processing cycle. The 810 requests payment; the 820, when a partner supports it, is the buyer's response detailing how that payment was applied.
What happens if the 810 doesn't match the PO or ASN? It gets flagged before it ever reaches accounts payable. An error in a single segment, a mismatched PO number, a wrong party ID, a totals discrepancy, can stop payment, trigger a chargeback, and flag your account for audit.
Is EDI 810 used outside the US? Not under that name. ANSI X12 is predominantly used in North America, while EDIFACT is suited for international trade across industries such as automotive, shipping, and global supply chains. The equivalent document abroad is the EDIFACT INVOIC message, carrying the same business intent under a different syntax.
