An e-invoice is not a PDF. It is a structured data file a buyer's system can read without a human, exchanged over a network like Peppol or an EDI connection. This page explains what qualifies, which standards and mandates matter to a US business in 2026, and what to do about the majority of your supplier invoices that still arrive as email attachments. Upload one to see it turned into structured data now.
Upload your invoices
Drop files here or click to upload
Up to 50 files
Uploading...
Electronic invoicing has been the future of accounts payable for two decades, and most US AP teams still open PDFs in an email inbox every morning. Both things are true at once. Your largest trading partners may send structured EDI 810 invoices. A handful of European subsidiaries may be legally required to exchange e-invoices next year. Everyone else emails you a PDF, and that tail is where the work is.
Regulators, Peppol, and EDI all define an e-invoice as machine-readable structured data. A PDF is an image of an invoice with text laid on top. It still has to be read by a person or by software before anything can be posted.
The EDI invoices from the big vendors post automatically. The PDF invoices from the other 400 suppliers get keyed. The month-end numbers depend on both, and only one of them is controlled.
Onboarding a supplier to EDI or Peppol is a project. A 12-person contractor who invoices you twice a year will not do it, and no procurement policy has ever changed that.
There is no US federal B2B e-invoicing mandate. There is one for federal contractors, and there are hard deadlines in Germany, France, Italy, and Poland that reach any US company with an entity or a customer there.
EN 16931, UBL 2.1, UN/CEFACT CII, Peppol BIS Billing 3.0, ASC X12 810, ZUGFeRD, Factur-X. They overlap, they are not interchangeable, and your ERP supports some subset of them.
Treat e-invoicing as the channel you use where it exists and where the law requires it, and treat document extraction as the channel that covers everything else. Structured invoices from a network flow straight into the ERP. PDF and scanned invoices go through an extractor that turns them into the same structured fields, so the ledger sees one consistent stream. The tool at the top of this page does the second half.
Peppol and EDI exchanges deliver invoices as validated XML or X12 documents through an access point or a VAN, with no document to read.
Formats like ZUGFeRD and Factur-X embed an XML invoice inside the PDF, so a human sees a document and a machine reads the data. Adoption is mostly European.
Still the default for most US suppliers. AI extraction pulls the vendor, invoice number, dates, PO reference, totals, taxes, and every line item into structured data.
A scanned or photographed invoice carries no data at all. Extraction handles it identically, which is what makes a single AP workflow possible.
If you have a European entity, the receiving obligation usually arrives before the issuing obligation. Knowing which of your entities is in scope is a finance decision, not an IT project.
Excel, CSV, or JSON out of the extractor, so PDF invoices land in the same import routine as your structured e-invoices.
Almost no US company can switch every supplier to a network. The realistic plan has three moves.
A small number of vendors usually send the majority of invoices. Those are the ones worth an EDI or Peppol connection. The long tail never will be.
US federal contractors already invoice electronically through the Treasury Invoice Processing Platform. Entities in Germany, France, Italy, and Poland face dated national obligations. Everything else in the US is voluntary today.
Tip: The obligation to receive an e-invoice almost always lands before the obligation to issue one.
Run the emailed PDFs and scans through extraction so they produce the same fields as the structured invoices, and post both through one import.
The obligation and the opportunity land on different desks.
You receive both channels. The e-invoices post themselves. Your headcount is set by the PDFs.
A US parent with a German or French subsidiary inherits that country's e-invoicing calendar, whatever the US position is.
Agencies moved to electronic invoicing under OMB policy, largely through the Treasury Invoice Processing Platform. Selling to the federal government means invoicing electronically.
Large retailers have required EDI 810 invoices for years. The chargeback for a malformed one is real money.
E-invoicing is the exchange of an invoice as structured, machine-readable data between a supplier's system and a buyer's system, with no document for a person to read or retype. A PDF sent by email is not an e-invoice, because the data still has to be extracted before it can be posted. A true e-invoice arrives as XML or EDI, in an agreed format, over an agreed network. Last updated July 2026.
That definition is the one used by tax authorities, by the Peppol network, and by the EU standard EN 16931. It is also the reason electronic invoicing and "emailing a PDF invoice" get confused constantly: both feel paperless, and only one of them removes the data entry.
Not for business-to-business trade. As of July 2026 there is no US federal mandate requiring companies to send or receive e-invoices between themselves. The US route has been a voluntary, market-run exchange network rather than a government clearance system.
Selling to the federal government is different. OMB Memorandum M-15-19, issued in July 2015, directed federal agencies to move to electronic invoicing for appropriate procurements by the end of fiscal 2018, using a federal shared service provider or an approved solution such as the Treasury Bureau of the Fiscal Service Invoice Processing Platform. If you invoice a federal agency, you invoice it electronically.
The Digital Business Networks Alliance is the nonprofit that operates the US e-invoice Exchange Framework. It was formed by participants in the Business Payments Coalition E-Invoice Exchange Market Pilot, a Federal Reserve supported effort, and launched publicly in January 2024. It runs on a four-corner model: a sender and a receiver each connect to their own service provider, and the two providers exchange the document across the network. Participation is voluntary.
Peppol is an international interoperability framework for exchanging electronic documents, including invoices, using the same four-corner model and the AS4 transport protocol. It is governed by OpenPeppol, a nonprofit association, with national Peppol Authorities accrediting access points in each participating country. Peppol BIS Billing 3.0, the invoice specification, is formally a Core Invoice Usage Specification of the European standard EN 16931, implemented in UBL. Peppol is dominant in Europe, Australia, Singapore, and New Zealand, and is used in the US only where a trading partner requires it.
| Standard | What it is | Where you meet it |
|---|---|---|
| EN 16931 | The European semantic data model for the core elements of an electronic invoice. A data model, not a file format. | The reference point for every EU mandate |
| UBL 2.1 | OASIS Universal Business Language: an XML library of business documents, including Invoice and CreditNote. One of the two syntaxes bound to EN 16931. | Peppol, most EU networks |
| UN/CEFACT CII | Cross Industry Invoice, the UN/CEFACT XML invoice syntax. The second syntax bound to EN 16931. | Germany, hybrid formats |
| Peppol BIS Billing 3.0 | A usage specification of EN 16931, expressed in UBL, for invoices sent across the Peppol network. | Peppol access points |
| ASC X12 810 | The Invoice transaction set in the ANSI ASC X12 EDI standard, maintained by the Accredited Standards Committee X12. Usually follows an 850 purchase order. | US retail, distribution, manufacturing |
| ZUGFeRD and Factur-X | Hybrid formats that embed an EN 16931 compliant XML invoice inside a PDF/A file. | Germany and France |
US trading relationships overwhelmingly use the X12 810. If a large customer has ever sent you an EDI specification and threatened a chargeback, that is the document. Our guide to the EDI 810 invoice breaks the segments down field by field.
EDI is one way to do e-invoicing. It is older, bilateral, and heavily used in US supply chains, where each trading partner publishes its own implementation guide on top of the X12 standard. Network e-invoicing in the Peppol or DBNAlliance sense is designed so that connecting once lets you reach every participant, rather than negotiating a map per partner. Both deliver structured invoice data. EDI asks each pair of companies to agree on the details; a network asks everyone to agree once.
Dozens do, and the dates move. These are the ones a US finance team with foreign entities is most likely to hit, taken from the European Commission country pages and the French government portal as of July 2026.
| Country | Obligation | Date |
|---|---|---|
| Italy | B2B and B2C e-invoicing through the Sistema di Interscambio, in FatturaPA XML | Mandatory since 1 January 2019 |
| Germany | All businesses must be able to receive EN 16931 compliant e-invoices | Since 1 January 2025 |
| Germany | Issuing mandatory above EUR 800,000 prior-year turnover, then for all businesses | 1 January 2027, then 1 January 2028 |
| France | All companies must be able to receive; large and mid-sized companies must issue | 1 September 2026 |
| France | Issuing mandatory for SMEs and micro-enterprises | 1 September 2027 |
| Poland | Mandatory B2B e-invoicing through KSeF, large taxpayers first | 1 February 2026, then 1 April 2026 |
| European Union | ViDA: mandatory e-invoicing and digital reporting for intra-EU cross-border B2B | 1 July 2030 |
| United States | No B2B mandate. Federal contractors invoice electronically under OMB M-15-19 | Federal agencies transitioned by end of FY2018 |
The ViDA package, VAT in the Digital Age, was adopted on 11 March 2025 and entered into force on 14 April 2025. From that point member states may impose domestic e-invoicing mandates without seeking an EU derogation first, which is why national deadlines have been arriving in clusters.
The honest answer is that the benefit comes from removing manual handling, not from the file format itself. Ardent Partners, which benchmarks accounts payable annually, reported in January 2025 that Best-in-Class AP organizations, defined as the fifth of enterprises with the lowest invoice processing cost and shortest cycle times, run at 78% lower invoice processing cost, 82% faster invoice processing time, a 59% lower invoice exception rate, and 2.1 times the straight-through processing rate of their peers. Structured invoice data is how they get there. Whether that data arrived over Peppol or came out of an extractor is, for the cost curve, beside the point.
Anyone quoting you an exact dollar cost per invoice should tell you whose benchmark it is and what year it is from. Our own breakdown of the components is in cost to process an invoice.
It depends which side you are on. If you issue invoices and a customer or a government requires a structured format, you need software that can produce and transmit it, which usually means a billing system with a Peppol access point or an EDI provider. If you receive invoices, the practical question is different: how do the invoices that are not e-invoices become data? For most US companies that is the larger number by far, and it is answered with invoice data extraction software rather than an exchange network.
We are not an e-invoicing network and we do not issue invoices. We take the invoice documents that arrive as PDFs, scans, photographs, and email attachments, and turn them into structured data: vendor, invoice number, dates, PO reference, currency, totals, taxes, and every line item, exported to Excel, CSV, or JSON. If you also receive EDI 810 or Peppol invoices, those already arrive as data and need no help from us. The two channels meet in your ERP.
That is the part of the AP cycle worth automating first, because it is the part that scales with headcount. Once the fields are structured, everything downstream works: invoice matching against the purchase order, GL coding, approval routing, and the payment run. The wider workflow is described on our accounts payable automation software page.
Nothing in force says so. The US has consistently favored a voluntary exchange framework, built through the Business Payments Coalition and now operated by the DBNAlliance, over a government clearance model of the kind Italy runs. That could change, and a US company with EU operations will meet mandates abroad long before it meets one at home. Planning on the basis that structured invoice data is useful regardless of who requires it is the safe position, and it is the only one that helps with the PDFs already sitting in your AP inbox.
E-invoicing is the exchange of an invoice as structured, machine-readable data between a supplier's system and a buyer's system, with no document for a person to read or retype. It arrives as XML or EDI over an agreed network. A PDF emailed to accounts payable is not an e-invoice, because the data still has to be extracted before it can be posted.
No. Tax authorities, Peppol, and the EN 16931 standard all define an e-invoice as structured data a system can process automatically. A PDF is a document layout, and reading it requires software or a person. Hybrid formats such as ZUGFeRD and Factur-X are the exception: they embed a compliant XML invoice inside the PDF file.
Not for business-to-business invoicing. As of July 2026 there is no US federal B2B e-invoicing mandate, and the US model is a voluntary exchange network operated by the DBNAlliance. Federal contractors are different: OMB Memorandum M-15-19 moved federal agencies to electronic invoicing, largely through the Treasury Invoice Processing Platform.
Peppol is an international network and set of specifications for exchanging electronic documents, governed by the nonprofit OpenPeppol. It uses a four-corner model, where each party connects to an accredited access point. Its invoice specification, Peppol BIS Billing 3.0, is a usage specification of the EU standard EN 16931 expressed in UBL XML.
EDI is one form of e-invoicing. It is bilateral: each pair of trading partners agrees an implementation of the ASC X12 810 invoice, which is why US retailers publish their own EDI guides. Network e-invoicing such as Peppol is designed so a single connection reaches every participant. Both move structured invoice data rather than documents.
Italy has required it for B2B and B2C since January 2019. Germany has required businesses to be able to receive e-invoices since January 2025, with issuing obligations in 2027 and 2028. France requires all companies to receive from September 2026. Poland phases in KSeF during 2026. The EU ViDA rules apply to intra-EU cross-border B2B from July 2030.
Only for the suppliers who use it. Most US businesses receive the majority of their invoices as emailed PDFs and scans from suppliers that will never join an exchange network. Those documents still need to become structured data, which is what an extractor does. In practice AP teams run both channels into the same ERP import.
EN 16931 is the European standard that defines the semantic data model for the core elements of an electronic invoice. It is a data model rather than a file format, and it is bound to two XML syntaxes, OASIS UBL 2.1 and UN/CEFACT Cross Industry Invoice. Every EU national e-invoicing mandate references it.
Usually yes, unless your ERP can connect directly. Most US companies receive X12 documents through a value added network or an EDI service provider, which handles the connection, the acknowledgments, and the mapping into the ERP. The trading partner normally dictates the specification you must meet.
Run them through an extractor. Upload the PDF, scan, or photo and get the vendor, invoice number, dates, PO reference, currency, totals, tax, and every line item as Excel, CSV, or JSON. Map that output into the same ERP import routine your structured invoices use, and both channels post identically.
