What Is an EDI Invoice? The EDI 810 Format, Explained Line by Line

Why listen to us: ECIT Digital turns the invoices that do not arrive as clean data, the PDFs and the paper, into structured data for your ERP, with 99.8% accuracy guaranteed. We spend our days on the other side of the EDI fence.

The first time I opened a raw EDI file, I assumed my cat Pixel had walked across the keyboard [she had not, she was asleep on the printer, judging me]. Rows of asterisks, tildes and codes like BIG and TDS, with not a single friendly word in sight.

It turns out that wall of asterisks is one of the most efficient invoices ever invented. This guide explains what an EDI invoice is, how the EDI 810 format works, and walks through a real-looking example line by line, so you never have to blame the cat again [sorry, Pixel].

EDI invoice vs e-invoice vs PDF, at a glance

Three kinds of "electronic" invoice, and only two of them are what a computer would call electronic [the PDF knows what it did].

What is an EDI invoice?

EDI stands for electronic data interchange: two companies' systems exchanging business documents in an agreed, structured format. The invoice is one of those documents, and it is the one finance cares about most, because it has a dollar sign on it.

In North America, EDI invoices follow the ANSI X12 standard, where the invoice is transaction set 810. X12 describes it as covering "the billing for goods and services provided", which is standards-body for "bills" [they bill by the syllable].

Outside North America, the common standard is UN/EDIFACT, where the invoice is the INVOIC message, defined as "a message claiming payment for goods or services supplied under conditions agreed between the seller and the buyer". IBM puts the split simply: X12 is "most common in North America", while EDIFACT is the international set.

X12 is not a niche thing either. It offers "more than 320 transaction standards", so the 810 is just one member of a very large, very asterisk-heavy family.

Where the EDI 810 fits in the order flow

An EDI invoice rarely travels alone. It is usually the fourth message in a conversation that started with a purchase order, like the third act of a very boring play [the PO is the hero].

The 810 is matched against the 850 and the 856. That is two-way or three-way matching done by machines, which our guide to purchase orders vs invoices explains for the humans.

EDI invoice format: the segments that matter

An EDI 810 is built from segments, one per line. Each starts with a short code, and elements inside it are separated by asterisks [the asterisks are load-bearing, do not remove them].

Every big buyer publishes its own guide on top of the standard, saying which segments are required and how to fill them. Read your buyer's guide first, because "we followed the standard" has never once gotten a rejected invoice paid.

EDI invoice example, line by line

Here is a short, simplified EDI 810 for two line items. I built it in the X12 4010 style, then checked the math twice, because Pixel will not do it for me.

That TDS line trips everyone up once. In this guide's convention the total has two implied decimals, so 34990 means $349.90, while the unit prices in IT1 carry an explicit decimal point. A published trading partner guide shows the same pattern: TDS*2999 for a $29.99 invoice [nobody panics about the $2,999 invoice, except everybody, once].

Whether amounts carry implied decimals depends on the element and your partner's guide, so check it. Pixel checked nothing, and she has never been paid.

How EDI invoices are sent

Writing the 810 is half the job. The other half is getting it to the buyer, which happens through one of three pipes [none of them involve a fax, you are welcome].

IBM describes a VAN as one where "a third-party network manages the data transmission". AS2 is an internet standard, RFC 4130, which "describes how to exchange structured business data securely using the HTTP transfer protocol".

Why EDI invoices get rejected

EDI is fast, which also means it rejects you fast [faster than Pixel rejects a new brand of cat food]. Most rejections come from a short list.

Retailers back their guides with fees. The Designer Brands (DSW) vendor policy, for example, lists "No/Late/Unusable EDI Functional Acknowledgement (997) transmission $250 per EDI message", and $150 per occurrence for multiple invoices per PO or shipment.

EDI invoice processing on the receiving side

For the buyer's AP team, EDI invoice processing is wonderfully boring, which is the highest compliment in accounts payable.

The catch is the word "mapping". Each new trading partner needs its own setup, which is why EDI is common between big partners and rare with small suppliers [the small supplier is still emailing you a PDF, right now].

If you are rolling out automation across all of AP, not just EDI, our guide to accounts payable automation best practices covers the order to do it in.

EDI vs e-invoicing networks like PEPPOL

EDI is not the only way to send structured invoices any more. E-invoicing networks let you connect once and reach everyone else on the network, instead of mapping partner by partner [like a group chat, but for invoices, and with fewer memes].

In Europe, "Peppol is not a portal, or a provider of exchange services. Peppol is an enabler", using a four-corner model where buyers and suppliers each connect through an accredited service provider. In the US, the Federal Reserve describes the e-invoice exchange framework as "a set of standards, policies and guidelines enabling businesses to connect once", now run by the Digital Business Networks Alliance.

The volume is real. Billentis estimates that "In 2026, around 87 billion B2B e-invoices were issued worldwide". Read our guides to what an e-invoice is and e-invoicing vs traditional invoicing if PEPPOL is new to you.

What about suppliers who cannot send EDI?

Here is the part the EDI vendors skip: many of your suppliers will never send you an 810. They are too small, the setup is too expensive, or they simply like PDFs [some suppliers love PDFs the way Pixel loves the printer].

Those invoices still need to end up as clean, structured data in your ERP, ideally in the same shape as your EDI invoices. That is where invoice capture comes in: the PDF is read, the fields and line items are extracted, checked, and delivered.

And for suppliers ready to go structured without EDI, PEPPOL e-invoicing gives them a network route instead of a partner-by-partner one. Between EDI for the big partners, PEPPOL for the willing and capture for everyone else, every invoice can arrive as data.

As for Pixel: she still walks across my keyboard, but now I can tell her work from a real EDI file. Hers has no TDS segment, and frankly no respect for implied decimals [she is a cat, she does not do decimals].