EDI 810 Invoice Format Explained

An EDI 810 is the electronic invoice in the ANSI ASC X12 standard. It carries the same information as a paper invoice, the vendor, the invoice number, the purchase order it bills against, the line items, and the total, but as a structured data file that the buyer's system reads without a person. It is sent after goods ship, it references an EDI 850 purchase order, and in US retail and distribution it is usually a condition of doing business.

Last updated July 2026.

If a large customer has sent you a document called an EDI implementation guide and mentioned chargebacks in the same email, the 810 is what they are talking about. This guide covers what the transaction set contains, the segments that carry the data, a worked example you can read, the errors that cost suppliers money, and what to do about the invoices that never arrive as EDI at all.

What is an EDI 810?

The 810 is the Invoice transaction set within ASC X12, the EDI standard maintained by the Accredited Standards Committee X12. It is the electronic equivalent of the invoice a supplier would otherwise print and mail. The seller generates it after shipping, transmits it to the buyer, and the buyer's ERP posts it, matches it against the purchase order, and schedules payment.

The word "transaction set" matters. The 810 is not a file format in the way a PDF is. It is a defined sequence of segments and data elements, wrapped in interchange and functional group envelopes, that both trading partners have agreed to interpret the same way. The standard tells you a BIG segment exists. Your customer's implementation guide tells you exactly which elements within it they require.

What does the EDI 810 stand for and where does it sit?

810 is simply the number X12 assigned to the invoice. It sits near the end of a document chain that starts with an order and finishes with a payment.

An 810 that does not reference a valid 850 has nothing to match against, which is the first place these files fail. On the buyer's side the 810 feeds straight into invoice matching, where it is compared against the purchase order and the goods receipt before anyone pays it.

What segments are in an EDI 810 invoice?

Segments are the lines of the file. Each starts with a two or three character identifier and holds data elements separated by a delimiter. These are the ones you will meet in almost every implementation.

What does an EDI 810 look like?

Here is a single-line invoice, using the asterisk as the element delimiter and the tilde as the segment terminator, which is the most common pairing.

ST*810*0001~
BIG*20260701*INV12345*20260615*PO98765***DI~
REF*VN*ACME-SUPPLY~
N1*BT*NORTHEAST DISTRIBUTORS*92*0001234~
N1*RE*ACME SUPPLY CO*92*ACME01~
ITD*01*3*2**10**30~
IT1*1*500*EA*12.40**VP*ACME-1200*UP*012345678905~
TDS*620000~
CTT*1~
SE*10*0001~

Read it left to right. BIG says the invoice is dated 1 July 2026, is numbered INV12345, bills against purchase order PO98765 dated 15 June 2026, and is a debit invoice. ITD expresses 2/10 net 30 terms, the same discount you would print in words on a paper invoice. IT1 bills 500 each at $12.40 with both a vendor part number and a UPC. TDS carries the total as 620000, because X12 implies two decimal places, so the invoice is for $6,200.00. CTT confirms there was one IT1 segment.

Two things trip people up. Amounts have no decimal point and no dollar sign. And the transaction type code in BIG07 is what separates an invoice from a credit memo, so the same 810 structure carries both, which is worth remembering when you are reconciling a vendor account and wondering why the credit memo never appeared as its own document type.

What is the EDI 810 format?

It is plain text. Delimiters are declared in the ISA envelope rather than fixed by the standard, so one partner may separate elements with an asterisk and another with a pipe. Versions matter as much as delimiters: 004010 and 005010 are the two X12 releases you will see in the wild, and a guide written for one will not validate against the other. When a customer sends you a specification, the version number on the cover page is the first thing to check.

Who requires EDI 810 invoices?

Large retailers, grocery and pharmacy chains, distributors, automotive manufacturers, and the healthcare supply chain. If you sell into a big-box retailer, EDI is not optional and neither is the 856 advance ship notice that precedes the invoice. The requirement flows from the buyer, who publishes a partner specification and expects you to conform to it, not the other way around.

Suppliers typically connect through a value added network or an EDI service provider that translates between the X12 file and their accounting system. Direct connections exist, but the mapping work is real and each new trading partner adds another map, because every buyer interprets the optional elements differently.

