What Is an E-Invoice? A Plain-Language Introduction
A finance team can send an invoice as a PDF, a scanned image, or text pasted into an email and reasonably call the process “electronic.” Under EU law, none of those count as an e-invoice.
The distinction isn't cosmetic: it decides whether a business meets its e-invoicing obligations in Germany, Italy, Spain, and every other EU market rolling out structured invoicing mandates, or whether it's still sending digital paper that happens to travel over the internet instead of the postal service.
TL;DR
- An e-invoice is an invoice issued, transmitted, and received in a structured data format that allows automatic, electronic processing, as defined in EU Directive 2014/55/EU.
- A PDF, a scanned invoice, or an invoice in an email body is digital, but none of them is structured, so none of them qualifies as an e-invoice.
- EN 16931, the European e-invoicing standard, defines that structure and supports two XML syntaxes, UBL and CII.
- A structured e-invoice moves through creation, validation, network transmission, and automatic posting, with no step where a person retypes the data.
- B2G e-invoicing has been mandatory across the EU since Directive 2014/55/EU, though member states had until 2019 (central government) and 2020 (sub-central) to actually implement receiving capability; B2B mandates are rolling out country by country ahead of the EU-wide ViDA requirement for intra-community trade from July 2030.
What is an e-invoice, exactly?
An e-invoice is an invoice issued, transmitted, and received in a structured electronic data format that a computer system can read and process without a person opening the file and re-entering its data. The legal definition comes from Directive 2014/55/EU: an invoice that has been issued, transmitted, and received in a structured data format which allows for automatic and electronic processing.
That last phrase carries the whole definition. In a structured e-invoice, the invoice number, the buyer and seller identifiers, the line items, the tax amounts, all sit in a fixed, machine-readable schema. An accounting or ERP system imports it directly into accounts payable, with no employee re-keying a single field.
What makes an invoice structured instead of just digital?
A structured invoice separates the data from the way it looks, putting every field in a defined position a system can read, rather than laying it out as text for a person to read.
A paper invoice bundles three things most people never think to separate: the data, a visual layout for reading it, and a physical object for handing it over. Scanning the paper, exporting it as a PDF, or pasting it into an email removes the physical handoff but keeps the other two problems, since someone still has to look at the layout and type the numbers into the next system.
A structured e-invoice drops the visual layer as the source of truth entirely. A human-readable rendering can still exist for someone who wants to look at it, the way ZUGFeRD and Factur-X embed one, but that rendering is a byproduct. The invoice is the data.
How is an e-invoice different from a PDF or scanned invoice?
A PDF invoice and a true e-invoice can describe the same transaction and still be legally different documents, because the difference is whether a computer or a person does the reading.
| Invoice type | Data format | Requires manual reading | Machine-readable structure | Meets EU e-invoicing mandates |
|---|---|---|---|---|
| Paper invoice | Printed text | Yes | No | No |
| PDF or scanned invoice | Digital image or unstructured text | Yes | No | No |
| Emailed or web-based invoice (HTML) | Unstructured digital text | Yes | No | No |
| Structured e-invoice (UBL or CII XML) | Structured XML | No | Yes | Yes, when compliant with EN 16931 or a national CIUS |
The European Commission's eInvoicing building block is explicit that e-invoices aren't PDF or Word files, images of an invoice, unstructured HTML invoices, or OCR output from a scanned paper invoice, no matter how digital the delivery channel looks.
What does “issued, transmitted, and received in structured format” actually mean?
The Directive 2014/55/EU definition names three separate steps, and an invoice has to clear all three to count.
Issued in structured format means the seller's system generates the invoice directly into the required schema, not as a PDF that gets converted afterward. Every mandatory field, invoice number, issue date, party identifiers, line items, VAT breakdown, has to be there from the moment the document exists.
Transmitted in structured format means the file moves from seller to buyer without losing that structure along the way. A structured XML file can technically travel as an email attachment, but most national mandates route it over a defined network, such as Peppol, so the receiving side can validate the message before it reaches the buyer.
Received in structured format means the buyer's system takes in the same structured data the seller sent, intact, and can act on it without a conversion step. The European standard on eInvoicing frames this as a three-level compliance model: the invoice document itself must follow the CORE model or a national CIUS, the sending system must be able to create such invoices, and the receiving system must accept and process every compliant invoice without rejecting valid optional fields.
Structure the invoice correctly and then email it as a PDF, or send a proper XML file the buyer's system can't ingest, and the exchange falls short on one of the three steps, no matter how digital it looks from the outside.
What formats do structured e-invoices use?
Most structured e-invoices in Europe are built on EN 16931, the semantic data model published by the European Committee for Standardization (CEN) at the European Commission's request. EN 16931 defines what information an invoice must contain, not a single file format; two syntaxes carry that data.
| Syntax | Root element / container | Common use |
|---|---|---|
| UBL 2.1 | <Invoice> for invoices, <CreditNote> for credit notes | Peppol BIS Billing 3.0, and several other EU national CIUS profiles |
| UN/CEFACT CII | Cross Industry Invoice XML | Germany's XRechnung CII variant, and the ZUGFeRD/Factur-X hybrid format |
A sender doesn't always get a free choice between the two. On the Peppol network, UBL is the mandatory syntax for Peppol BIS Billing 3.0 — every access point must support it, though a receiver can optionally register to also accept CII. ZUGFeRD/Factur-X hybrids, by contrast, allow no choice at all: CII is the only syntax the format supports. National governments layer their own rules on top of EN 16931 through a CIUS: Germany's XRechnung, currently at version 3.0.2, is one example, though a 4.0 revision aligning with an updated EN 16931 standard is expected later in 2026, so this version number is worth rechecking before publishing. Italy's FatturaPA sits outside this system entirely, since it predates EN 16931 and uses neither UBL nor CII; it's the format the Sistema di Interscambio requires for domestic invoicing, not the only format the SDI accepts, since cross-border suppliers billing Italian public bodies can use an EN 16931-compliant CIUS-IT profile instead. fiskaly's E-INVOICE API generates and validates these CIUS variants across multiple markets from a single integration, rather than requiring a separate format pipeline per country.
Key takeaways
- An e-invoice is a legal category, not a file type. Directive 2014/55/EU defines it by what happens to the data (structured, automatic processing), not by whether the invoice arrived electronically.
- “Digital” and “structured” are different properties. A PDF can be digital without being structured, and only structured invoices meet EU e-invoicing mandates.
- EN 16931 is the standard behind most EU e-invoices, and it supports two XML syntaxes, UBL and CII, rather than one fixed file format.
- Some national schemas sit outside EN 16931 entirely. Italy's FatturaPA and Spain's Facturae predate the European standard and use neither UBL nor CII.
- The compliance bar has three parts: issuing, transmitting, and receiving all have to happen in structured format for an exchange to count as a true e-invoice.
How does an e-invoice move from issuer to receiver?
- The seller's system generates the invoice in a structured schema. An ERP, accounting platform, or invoicing API populates the mandatory EN 16931 or CIUS fields directly, rather than producing a PDF first.
- The invoice is validated against the applicable business rules. Automated checks confirm required fields are present, tax calculations are correct, and codes used (currency, country, VAT category) are valid before the document leaves the seller's system.
- The invoice is transmitted over a structured network. Many EU markets route this through a Peppol Access Point, which validates the message format before forwarding it; others use a national platform such as Italy's Sistema di Interscambio.
- The receiving system validates the incoming file. The buyer's Access Point or platform checks the invoice against the same schema and business rules before accepting it.
- The invoice posts automatically into accounts payable. No one retypes the amounts, the invoice number, or the tax breakdown; the structured fields map directly into the buyer's ledger.
The invoice is archived for the required retention period. Most EU jurisdictions require fiscal documents to be kept for several years in a tamper-evident, auditable form, often through dedicated archiving infrastructure like fiskaly SAFE, which is why archiving usually runs alongside e-invoicing rather than as an afterthought.
Building every one of these steps from scratch, schema generation, validation, network transmission, and archiving, is a significant engineering lift for any business to take on alone. An e-invoicing API integration such as fiskaly's E-INVOICE plugs into an existing ERP, billing system, or POS platform to handle generation, validation, and transmission directly, rather than requiring that system to be rebuilt around each country's requirements from the ground up.
Why are governments requiring structured e-invoicing?
Tax authorities want the same thing accounting departments want: data they don't have to re-key and can check automatically. A structured invoice lets a tax authority validate VAT calculations and flag fraud in close to real time, something a PDF or paper trail makes far harder at scale.
That logic sits behind the EU's VAT in the Digital Age (ViDA) reform, which extends structured e-invoicing to intra-community B2B transactions from July 2030. Individual member states are ahead of that timeline already. Germany's B2B e-invoicing mandate requires businesses to receive structured e-invoices since January 1, 2025, with sending obligations phasing in for larger businesses in 2027 and everyone else by 2028. Italy's Sistema di Interscambio has required electronic invoicing for B2G transactions since 2014, extended to domestic B2B and B2C transactions from January 2019. Spain's Crea y Crece law is rolling out a parallel B2B mandate, with large businesses (turnover above €8M) expected to go live around October 2027 and all other in-scope businesses by October 2028, though Spain's e-invoicing timelines have a history of slipping, so treat these dates as directional rather than fixed. For the country-by-country deadlines behind these mandates, see fiskaly's guide to Europe's e-invoicing mandates.
Who needs to care about e-invoicing right now?
Any business invoicing a public sector entity in the EU already needs structured e-invoicing capability: B2G e-invoicing has been mandatory across the bloc since Directive 2014/55/EU took effect, with member states required to have central government receiving capability in place by 2019 and sub-central government by 2020. B2B requirements are catching up market by market, and the software vendors serving those businesses, POS platforms, ERPs, accounting tools, are the ones actually on the hook for building the capability, since their customers expect it to work out of the box rather than being pointed at a separate solution.
Bottom line
The line between “digital” and “structured” is what separates a scanned invoice from a legally compliant e-invoice. A PDF or an emailed image still asks a person to read and re-enter the data; a structured e-invoice, issued in a defined schema, transmitted intact, and received in a form the buyer's system can act on directly, does not. For format-by-format detail on how UBL, XRechnung, FatturaPA, and Facturae compare, see fiskaly's e-invoice format guide. For the country-by-country deadlines behind these mandates, see fiskaly's guide to Europe's e-invoicing mandates. For generating, validating, and transmitting structured e-invoices across markets from a single integration, see fiskaly E-INVOICE.
Frequently asked questions
Is a PDF invoice the same as an e-invoice?
No. A PDF invoice is a digital document designed for a person to read; a true e-invoice is structured data designed for a computer system to read and process automatically. A plain PDF doesn't meet the legal definition of an e-invoice under EU rules.
What is EN 16931?
EN 16931 is the European standard, published by CEN, that defines the semantic data model — the required fields and their structure — for a compliant electronic invoice. It supports two syntaxes, UBL 2.1 and UN/CEFACT CII, and forms the basis for most national e-invoicing formats in the EU.
Do I need special software to create or receive e-invoices?
Yes. Creating a compliant e-invoice means generating structured XML that follows EN 16931 or the relevant national CIUS, and receiving one means validating and importing that same structure, usually through ERP, accounting software, or a dedicated e-invoicing API integration such as fiskaly's E-INVOICE, which plugs into an existing system rather than replacing it.
Is a scanned invoice sent by email considered an e-invoice?
No. A scanned invoice is an image of a document, not structured data, regardless of the channel used to send it, and it still requires manual reading and data entry on the receiving end.
What is Peppol and how does it relate to e-invoicing?
Peppol (Pan-European Public Procurement Online) is a network for exchanging structured e-invoices between systems in different countries. Peppol BIS Billing 3.0, the specification most commonly used on the network, requires the UBL syntax and validates messages against EN 16931 business rules before delivery.
Are e-invoices mandatory for all businesses in the EU?
B2G e-invoicing has been mandatory across the EU since Directive 2014/55/EU, with member states required to implement receiving capability by 2019 (central government) and 2020 (sub-central). B2B mandates vary by country and timeline: Italy's SDI mandate covered B2G from 2014 and extended to domestic B2B and B2C from January 2019, Germany started with receiving in 2025 and sending from 2027-2028, and other member states are on their own schedules ahead of the EU-wide ViDA requirement for intra-community trade from July 2030.
Why do some countries, like Italy and Spain, not use UBL or CII?
Italy's FatturaPA and Spain's Facturae predate the EN 16931 standard and were built before UBL and CII became the common EU syntaxes. Both countries kept their existing national schemas rather than replacing them, so invoicing software targeting those markets needs a separate format pipeline in addition to any UBL- or CII-based one.