X12 transaction guide · Finance
EDI 810 Invoice
The X12 document a supplier sends to bill a customer for goods or services, usually after the order has shipped.
- Sent by
- Supplier or service provider
- Received by
- Buyer (accounts payable)
- Standard
- ANSI ASC X12
- EDIFACT equivalent
- INVOIC
What is an EDI 810?
The EDI 810 Invoice is the ANSI X12 transaction set used to bill a customer electronically. It carries the invoice number and date, references to the purchase order, payment terms, the items or services billed with quantities and prices, allowances and charges, and the total amount due.
Buyers usually match the 810 against the purchase order and the receipt or ship notice before approving payment, a process often called three-way matching. When the invoice does not reconcile, payment is delayed or the invoice is rejected, so generating the 810 directly from ERP billing data is the most reliable approach.
How to read this diagram: the top row shows who sends the 810, to whom, and which documents usually come before and after it. The lower part shows what X12 release 004010 itself requires: the envelopes around the 810 and the segments and loops the standard marks as required, area by area. Optional loops are listed by the segment that starts them rather than drawn in full. This is the standard's minimum, not a trading partner's requirement: each partner's implementation guide usually makes some optional loops mandatory, restricts the codes and may use a different release.
When it is used
- Billing a retailer or distributor after shipping an order
- Invoicing services, freight or other charges electronically
- Supporting automated three-way matching in the buyer's accounts payable
- Replacing paper or PDF invoices for high-volume customers
Where it fits in the document flow
Structure
Key segments in the 810
The segments most implementations use, described in plain language. The last column shows what X12 release 004010 itself requires: "Required" marks a segment the standard requires in every 810; "Optional, common" marks a segment the standard leaves optional, or that sits in an optional loop, but that implementations often use. This is the standard's requirement, not your trading partner's: each partner's implementation guide names the release it uses, makes some optional segments mandatory and restricts the values, and requirements can differ between releases. The requirement status comes from one published X12 reference listing and has not been checked against a second source.
| Segment | Name | What it carries | In X12 004010 |
|---|---|---|---|
| BIG | Beginning Segment for Invoice | Invoice date, invoice number, original purchase order date and purchase order number. | Required |
| N1 loop | Party Identification | Remit-to, bill-to, ship-to and other parties. | Optional, common |
| ITD | Terms of Sale | Payment terms such as discount percentage, discount days and net days. | Optional, common |
| IT1 | Baseline Item Data (Invoice) | One line per billed item with quantity, unit of measure, unit price and identifiers. | Optional, common |
| SAC | Service, Promotion, Allowance or Charge | Allowances, discounts or charges such as freight. | Optional, common |
| TDS | Total Monetary Value Summary | Total invoice amount, expressed with implied decimal places. | Required |
| CTT | Transaction Totals | Number of invoice lines, used as a control total. | Optional, common |
Example
Sample EDI 810
Invoice INV1001 for purchase order PO123456 bills 24 units at 12.50, with terms of 2 percent discount in 10 days and net 30. TDS carries the 300.00 total with two implied decimals.
Illustrative data only, not tied to one X12 release or trading partner. The interchange (ISA/IEA) and functional group (GS/GE) envelopes are omitted for readability.
ST*810*0001~
BIG*20261021*INV1001*20261015*PO123456~
N1*RE*Example Supplier*92*5555~
ITD*01*3*2**10**30~
IT1*1*24*EA*12.50**UP*012345678905~
TDS*30000~
CTT*1~
SE*8*0001~The sample is the same one shown above, with a note beside each segment the first time it appears. Segment IDs are highlighted at the start of each line; the fields after them are separated by asterisks, and each segment ends with a tilde.
Avoid problems
Common 810 errors and how to prevent them
Purchase order reference does not match
The purchase order number in BIG must match the buyer's 850 exactly, or the invoice cannot be matched.
Quantities differ from what was received
Invoicing ordered quantities instead of shipped quantities causes three-way match failures and deductions.
Wrong total format
TDS uses implied decimals. Sending 300.00 as 300 instead of 30000 understates the invoice.
Combining orders or shipments
Some buyers require one invoice per order or shipment. Combined invoices may be rejected.
Trading partners
Integration guides that include the 810
How ECOM helps
Automate the 810 with ECOM
Solution
Financial Document Automation
Automate invoices, remittances, payment files and bank statements from capture to posting.
Solution
Order-to-Cash Automation
Automate the flow from purchase order to payment across every customer channel.
Product
PRISM-SCV
Order lifecycle visibility, response monitoring, routed alerts and business-identifier search across your B2B transactions.
EDI 810 FAQs
When is an EDI 810 sent?
Usually after the goods have shipped or services were delivered, often triggered by shipment confirmation or billing in the ERP.
What is three-way matching?
Three-way matching compares the invoice with the purchase order and the receipt or ship notice before payment is approved.
How is a buyer's payment communicated?
Many buyers send an 820 payment order/remittance advice that lists the invoices paid and any deductions.
What is the EDIFACT equivalent of the 810?
The UN/EDIFACT equivalent is the INVOIC message, used widely by European and international trading partners.
More general questions about EDI are answered in the EDI FAQ.
Need help with the EDI 810?
ECOM maps, tests and monitors X12 documents for your trading partners and integrates them with your ERP.