Why do EDI 810 invoices cause chargebacks?

Because a retailer that automates its receiving also automates its deductions. Common causes, in rough order of how often they show up:

• The invoice does not reference a valid PO number, so nothing matches and the invoice is rejected via an 824.
• Quantities billed exceed quantities received, usually because the shipment was short and the invoice was generated from the order.
• Unit of measure mismatch: the PO is in cases, the 810 bills in each.
• Price variance against the price on the purchase order, even by a cent on a high-volume line.
• Missing UPC or a wrong vendor part number, which stops the line from resolving to an item.
• Late transmission against a partner rule that requires the invoice within a set number of days of shipment.

None of these are EDI problems. They are data problems that EDI makes visible immediately instead of six weeks later, which is exactly why buyers like it. The same failure modes appear in the invoice exception queue of any AP department that matches invoices to purchase orders.

How does accounts payable process an incoming EDI 810?

The file lands through the VAN, the translator maps it into the ERP as an unposted invoice, and the ERP runs the match against the purchase order and the receipt. A clean match posts the invoice with no human involvement. A failed match becomes an exception with a coded reason. From there the invoice follows the same path as any other bill: it gets coded, approved if required, and picked up by the next payment run. The buyer normally returns a 997 to confirm receipt and, if the invoice is rejected, an 824 explaining why.

The 810 arrives as data, which is why it never touches an AP clerk. That is the entire argument for EDI, and it is the same argument for e-invoicing on the Peppol network, which achieves the same outcome with a different technology and a single connection instead of one per partner.

What about suppliers who do not use EDI?

They are the majority. A typical US mid-market company has a handful of trading partners on EDI and several hundred suppliers who email a PDF, and the PDFs are where the AP headcount goes. Those documents contain the same fields the 810 carries, just laid out for a human instead of a parser.

The practical answer is to extract them. Run the PDF, scan, or photo through an extractor that returns the vendor, invoice number, PO reference, dates, terms, taxes, totals, and every line item as Excel, CSV, or JSON, and post that through the same import route your EDI invoices use. The ledger stops caring which channel the invoice arrived on. The same discipline applies upstream: teams that keep their purchase orders in one system rather than scattered across email give the match something reliable to compare against, whether the invoice arrived as an X12 file or an attachment.

EDI 810 vs e-invoicing: are they the same thing?

EDI is one way of doing e-invoicing, and in the United States it is the dominant one. The difference is topology. EDI is bilateral: you agree an implementation with each trading partner, and adding a partner means new mapping work. Network e-invoicing, as run by Peppol internationally and by the DBNAlliance in the US, is designed so a single connection to an access point reaches every participant on the network. Both deliver structured invoice data. Neither helps with the supplier who sends a PDF, which is why invoice data extraction and EDI sit side by side in most AP departments rather than replacing one another.

Frequently asked questions about the EDI 810

Is an EDI 810 the same as an invoice? Yes. It is the invoice, expressed as an X12 transaction set rather than a document. It carries the invoice number, date, purchase order reference, line items, terms, and total.

What is the difference between an 810 and an 850? The 850 is the purchase order the buyer sends. The 810 is the invoice the supplier sends back after shipping. The 810 references the 850, which is what allows the buyer to match them. The relationship between the two documents is the same one described in purchase order vs invoice.

What is an 810 in accounting terms? It is an accounts payable document on the buyer's side and an accounts receivable document on the seller's side, exactly like a paper invoice. It creates a liability when posted and clears when paid.

Can you convert an EDI 810 to Excel? Yes, EDI translators do this routinely, and the file is machine readable to begin with. The harder direction is the one most AP teams need: turning a PDF invoice into the same structured columns an 810 would have produced. That is a data extraction problem, not an EDI one, and it is handled by line item extraction.

Do small businesses need EDI? Only if a customer requires it. The cost of an EDI provider and the mapping work rarely pays for itself below a few hundred transactions a month with a single partner. Most small suppliers adopt EDI because a large buyer made it a condition of the contract.