{"id":29073,"date":"2026-08-01T07:00:08","date_gmt":"2026-08-01T07:00:08","guid":{"rendered":"https:\/\/bilnex.io\/en\/peppol-vs-pdf-einvoicing\/"},"modified":"2026-08-01T07:00:08","modified_gmt":"2026-08-01T07:00:08","slug":"peppol-kontra-fakturowanie-pdf","status":"publish","type":"page","link":"https:\/\/bilnex.io\/pl\/peppol-kontra-fakturowanie-pdf\/","title":{"rendered":"Peppol kontra PDF: Zasady e-fakturowania w Europie w latach 2026\u20132030"},"content":{"rendered":"
\n
\n
\n

Are PDF, e-invoice and Peppol the same thing?<\/h2>\n

What each term actually covers<\/h3>\n

A PDF invoice you email to a client can be entirely valid under VAT law. It can still fail to count as a structured e-invoice. Peppol isn’t a format at all, it’s a network for moving invoices around. Under the European Commission’s eInvoicing definition<\/a>, an e-invoice is invoice data that’s issued, sent and received in a structured format a computer can process automatically. PDF, Word files, images, HTML and scanned documents all fall outside that definition. The VAT rule in force right now is wider: Article 217 of the EU VAT Directive<\/a> defines an electronic invoice as one issued and received in any electronic format, and a plain PDF satisfies that just fine. Peppol, meanwhile, is a four-corner network<\/a> built to move structured invoices around securely. It’s not a format of its own, and it’s not an automatic legal requirement.<\/p>\n

Why the distinction matters for your invoice<\/h3>\n

That distinction matters more than it looks. Your accountant can sign off on a PDF as fully compliant under VAT rules, and the same PDF can still fail to satisfy a buyer who’s registered to receive e-invoices or who requires structured data. These are two separate rulebooks that happen to share the word “electronic.”<\/p>\n

How do PDF, XML and Peppol actually differ in practice?<\/h2>\n

Once you know which document a specific buyer needs, the choice usually comes down to what’s in the table below. A “structured EN 16931 invoice” means a machine-readable data file, typically an XML file, built to the European e-invoicing standard EN 16931.<\/p>\n\n\n\n\n\n\n\n\n\n
Feature<\/th>\nEmailed PDF<\/th>\nStructured EN 16931 invoice (agreed channel)<\/th>\nInvoice sent via Peppol<\/th>\n<\/tr>\n<\/thead>\n
How the buyer receives it<\/td>\nAs an attachment, opened and read by a person<\/td>\nAs a data file, straight into the company’s own system<\/td>\nAs a data file via an Access Point (a service provider that plugs into the Peppol network)<\/td>\n<\/tr>\n
Automatic processing in the buyer’s software<\/td>\nNo, needs manual entry or OCR (optical character recognition, software reading text off an image)<\/td>\nYes, if it meets the standard<\/td>\nYes, if the document meets the standard<\/td>\n<\/tr>\n
Meets the EU VAT Directive’s current “electronic invoice” definition<\/td>\nYes, if it contains the required data elements<\/a><\/td>\nYes<\/td>\nYes<\/td>\n<\/tr>\n
Satisfies Estonia’s registered e-invoice recipient requirement<\/td>\nUsually not<\/td>\nYes, if it meets EN 16931-1 or another agreed standard<\/a><\/td>\nMostly yes, if the buyer accepts this channel and the document meets the standard<\/td>\n<\/tr>\n
Satisfies Latvia’s structured-invoice obligation<\/td>\nNo<\/td>\nYes, if it meets LVS EN 16931-1:2017<\/a><\/td>\nMostly yes, under the same condition<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

In other words: the Peppol channel by itself guarantees nothing. What decides the outcome is the structure of the document and what the specific buyer has actually asked for.<\/p>\n

Estonia: check the e-business register before you send an invoice<\/h2>\n

Since 1 July 2025<\/a>, any accounting-obligated entity listed in the e-business register (e-\u00e4riregister) as a registered e-invoice recipient can require its suppliers to issue an e-invoice for goods or services bought from them. An invoice counts as properly issued if it meets the EN 16931-1 standard<\/a>, though the two parties are free to agree on a different suitable standard instead. Unless a law or other legal act says otherwise, the format and terms for submitting machine-readable source documents are left for the two parties to work out between themselves.<\/p>\n

In practice, that means checking the buyer’s entry in the e-business register before you send anything. If they’re registered there as an e-invoice recipient, the requirement is theirs to invoke, not yours to guess at. The real test is whether the document is machine-readable, not whether the word “Peppol” appears on it somewhere. Estonian law doesn’t currently set a single nationwide rule forcing all B2B invoices through Peppol specifically. Always check the individual buyer’s requirement and any sector-specific rules that might apply on top of it.<\/p>\n

Latvia: structured invoices are already mandatory in B2G<\/h2>\n

Latvia’s Accounting Law<\/a> defines a structured electronic invoice as one prepared, sent and received in a structured electronic format capable of automatic electronic processing, meeting the LVS EN 16931-1:2017<\/a> standard together with the EU syntax specification the law references.<\/p>\n

What’s already required in B2G<\/h3>\n

Since 1 January 2026<\/a>, the structured-invoice requirement also applies to suppliers billing budget institutions under contracts signed before 2025. The transition period that had delayed those older contracts runs out on that date. From the same date, 1 January 2026<\/a>, data from structured invoices sent to budget institutions also has to be reported to Latvia’s tax authority, the Valsts ie\u0146\u0113mumu dienests (State Revenue Service).<\/p>\n

What arrives in 2028 for ordinary B2B trade<\/h3>\n

The deadline that matters most for ordinary B2B trading comes later: from 1 January 2028<\/a>, the structured e-invoice obligation extends to invoices issued to any other Latvia-registered company that isn’t a budget institution. That’s the point where most of your Latvian customers outside the public sector will be able to start requiring a structured invoice from you too.<\/p>\n

Why Peppol is often the easiest route, but not the definition<\/h2>\n

OpenPeppol’s own 2024 overview<\/a> explains that e-invoicing splits into two separate pieces: the structured invoice data itself, and the mechanism for sending and receiving it. Peppol handles the second piece. It runs on a four-corner network (4-corner model) in which the sender and the recipient each use a service provider, called an Access Point, and these Access Points exchange standardized business documents with each other.<\/p>\n

That makes Peppol a genuinely convenient choice in practice: if your accounting software already connects to an Access Point, you don’t need to build a separate channel for every customer. But using Peppol on its own doesn’t turn a document into an e-invoice, and it doesn’t automatically satisfy any legal requirement by itself. What decides that is still the structure of the document and what the buyer actually needs.<\/p>\n

What changes in EU VAT rules on 1 July 2030?<\/h2>\n

The Council adopted Directive (EU) 2025\/516<\/a> on 11 March 2025, amending the VAT Directive. The revised Article 217 replaces today’s broad “any electronic format” definition and takes effect from 1 July 2030<\/a>. From that date, an invoice will need to be issued in a structured electronic format that can be processed automatically, at least for certain reporting data.<\/p>\n

That doesn’t mean every EU invoice has to travel over Peppol specifically by 2030. The directive gives member states the right, from 14 April 2025<\/a>, to introduce domestic rules requiring electronic invoicing for transactions within their own borders. That’s a choice each country makes, not an automatic EU-wide Peppol mandate. Which channel actually becomes compulsory is decided by each country’s own legislation, as Estonia and Latvia have already shown.<\/p>\n

A five-point check before you send an invoice<\/h2>\n