A billing record in named fields, not a picture of a bill. Seller, buyer, lines, tax, totals, and payment terms sit where software can read them without guessing. Sending a Portable Document Format (PDF) by email is electronic only in the casual sense: a person, or Optical Character Recognition (OCR), still has to interpret the page. Directive 2014/55/EU uses electronic invoice for a document issued, transmitted, and received in a structured format that can be processed automatically. A bare image falls outside that definition. When a PDF rides along, it is a reading copy.
What the File Must Carry
A usable electronic invoice names the commercial facts a payables system will post. Layout does not matter. Identity of each value does. The European core model treats the invoice as a set of business terms with stable meanings, so two companies are referring to the same fact even when their software differs.
- Parties. Seller, buyer, and sometimes a distinct payee or tax representative, with the legal names and tax identifiers the receiving system matches to master data.
- Lines. Description, quantity, unit price, and line tax, so a purchase-order match can fail on one row instead of on a lump sum.
- Tax. A breakdown by rate, including Value-Added Tax (VAT), rather than a single number typed at the bottom of a page.
- Payment. Currency, due date, and the means of payment, so the payable can be scheduled without opening an attachment.
If those values exist only as ink on a PDF, the system does not have an invoice yet. It has a picture it must interpret. National tax rules may also require an extra identifier or a clearance number. Those controls sit on top of the commercial invoice. They do not replace the fields above.
One Semantic Model, Two Syntaxes
EN 16931, the European standard tied to that directive, is the semantic model: what the invoice means, not which tags to use. The two syntaxes public buyers covered by the directive must be able to receive are both eXtensible Markup Language (XML). Universal Business Language (UBL) 2.1, published as ISO/IEC 19845:2015, uses separate invoice and credit-note documents. The UN/CEFACT Cross Industry Invoice (CII) D16B schemas use one document type and a code to say which business document it is. Same terms, different trees.
Countries then tighten that core with a profile. Germany’s XRechnung accepts UBL or CII. Factur-X and ZUGFeRD, the French and German hybrid formats, embed CII XML inside a PDF/A-3 file: a person reads the page, and a parser reads the embedded XML. Other regimes do not use these syntaxes at all. Italy routes domestic VAT invoices through Sistema di Interscambio in a national XML schema, FatturaPA, rather than UBL. India’s Goods and Services Tax (GST) e-invoice schema uses JavaScript Object Notation (JSON). The duty in Directive 2014/55/EU sits on public procurement. Whether a private business must issue an electronic invoice to another business is a national rule, and those rules do not share one calendar or one file format.
Delivery, Clearance, and Payables
Business-to-Business (B2B) exchange used to mean a private pipe between two partners. Pan-European Public Procurement On-Line (Peppol) is a network instead. It began for public procurement and is now used more widely. Each party needs an access point and a network address. They do not negotiate a custom message map. The usual invoice profile on that network, Billing 3.0, is EN 16931 expressed in UBL, plus stricter validation so a stranger can receive the file.
- Corner 1. The supplier creates the invoice in an Enterprise Resource Planning (ERP) or billing system.
- Corner 2. The supplier’s access point checks the profile and sends the file.
- Corner 3. The buyer’s access point receives it.
- Corner 4. The buyer’s system takes the data in, ready to post.
That operating model is not the same thing as Electronic Data Interchange (EDI). An EDI invoice is already structured, often as a UN/EDIFACT INVOIC message or an ANSI X12 810. The gap is the agreement. Classic EDI uses a bilateral map: the partners settle segments, codes, and a transport such as a value-added network, and a new customer means a new map. Regulated e-invoicing tries to replace that custom work with a published semantic core and a published syntax. CEN/TS 16931-3-4 binds the European core model to a UN/EDIFACT invoice, so an EDIFACT file can carry the same terms. The process around the file can still be a private EDI relationship rather than a public network or a tax platform. Supporting that binding is not the same duty the directive places on public buyers, which names UBL and CII.
Tax authorities attach to the exchange in three ways. In a post-audit model, the parties exchange the invoice and the authority reviews it later. In a clearance model, the supplier must submit the structured invoice to a government platform, and it is not a valid tax invoice until that platform accepts it and returns an identifier. Italy’s Sistema di Interscambio is that pattern for domestic VAT invoices. A third pattern, continuous transaction controls, reports the data at nearly the same time as delivery, sometimes by copying the authority, without holding the invoice for approval. The billing system has to know which pattern applies, because clearance can stop issuance until the authority responds.
The seller’s Accounts Receivable (AR) system emits the fields. The buyer’s Accounts Payable (AP) system should not retype them.
- Validate. Check the schema, the parties, the arithmetic, and the tax codes before anyone opens a queue.
- Match. Compare price and quantity with the purchase order and the goods receipt, line by line.
- Post. Write the accepted invoice into the ERP, schedule payment from the stated terms, and archive the original structured file.
People still handle price breaks, missing receipts, and master-data mismatches. They should not have to rekey a clean invoice. The differences among the three file habits look like this.
| Feature | PDF Bill | Structured File | EDI Invoice |
| What travels | A visual page | Named business fields | Segments in a partner message |
| Who reads it | A person or OCR | A schema parser | A translator using a partner map |
| Usual syntax | None | UBL, CII, a national XML or JSON schema, or XML embedded in a PDF | UN/EDIFACT or ANSI X12 |
| Agreement | Send the file | A shared profile or a national schema | A bilateral map and transport |
| Tax authority | Not part of the format | Exchange only, a parallel report, or clearance before the invoice is valid | A commercial flow, unless a local rule adds reporting |
| Payables work | Capture and correct, then match | Validate, match, and post the exceptions | Translate, then match |
Archive the structured original. A later PDF rendering is not a substitute when the tax rule treats the data file as the invoice.
