E-invoicing is the exchange of billing data between a seller’s and a buyer’s accounting systems in a structured, machine-readable format, so the information flows from one system to the other without anyone retyping it. That is the whole definition, and it is also the source of most of the confusion around the term: a PDF attached to an email is not an e-invoice in the technical or regulatory sense, even though people often call it one. Governments are increasingly writing rules that assume the stricter meaning, and the standards behind it decide whether an invoice is legally valid, automatically processed, or rejected at the gate.
How an E-Invoice Differs From a PDF
The defining feature is that a computer can read and process the file without human help. A PDF looks like an invoice on screen, but it is essentially a picture of a document. Software cannot reliably pull the tax rate, line items, or payment terms out of it the way it can from a structured data file.
Structured formats organize invoice data into labeled fields in a predictable order. A file in Universal Business Language (UBL), for example, contains tagged elements for the seller’s name, each line item’s quantity and price, the applicable tax, and the payment due date. Accounting software reads those tags directly instead of trying to interpret a visual layout.
Hybrid formats sit between the two worlds. The Factur-X standard used in France and the ZUGFeRD standard used in Germany combine a human-readable PDF with an embedded XML data file. The recipient can open the PDF as a normal invoice, and accounting software can extract the structured XML for automated processing.1fnfe-mpe.org. The New Release of Factur-X/ZUGFeRD Update of the Hybrid E-Invoice Format That approach is common with small and mid-size businesses that need both.
The Data Standards Behind It
Two syntaxes dominate globally. UBL 2.1, maintained by OASIS, is the most widely adopted. UN/CEFACT Cross-Industry Invoice (CII) is the other major syntax, common in parts of Europe. Both can carry the same core invoice information; they differ in how the underlying XML tags are structured.
In Europe, EN 16931 ties the standards together. It defines a semantic data model, meaning it specifies which fields every e-invoice must contain (invoice number, date, seller and buyer details, line items, tax breakdowns, payment terms) without dictating which XML syntax you use. Both UBL 2.1 and CII are recognized syntaxes under EN 16931.2European Commission Digital. European Legislation on eInvoicing
Peppol BIS Billing 3.0 builds on EN 16931 and UBL to create a complete, interoperable profile used across the Peppol network. It inherits its element names from EN 16931 and adds Peppol-specific business rules that invoices must pass before transmission.3Peppol. Peppol BIS Billing 3.0 – November 2025 Release
How E-Invoices Are Delivered
Peppol is the most prominent open network for exchanging e-invoices internationally. It began as a European public procurement project and has since expanded to Asia-Pacific, North America, and beyond. The network runs on a four-corner model that keeps each party’s internal systems separate from the transmission layer:
- Corner 1, the sender. Your accounting software generates the invoice file and pushes it to your access point provider.
- Corner 2, the sender’s access point. This service provider validates the file against the required schema and business rules, then transmits it across the network.
- Corner 3, the receiver’s access point. The recipient’s access point receives the file, verifies the recipient’s identity, and confirms the invoice meets technical standards.
- Corner 4, the receiver. The invoice data lands in the buyer’s accounting system, ready for approval and payment.
Each business on the network has a Peppol Participant Identifier, commonly called a Peppol ID, that functions like a digital address. When your system sends an invoice, the network looks up the recipient’s Peppol ID to decide which access point should receive it. The journey from corner 1 to corner 4 typically takes seconds, and delivery confirmations at each stage give both parties an audit trail without manual follow-up.
Where E-Invoicing Is Required
The EU Framework
The foundational EU law is Directive 2014/55/EU, which requires all public contracting authorities and entities across EU member states to accept and process e-invoices that comply with EN 16931. The directive covers public procurement: if you sell to an EU government agency, that agency must be able to receive your e-invoice. It also defines the required core elements, including seller and buyer information, line item details, delivery data, and payment terms.4Directive 2014/55/EU Text. Directive 2014/55/EU of the European Parliament and of the Council on Electronic Invoicing in Public Procurement
Individual member states have gone further. Italy made B2B e-invoicing mandatory for all domestic transactions in 2019. Germany requires structured e-invoices for federal government suppliers. France begins phased B2B mandates in September 2026, starting with large enterprises.
The next major shift is the EU’s VAT in the Digital Age (ViDA) package, adopted in March 2025, which introduces real-time digital reporting for cross-border trade based on e-invoicing. It rolls out progressively through January 2035 and will eventually require existing national systems to converge on a common approach.5European Commission. VAT in the Digital Age (ViDA)
Global Mandates
By 2026, more than 80 countries will either mandate or tightly regulate e-invoicing. Belgium requires structured B2B e-invoicing for domestic transactions starting January 2026. Singapore requires electronic tax data transmission for new GST registrants from April 2026. Malaysia, Oman, and the Philippines are all expanding their mandates through 2026.
Many of these countries use Continuous Transaction Controls (CTC), where tax authorities receive invoice data in real-time or near-real-time rather than waiting for periodic tax returns. There are two main flavors. In a real-time reporting model, used in Hungary and South Korea among others, businesses transmit invoice data to the tax authority at or near the moment of the transaction. In a clearance model, used in Mexico, India, Saudi Arabia, and several Latin American countries, the tax authority must approve each invoice before it is legally valid. The stakes are highest in the clearance model: if your invoice fails validation, it cannot legally be issued to the buyer until the errors are fixed.
Where US Law Stands
The United States has no national e-invoicing mandate for private-sector transactions, but the legal foundation for electronic records is settled. Under the Electronic Signatures in Global and National Commerce Act, a record or signature cannot be denied legal effect, validity, or enforceability solely because it is in electronic form.6Office of the Law Revision Counsel. 15 US Code 7001 – General Rule of Validity An e-invoice carries the same legal weight as a paper one, provided the parties agreed to transact electronically. The Uniform Electronic Transactions Act reinforces this at the state level and has been adopted in 49 states.
For record-keeping, the IRS requires every taxpayer to keep records sufficient to determine tax liability under 26 U.S.C. ยง 6001.7Office of the Law Revision Counsel. 26 US Code 6001 – Notice or Regulations Requiring Records, Statements, and Special Returns If you store invoices electronically, Revenue Procedure 97-22 sets the rules: the system must accurately transfer records to electronic storage, maintain controls to prevent unauthorized changes, include an indexing system for retrieval, and produce legible hard copies on request. The records must provide an audit trail between source documents and the general ledger.8Internal Revenue Service. Revenue Procedure 97-22 Revenue Procedure 98-25 adds requirements for machine-readable records: enough transaction-level detail to support the tax return, a demonstrable audit trail to the return, and, at examination time, whatever hardware, software, and personnel the IRS needs to access the records.9IRS.gov. Revenue Procedure 98-25 – Retaining Machine-Sensible Records
Federal contractors face a mandate. OMB Memorandum M-15-19 directed federal agencies to transition to electronic invoicing for procurement, and agencies were required to adopt approved e-invoicing solutions or migrate to a Federal Shared Service Provider.10The White House. Improving Government Efficiency and Saving Taxpayer Dollars Through Electronic Invoicing The primary tool is the Invoice Processing Platform (IPP), a secure web-based system operated by the Treasury Department’s Bureau of the Fiscal Service.11Fiscal.Treasury.gov. Invoice Processing Platform Federal agencies no longer accept paper invoices, so vendors must register in the System for Award Management (SAM) and submit through IPP.
For private-sector B2B, the United States is building a voluntary national exchange network. The Business Payments Coalition, with Federal Reserve support, developed an e-invoice exchange framework that became available for general business use in early summer 2023.12FedPayments Improvement. Exchange Framework Validated for E-Remittance Information Governance transferred to the Digital Business Networks Alliance (DBNAlliance), which operates an open exchange network for secure B2B document exchange among US companies.13DBNAlliance. Home – DBNAlliance | The US Open Exchange Network Adoption is voluntary; the infrastructure exists for businesses that want to move off email attachments.
Why E-Invoices Get Rejected
Before an e-invoice reaches the recipient, it passes through several automated checks, and a rejection means delayed payment.
The first layer is XML schema validation, which checks the file structure itself. Does every required element exist? Are data types correct, with numbers where numbers belong and dates properly formatted? A missing closing tag or a text string in a numeric field fails at this stage.
The second layer is Schematron business rule validation, which applies the specific rules of the standard in use. Peppol BIS Billing 3.0, for example, includes rules that check what EN 16931 requires but XML schema alone cannot enforce: does the tax calculation add up, is the currency code valid, are mandatory fields populated with real data rather than placeholder text.3Peppol. Peppol BIS Billing 3.0 – November 2025 Release
Common reasons invoices get rejected include mismatched tax identification numbers, where the state code derived from a tax ID does not match the state in the address; document numbers with invalid characters or lengths; missing product classification codes; and address fields that are too short or too long. Invoice dates set in the future also fail. Most ERP systems can run these validation checks before submission, and catching errors there is far less painful than having an access point bounce the file back.