EU E-Invoicing & Tax Reporting Knowledge Base

Product guides and frameworks for EU e-invoicing, Peppol, EN 16931, VAT reporting, tax authority integrations and rollout readiness.

Oct

2026

E-Invoicing Beyond Invoices: Payments, Customs, Payroll

The invoice is the first regulated business document to be forced into structured form, not the last. Greece’s tax authority now runs a real-time goods-movement interface alongside its invoice interface, both on the same platform. India’s Invoice Registration Portal forwards the invoice payload to the e-way bill system and the VAT return system without the taxpayer submitting it twice. Peppol, a network built to move invoices between public buyers and their suppliers, now publishes specifications for despatch advices, weight statements and transport booking requests. The pattern is consistent enough to plan around: once a jurisdiction has structured, addressable, machine-validated documents moving through a controlled channel, every adjacent document becomes a candidate for the same treatment.

Planning for e-invoicing beyond invoices matters commercially, not just architecturally. Invoice automation on its own captures roughly a third of the efficiency available across the purchase-to-pay and order-to-cash cycle. If you scope an e-invoicing programme as an invoice programme, you are scoping about a third of the value — and building an integration you will likely rebuild within a few years.

Invoice automation is about a third of the prize

The e-invoicing analyst Bruno Koch has put the invoice’s share of the total optimisation potential at roughly one third, with the remaining two thirds sitting in the surrounding documents: the request for proposal, the tender, the catalogue, the contract, the order and order confirmation, the delivery note, the payment, and the archive. His argument is not that paper substitution is pointless — it is that it stops short. Replacing paper with electronic documents is worth doing, he writes, but a more disruptive approach can “improve the entire financial supply chain by many factors.”

The sharpest number on this comes from analysis at Politecnico di Milano, which put the net benefit of VAT-compliant e-invoicing at €4–12 per invoice, and the benefit of integrating the full trade process at up to €65 per cycle. Those absolute figures date from research presented in 2010 and should be treated as illustrative rather than current. The ratio is the durable part: full-process integration was worth several times what invoice digitisation alone was worth, and nothing since has changed the shape of that gap.

What has changed is who is driving the expansion. In 2010 the argument for extending beyond the invoice was a business case that most organisations declined. In 2026 it is increasingly a legal obligation, and the obligation arrives from tax and customs authorities rather than from procurement teams.

Payments: the invoice already carries the payment instruction

An e-invoice is a payment instruction with tax metadata attached, and the payments industry has been formalising that link for a decade. The Euro Retail Payments Board, chaired by the European Central Bank, ran a working group on electronic invoice presentment and payment (EIPP) that reported in November 2016. It found a fragmented market — half the solutions surveyed operated in a single country, three quarters in one country or one regional bloc — but a clear technical convergence: SEPA credit transfers and direct debits dominated as the settlement instruments, card payments barely registered, and no single invoice syntax was winning among ISO 20022, UBL, UN/CEFACT Cross Industry Invoice and EDIFACT.

That work did not stop at a report. It produced an EIPP Multi-Stakeholder Group, a decision to model the request for payment on ISO 20022 pain.013 and pain.014 messages, and ultimately the European Payments Council’s SEPA Request-to-Pay scheme (EPC014-20), whose first rulebook was issued in November 2020 and whose version 4.0 took effect on 5 October 2025. The scheme explicitly names e-invoice presentment and payment as one of its use cases across B2C, B2B and B2G.

National tax platforms are pulling payment data in from the other direction. Greece’s myDATA payload does not merely record that an invoice was paid; for card transactions it carries terminal-level detail — payment method type, terminal identifier, retrieval reference number, authorisation data, whether the transaction was contactless, and any tip. That is fiscalisation and invoicing meeting in a single schema, which is why the Greek POS-to-cash-register interconnection rules and the invoicing rules ended up as the same compliance project for most retailers.

Procurement: the invoice network was built for public buying

Europe’s e-invoicing infrastructure did not start as an invoicing project. Directive 2014/55/EU is titled “on electronic invoicing in public procurement”, and Peppol’s invoice specifications are maintained by a body called the Post Award Coordinating Community — post-award being the phase after a procurement contract is signed. The same community publishes specifications for purchase orders, order responses, catalogues and despatch advices. Extending from invoice to order on Peppol is not a new integration pattern; it is switching on document types that already exist on a network you are already connected to.

The procurement metadata is often already in the invoice. In Greece, a B2G invoice carries the contracting authority, the contract type and reference code, and a Common Procurement Vocabulary (CPV) code mapped from the material master — the same classification used to publish the tender in the first place. The invoice is functioning as the closing record of a procurement transaction, and the tax authority is collecting it as such.

Logistics: the delivery note is being cleared in real time

The most concrete evidence that e-invoicing pulls in transport is Greece’s digital delivery note, which runs on the myDATA platform beside the invoice. Phase A — digitally issuing the transport document at the moment goods begin to move, transmitting it to the authority, and notifying the recipient — has been in force since December 2025. Phase B extends this to the movement itself: loading, unloading, receipt, and quality and quantity checks. AADE’s published technical specifications now include a dedicated Digital Goods Movement interface with fields for vehicle number, dispatch date and time, packaging type, line-level movement purpose, and a delivery lifecycle event set.

Phase B has been rescheduled more than once — from December 2025, then to May 2026, and on 30 April 2026 AADE restructured it into a staged rollout beginning in October 2026. The slippage is informative rather than reassuring: authorities are finding real-time event tracking harder to deliver than real-time invoice clearance, which is exactly what you would expect, and they are not abandoning it.

India got to the same place by a different route. Under its GST e-invoicing system, a supplier sends the invoice to an Invoice Registration Portal, which returns an Invoice Reference Number and a signed QR code — and then forwards the same payload onward. The GST Network’s advisory on auto-populationconfirms the data is transmitted to the GST system within two days and populates the corresponding tables of the GSTR-1 return. In parallel, the payload populates Part A of the e-way bill, the permit that authorises the physical movement of the goods. One submission, three regulatory outcomes: invoice registration, return prefill, transport authorisation.

On the network side, Peppol Logistics publishes business interoperability specifications for the Advanced Despatch Advice, the Receipt Advice used to confirm what actually arrived, a Weight Statement for bulk goods, and a Transport Execution Plan with Request used to book the transport itself. These are voluntary today in most of Europe. They exist because the buyers and suppliers already exchanging invoices asked for them.

Customs: the EU is replacing declarations with a data hub

Customs is converging on the same architecture as continuous transaction controls — submit structured data to a central government system, receive a release — and it is doing so through two separate instruments.

The first is already law. Regulation (EU) 2022/2399 established the EU Single Window Environment for Customs and, with it, EU CSW-CERTEX, a central system connecting national customs single windows to the Union’s non-customs systems so that certificates, licences and permits held elsewhere can be checked against a declaration automatically. It has applied since 12 December 2022, though the provision giving economic operators a single communication channel does not bite until 13 December 2031.

The second is the reform of the Union Customs Code, on which the Council and the European Parliament reached political agreement on 26 March 2026. It creates an EU Customs Data Hub and a European Union Customs Authority based in Lille. The design intent is to retire the customs declaration as a discrete filing: goods are released once the data submitted to the hub is complete and accurate. Use of the hub becomes mandatory for deemed importers — the e-commerce platforms now treated as the importer of record — from 1 July 2028, with a full transition running well into the 2030s. In the interim, the €150 duty exemption for low-value consignments disappears on 1 July 2026, replaced by a flat €3 per-item duty until the hub can apply normal tariffs. The final text still requires formal adoption, so the dates are firm in direction and provisional in detail.

For a business, the practical consequence is that the commercial invoice, the customs data set and the VAT reporting data set start drawing on one master record. Keeping three inconsistent versions of the same shipment stops being an internal untidiness and starts producing contradictions across three authorities.

Payroll: already inside the tax platform

Payroll is the leg that surprises people, and it is the one where the shift has already happened. Greece’s myDATA is not an invoicing platform with a reporting bolt-on; it is an electronic books platform on which invoices are one document class among several. Businesses transmit income and expense classifications, depreciation, year-end accounting settlement entries — and payroll, submitted monthly. The penalty regime treats failure to transmit payroll records as a distinct offence from failure to transmit invoice summaries, which is a good indication that the authority regards them as equivalent obligations rather than as core plus periphery.

Once payroll, depreciation and adjusting entries are all arriving in structured form, the authority is no longer reconciling a VAT return. It is reconstructing the financial statements. That is a materially different supervisory capability from invoice-level VAT control, and it is the direction other jurisdictions with SAF-T obligations are already travelling in — SAF-T files have always included the general ledger, master data and, in several national variants, payroll.

The connective tissue: one identity, one channel

Extending structured exchange across document types runs into the same bottleneck every time: knowing who the counterparty is, provably, across borders. Every model above depends on it. As Bruno Koch noted years before any of these mandates existed, unique identification of trading partners based on compliant master data is the prerequisite for automated invoicing, not a nice-to-have.

The EU’s answer is the proposed European Business Wallet, published by the Commission on 19 November 2025 as part of its digital package and now in the ordinary legislative procedure. It builds on the European digital identity framework established by Regulation (EU) 910/2014 as amended by Regulation (EU) 2024/1183, and would give every business and public body a single credential for identifying itself, signing and sealing documents, and exchanging them through a qualified electronic registered delivery service with the same legal effect as acting on paper in person. The Commission’s estimate is that broad uptake could unlock up to €150 billion in annual savings for European business — an assumption-heavy number, but one that indicates the scale at which the Commission is thinking about document exchange generally, not invoicing specifically.

Meanwhile Council Directive (EU) 2025/516 sets the tax timetable. Digital reporting requirements for cross-border B2B supplies apply from 1 July 2030, and Member States running domestic real-time transaction reporting must align those systems with the EU model by 1 January 2035. The invoice is the reference implementation. Once thirty-odd national systems have converged on one structured document, standardised addressing and a common validation model, the marginal cost of adding a second document type to that pipeline falls sharply — which is precisely why the second document type keeps arriving.

What this changes about scoping an e-invoicing project

None of the above means you should build for delivery notes and customs data today in a country that does not require them. It means the decisions you make for invoices should not foreclose them.

Evaluate providers on their document catalogue, not their invoice coverage. Ask which Peppol post-award and logistics profiles they support in production, and whether goods-movement reporting in Greece runs through the same contract and connection as invoice reporting or a separate one.
Treat master data as the deliverable. Counterparty identifiers, delivery locations, product classifications and CPV codes are what every subsequent document type will need. A programme that hardcodes these into an invoice mapping will pay for them again for every new document.
Assume one submission will produce several regulatory outcomes. Design the status model accordingly. If a single payload feeds a tax platform, a transport permit and a prefilled return, “accepted” is not one state, and a rejection may land in only one of the three.
Do not assume retention rules follow the invoice. Archiving obligations across Europe are not harmonised even for invoices, and transport documents, payroll records and customs data sit under different retention periods and different authorities.
If you operate in Greece, India, or as a deemed importer into the EU, the expansion is not hypothetical. If you operate only under a domestic invoice mandate elsewhere, you have until roughly 2030 before the EU-level convergence starts constraining your architecture.

The organisations that will handle the next decade cheaply are the ones treating e-invoicing as the first implementation of a transaction data pipeline, rather than as a tax filing with an XML attachment.

Frequently asked questions

Does ViDA require reporting of anything other than invoices?

No. Council Directive (EU) 2025/516 covers invoice data: structured e-invoicing and near-real-time digital reporting for cross-border B2B supplies from 1 July 2030, with domestic real-time reporting systems aligning by 1 January 2035. It says nothing about delivery notes, payroll or customs. The expansion into those documents is happening at national level and through separate EU instruments, not through ViDA.

Is Peppol only for invoices?

No. Peppol’s Post Award Coordinating Community maintains specifications for purchase orders, order responses, catalogues, credit notes and despatch advices, and Peppol Logistics adds the Advanced Despatch Advice, Receipt Advice, Weight Statement and Transport Execution Plan with Request. Invoices are simply the document type that most national authorities mandated first, so they dominate live volumes.

Will payroll reporting spread beyond Greece?

It is already broader than Greece, though usually under a different label. Countries with SAF-T obligations require submission of general ledger and master data, and several national SAF-T variants include payroll. Greece’s contribution is to put payroll on the same real-time platform as the invoice rather than in a periodic file, which is a change of cadence rather than of principle.

Does the EU Customs Data Hub replace customs declarations?

That is the stated design intent: goods would be released once complete and accurate data sits in the hub, rather than on submission of a separate declaration to a national authority. It is not yet live. Use becomes mandatory for deemed importers from 1 July 2028 under the agreement reached on 26 March 2026, with the wider transition continuing into the 2030s, and the final legal text still requires formal adoption.

Should we wait for the picture to settle before investing?

Waiting on scope is reasonable; waiting on foundations is not. The mandates that will arrive between 2026 and 2035 differ in which documents they cover, but they agree on what they need underneath: verified counterparty identity, clean master data, structured line-level detail, and an exchange channel with acknowledgements. Those are worth building now regardless of which document type your jurisdiction mandates next.

Sep

2026

B2C E-Invoicing: Why Receipts Took a Different Road

Till receipts are becoming tax data they are not becoming e-invoices. The transformation is real, it has been running for over a decade, and it happens on a track that European e-invoicing standards were deliberately scoped to exclude — and that ViDA still declines to touch.

The mechanism isn’t EN 16931 or Peppol. It’s fiscalisation, plus a consumer with a reason to identify themselves at the till. Portugal has had both since 2014. If you want to know where B2C is going, don’t read the e-invoicing roadmap — read Portugal’s.

The receipt was never in the numbers

Start with the volume estimate the industry has quoted for years. The Euro Retail Payments Board’s 2016 working group report, citing Billentis, put European e-invoice volume that year at roughly 3 billion in B2C and 5 billion in B2B and B2G, out of an estimated total of about 36 billion invoices and bills.

Read the denominator. Thirty-six billion invoices and bills — not receipts. European retail generates that many transactions in a matter of weeks. The receipt isn’t in the addressable market because it was never considered part of the same universe.

And the 3 billion B2C figure doesn’t mean what it looks like. In the ERPB’s frame, B2C means EIPP — electronic invoice presentment and payment. A utility bill, a telecom bill, an insurance premium: documents presented to a named customer who owes money and will pay later. The report’s whole architecture assumes a payer with an account, a due date, and an identity. That’s not a supermarket transaction. B2C e-invoicing has always meant billing, and billing is not retail.

The European standard was scoped to exclude B2C on purpose

This wasn’t an oversight either. The ERPB report states it plainly: CEN’s work on the European e-invoicing standard is focused on the B2B and B2G segments, with the main scope enshrined in Directive 2014/55/EU and endorsed by the European Multi-Stakeholder Forum — the core semantic data model and the compliant syntaxes. B2C appears only as a note that CEN was, at the time, considering future work on B2C requirements for possible inclusion in the semantic model.

Ten years on, EN 16931 is still the core invoice for business and government transactions. The consumer receipt sat outside the mandate that created the standard, so it sat outside the standard.

ViDA doesn’t close the gap. Its recital 23 permits member states to keep national reporting tools alongside the new real-time obligations — and names, specifically, reporting obligations that are not general, such as those concerning cash registers. Article 273 carries it through. Cash registers are explicitly parked outside Chapter 6 and left to national law. The EU harmonised the intra-EU B2B report down to ten fields and left the till alone.

What’s actually happening: Portugal

Portugal built the thing the brief for this article imagines is coming, and it has been live for a decade.

The flow is simple. At the point of sale the consumer gives their NIF — the taxpayer identification number — and the merchant puts it on the invoice. The merchant’s certified software transmits the invoice data to the Autoridade Tributária, and the transaction appears in the consumer’s e-Fatura account. Every invoice carries an ATCUD unique document code and a QR code. In return, the consumer claims personal income tax deductions on eligible spending, and the data pre-fills their annual IRS return.

Four details make it work, and each one is a design decision worth stealing:

The consumer is paid to authenticate. Tax deductions arrived with the 2015 IRS reform. On top of that sits the Fatura da Sorte lottery, running since 2014: every €10 of NIF-registered purchases automatically generates a coupon. No registration, no action beyond saying yes at the register. The state solved the identity problem by making identity worth money to the person supplying it.
The transport is SAF-T, not an e-invoicing network. Data reaches the AT through SAF-T PT uploads, real-time web services, or manual entry on the portal. Portugal moves consumer receipts down the accounting-extract channel — the one built for audits — not down a four-corner exchange network.
The consumer does the classification. Invoices land in the e-Fatura portal and the taxpayer must validate them and assign each to an expense category, because different categories carry different deductions. Compare Greece, where SAP’s implementation guide derives myDATA’s classification fields per document type from the G/L account. Same data requirement, opposite allocation of labour: Greece makes the ERP do it, Portugal makes the citizen do it.
It isn’t real time. Merchant-reported receipts commonly take around two months to surface in a consumer’s e-Fatura account. The receipt became tax data without becoming a continuous transaction control.

One commentary puts the significance well: this structure sets Portugal apart from the direction most of Europe has taken, where e-invoicing requirements operate as B2B or B2G compliance obligations on businesses. Portugal made the consumer a participant instead of a bystander.

Why a receipt can’t just become an invoice

The obstacle is identity, and it’s structural rather than technical.

Article 226 of the VAT Directive requires the full name and address of both the supplier and the customer on a full invoice. A consumer has no VAT number and, at a till, no established identity at all. A receipt is anonymous by construction — that’s not a deficiency, it’s what a receipt is. Under Article 226b a simplified invoice needs only about four details, and Article 220a permits it for invoices up to €100, which is precisely the shape of retail. The law already built the receipt an exit from the invoice’s requirements.

So a receipt becomes an invoice only when the customer volunteers an identifier. And a customer volunteers an identifier only when something is in it for them. Every scheme that has succeeded at this has attached a consumer benefit — deduction, lottery, or both. Every scheme that has treated it as a compliance obligation on the merchant has produced a QR code nobody scans.

Note what this implies about the direction of travel: the reason ViDA’s reportable set drops Article 226(5) — the parties’ names and addresses — for intra-EU supplies is that VAT numbers resolve identity through VIES. There is no VIES for consumers. Cross-border B2B could be harmonised because businesses are already identified. Retail can’t be, because the buyer isn’t.

What this means if you build for retail

Don’t wait for the e-invoicing standard to arrive. It was scoped out in 2014 and ViDA re-confirmed the exclusion in 2025. If your roadmap has “EN 16931 for POS” on it, move it.

Build for fiscalisation, which is national and unharmonised. Portugal wants ATCUD and QR codes via certified software. Greece wants transmission through a provider with the returned identifiers printed on the document. There is no European format for any of this — the ERPB’s own taxonomy of e-invoicing models has four corners and none of them is a tax authority, let alone a till.

Treat consumer identity as an incentive problem, not a UX problem. “Quer NIF na fatura?” is reportedly the most commonly spoken phrase in Portugal, and it isn’t because the checkout flow is elegant. It’s because the answer is worth money.

Expect the receipt to keep its own lifecycle. It reports on a different channel (SAF-T), at a different latency (weeks, not seconds), to a different regime (national, not Chapter 6), with a different party doing the classification (the consumer). Anything you build that assumes the retail receipt will converge onto the B2B invoice pipeline is betting against ten years of divergence.

Frequently asked questions

Does EN 16931 cover B2C invoices?

No. The standard’s scope, set by Directive 2014/55/EU, is the B2B and B2G segments. CEN was reported to be considering future work on B2C requirements for the semantic model as far back as 2016, but the core invoice remains a business-to-business and business-to-government artefact.

Will ViDA make POS receipts reportable?

Not directly. ViDA’s digital reporting requirements apply to intra-EU B2B supplies from 1 July 2030, and its recital 23 explicitly preserves member states’ non-general reporting obligations such as those concerning cash registers. Retail fiscalisation stays a national matter.

Is a till receipt a valid invoice?

It can be a simplified invoice. Article 226b requires only a handful of details — issue date, identification of the supplier, the type of goods or services, and the VAT payable or the information needed to calculate it — and Article 220a allows simplified invoices where the amount doesn’t exceed €100. It becomes a full invoice only if the customer’s identity is captured, which for a consumer means volunteering a tax number.

How does Portugal get consumers to identify themselves at the till?

By paying them. NIF-registered purchases generate personal income tax deductions, introduced with the 2015 IRS reform, and each €10 of spend automatically generates a coupon in the Fatura da Sorte lottery, running since 2014. The identity problem was solved with an incentive, not a mandate on shoppers.

Are e-receipts real-time reported?

Not in Portugal’s model. Receipts reach the tax authority through SAF-T PT uploads, web services or manual entry, and typically take around two months to appear in the consumer’s e-Fatura account. Some countries run retail closer to real time, but the receipt track and the continuous-transaction-control track are separate developments and shouldn’t be assumed to move together.

Sep

2026

E-Invoicing Models Compared: Clearance, CTC and RTR

The four models people name — real-time reporting, clearance, centralised exchange, five-corner CTC — aren’t four inventions. They’re points on two independent axes, and once you see the axes the design decisions fall out.

Axis one: is validation constitutive? When the state’s platform rejects your invoice, does the invoice cease to exist, or is it just a failed report against a perfectly valid document?

Axis two: is the state in the delivery path? Does the invoice reach your buyer through the government’s platform, or do you deliver it yourself and send the state a copy?

Those two questions produce four quadrants, and one of them is routinely mislabelled.

Two axes, four models

Real-time reporting — not constitutive, not in the path. Hungary’s RTIR, Spain’s SII. You issue and deliver; you report.
Clearance without exchange — constitutive, not in the path. India’s IRP. The state must stamp it, then hands it back to you to deliver.
Centralised exchange — constitutive and in the path. Italy’s SdI. The state validates and delivers.
Five-corner CTC — not constitutive, not in the path, but your provider is licensed. France from September 2026.

The second quadrant is the one that gets lost, because “clearance” and “centralised exchange” are used interchangeably and they are not the same thing. India clears without delivering: Sigitek’s SAP implementation documentation for Indian e-invoicing runs SAP → GSP → IRP, the portal validates and signs and returns the JSON with an IRN, forwards the data to the GST and E-Way Bill systems — and the last step in the vendor’s own architecture is “Print or Email Invoice”. The buyer is not on the network. Italy’s SdI, by contrast, routes the invoice to the recipient’s registered channel and reports a delivery receipt back.

Same word, two architectures, completely different integration.

Validation: the same rejection, opposite consequences

This is the axis that matters most and the one that’s easiest to get wrong, because every model returns something that looks like a validation result.

Hungary’s NAV validates. Invoice data goes to the Online Számla system in XML, immediately via machine-to-machine connection where invoicing software is used, and NAV replies per invoice with accept, reject with error, or warning. It issues an electronic reference number — which notably does not need to be printed on the invoice, because it’s only a reference for potential future audits.

And yet: RTIR is not a clearance model. The invoice is not legally valid because NAV approved it. The supplier remains responsible for issuing a compliant invoice and separately for reporting it. A NAV rejection means your report failed. The invoice is untouched.

Now Italy. A notifica di scarto from the SdI means the invoice is legally treated as never issued. Same act — a state platform returning a negative validation result over a healthy connection — and the opposite legal consequence.

For a product team this is the single most important distinction in the space, and it’s not visible in any topology diagram:

Non-constitutive (Hungary, Spain): a rejection is an operational problem. The invoice is out, the buyer can pay it, and you fix the report.
Constitutive (Italy, India): a rejection is a commercial problem. There is no invoice. Nobody owes you anything yet.

If your data model has one rejected state serving both, it is telling two different lies in two different countries.

The receipt: who keeps the proof

Ask where the evidence lives and the models diverge again — in ways that are almost the reverse of what people assume.

India: you keep it, and the state doesn’t. The IRP allows cancellation only within 24 hours, and the reason commonly given is that the IRP does not store e-invoices for longer than that. The clearance platform is close to stateless. The digitally signed JSON with the IRN that comes back to your system is the artefact, and retaining it is your problem.

Italy: both, with obligations attached. The SdI parks undeliverable invoices in the recipient’s reserved area on the tax authority’s portal, and Italian rules require ten years of compliant electronic preservation — with audits checking delivery receipts, rejection notifications and resubmission logs alongside the invoices themselves.

Greece: printed on paper. SAP Hellas’s August 2024 implementation guide requires the MARK, the UID, the authentication code and the QR code to appear on the invoice printout. The proof of reporting is rendered as ink.

Hungary: held by the authority, and you don’t have to show it. The reference number exists for audit and isn’t printed.

Four models, four different answers to “where is the evidence” — and only one of them (Italy) puts a copy somewhere the state maintains for you.

Failure: what stops when the hub stops

Blast radius is a function of axis two.

Centralised exchange: the government platform is a single point of failure for commerce itself. If the SdI can’t route, the invoice can’t reach the buyer, because an invoice sent directly to the customer isn’t a legally valid document. Commentary on the rise of decentralised models makes exactly this argument — pre-clearance submission undermines established billing processes and makes the authority’s portal a single point of failure.

Clearance without exchange: narrower. If India’s IRP is unreachable you have no IRN, but the delivery channel — print, email — is untouched. The failure is legal, not logistical.

Real-time reporting: narrower still. A NAV outage doesn’t stop you invoicing anyone. It creates a reporting backlog with a three-day correction clock.

Five-corner: failure is distributed and, importantly, has more than one domain. Greece’s guide is explicit about this: it prints one message for a transmission failure between issuer and service provider, and a different one for a failure between the service provider and the tax authority — with an offline QR code minted on the fly during the legal printing process either way. Two failure domains, two messages, one fallback. The API endpoint that issues the fallback identifier is named TransmissionFailure.

That’s the design lesson: in decentralised models you own a failure taxonomy, not a boolean.

Retries and corrections: whose job, and on what clock

Every model gives you a different answer, and none of them is “edit the record”.

Hungary: errors must be resubmitted within three days of the original submission. Note the submission token is live for roughly five minutes — a detail that quietly rules out certain queue designs.
Italy: a rejected invoice must be corrected and resubmitted within five days, reusing the same invoice number and date.
India: cancel within 24 hours, or issue a credit note referencing the original IRN — and you must not reuse the invoice number. Also, if an e-way bill is active against the IRN, cancellation is blocked entirely.
Greece: on the service-provider route, the cancel function isn’t available at all; credit notes substitute for it.

Italy requires number reuse. India forbids it. Both are mandatory, both are penalised, and they are the same engineering decision. Any global policy on document numbering is wrong in at least one of these markets.

The axis the diagrams miss: who holds the licence

There’s a third axis, and it doesn’t appear in any corner diagram because it isn’t topological.

In France, invoices flow through accredited private platforms registered by the tax administration for renewable three-year periods, with software that merely creates invoices unable to connect to the public portal directly. Greece’s provider framework does the same, and choosing that route removes an operation — cancellation — from your state machine. Spain’s forthcoming regime is heading the same way: reporting suggests the government will approve agents against interoperability, digital security and continuity-planning criteria, with the private operator responsible for signing the invoice before forwarding it to both the customer and the tax authority.

So the real question in a five-corner market isn’t how many hops there are. It’s whether your provider holds a current licence, and what that licence obliges them to do about you.

Using this

Classify before you build. For each market, answer the two questions — is validation constitutive, is the state in the path — before looking at any API documentation. They determine your error semantics and your delivery architecture, and no amount of integration work fixes a wrong answer.

Model rejection twice. One state for “the report failed”, one for “the invoice does not exist”. They need different UI, different notifications and different accounting consequences.

Treat the receipt as a first-class record. Especially where the state doesn’t keep one for you, which includes the biggest clearance system in the world.

Expect countries to move between quadrants. Hungary has confirmed structured domestic B2B e-invoicing in phases from 2028, replacing RTIR — a move from the reporting quadrant to a mandate. Spain is running SII alongside a new regime that reporting suggests will offer a choice between a hybrid five-corner private network and direct state platforms, with the two likely consolidated later. The quadrant is not a permanent property of a country.

Frequently asked questions

What’s the difference between clearance and real-time reporting?

Whether the validation is constitutive. Under clearance, the authority or its platform must validate and return a confirmation — an identifier, a signature, a QR code — before the invoice is legally issued. Under real-time reporting, you issue a valid invoice and separately transmit data; the authority may still validate and reject, but the invoice stands. Hungary’s RTIR and Spain’s SII are reporting regimes. Italy’s SdI and India’s IRP are clearance.

Is clearance the same as centralised exchange?

No, and conflating them is the most common error here. India’s IRP clears an invoice and hands it back to the supplier, who then prints or emails it — the buyer never touches the government platform. Italy’s SdI clears and delivers. Same legal category, different delivery architecture, different integration.

Which model does ViDA use?

Real-time reporting, decentralised. From 1 July 2030 data is transmitted per transaction at the moment the invoice is issued, and the authority isn’t placed between supplier and buyer. Member states with domestic real-time systems in place on 1 January 2024 have until 1 January 2035 to align.

Where does my architecture actually differ between models?

Three places. Error semantics — is a rejection commercial or operational. Delivery — do you own the channel or does the state. And evidence — who retains the proof and for how long. Everything else is a schema mapping.

Can one country run more than one model?

Yes, and several do. Spain has run SII reporting since July 2017 and is layering an e-invoicing mandate on top, with consolidation expected later rather than at launch. France separates exchange through accredited platforms from reporting through the public portal. Assume overlap is the normal state, not a transitional one.

Sep

2026

5-Corner Model Explained: A License, Not a Network

Topologically, the five-corner model is the four-corner model with a reporting leg bolted on. Sender, sender’s provider, receiver’s provider, receiver — then a copy of the data goes to the tax authority. As network architecture, that’s a footnote.

The novelty isn’t the corner. It’s that the fifth corner is not a participant on the network at all — it’s a regulator with a data feed, and its arrival turns the other four corners into licensed entities. The model is a governance arrangement wearing a topology diagram. And the clearest proof is that when one government tried to actually be a corner, it gave up and handed the job to seventy private companies.

What the fifth corner actually is

Start with what came before, because the omission is instructive. The Euro Retail Payments Board’s 2016 working group report categorised e-invoicing solutions by the number of intermediary platforms in the presentation flow: Supplier Direct, Buyer Direct, three-corner, four-corner. The tax authority is not a corner in any of them. In 2016 that wasn’t an oversight — corners were counted by who sat in the path between a supplier and a buyer, and the tax authority didn’t.

It still doesn’t. In a five-corner architecture the invoice travels sender → provider → provider → receiver exactly as before. The authority receives a copy on a separate leg. It is not in the delivery path, it does not route, and — unlike every other corner — it cannot be chosen, switched, or negotiated with.

Which is why the industry’s own name for this is more honest than the diagram: DCTCE, Decentralized CTC and Exchange. Two functions, named separately, in one acronym. The exchange is decentralised and private. The controls are centralised and public. Calling the second one a “corner” implies a symmetry that doesn’t exist.

France tried to be a corner and quit

France designed the most ambitious version of this and then walked it back in public, which makes it the best available evidence about what the model really is.

The Portail Public de Facturation was originally specified with three functions: a free-to-use B2B e-invoicing platform available to any sender or receiver, a central business directory, and a data concentrator. The first one is the interesting one — the state offering itself as a service to business, a genuine fifth corner you could actually connect to and use for free.

On 15 October 2024, the DGFiP announced it was dropping that function. The PPF no longer handles the issuing or receiving of invoices. Every business inside the mandate must now use a certified private platform. The PPF kept the directory — mapping each French business to its chosen platform — and the concentrator role, routing data upward to the tax authority and, where two platforms have no direct bilateral connection, relaying flows between them. It runs entirely in the background; most businesses will never touch it.

Two explanations circulate for why, and they don’t agree.

The official one is success: the administration justified the decision on the grounds that the private platform ecosystem had become robust and dynamic enough to meet business needs, with over 70 platforms registered. The other, reported alongside the reform’s earlier delays, is that development of the centralised platform had been significantly underestimated. Those are very different stories — one says the market outgrew the state’s offer, the other says the state couldn’t ship. Both are in circulation; neither has been conceded.

Either way the outcome is the same, and it’s the point of this article: the state removed itself from the exchange and kept the data. That is the five-corner model’s actual shape, arrived at not by design but by subtraction.

The real change: your provider becomes a regulated entity

Here’s what actually happens when the fifth corner arrives, and it has nothing to do with routing.

In France, invoices flow between businesses through accredited private platforms — Plateformes Agréées, formerly PDPs — which validate, transmit and route them, and report the required data to the tax authority through the PPF. Those platforms are registered by the tax administration for renewable three-year periods. Software that merely creates invoices — Solutions Compatibles — cannot connect to the PPF directly at all; it has to go through an accredited platform.

Read that again as a business model rather than an architecture. A private company now holds a time-limited state licence to move other companies’ invoices, and part of the licence is an obligation to report those companies to the tax authority. The provider is simultaneously your vendor and the state’s collection point. Greece does the same thing through its YPAHES provider framework; the SAP implementation guide for Greek e-invoicing notes that choosing the service-provider route removes the ability to cancel a document entirely.

That’s the trade the fifth corner makes. Not “the state gets data and business gets services”. More precisely: the state outsources the pipe and regulates the plumbers.

The genuine benefit, stated precisely

There is a real advantage here, and it deserves to be argued properly rather than asserted.

The first part is negative and substantial: no state monopoly in the delivery path. Commentary on the model’s rise notes that it’s gaining ground precisely because pre-clearance submission undermines established billing processes and makes the authority’s portal a single point of failure. In a clearance system, when the government hub is down, commerce stops. In a decentralised one, invoices keep moving and the reporting leg catches up.

The second part is where the “new internet” framing actually earns its keep. A four-corner network is general-purpose. Peppol carries orders, catalogues, despatch advices, order responses and — since 2025 — its own status messages, over a federated discovery layer where any participant can find any other. Italy’s SdI, by contrast, is an invoice system. It can only ever be an invoice system. A country that builds a clearance hub has built a very expensive pipe that carries one document type; a country that regulates a network inherits a pipe that carries everything, at no cost to the treasury.

That is a real difference in kind, and it’s the strongest argument for the model. It just isn’t the argument about tax.

The obligations are mandatory. The benefits are optional.

This is the part most explainers skip, and it complicates the “benefits everyone” story considerably.

The reporting leg is compulsory. The features that make the network valuable to business are not.

Peppol’s Message Level Response — the mechanism that tells a sender whether their document passed validation — is an optional document. Not every sender supports receiving one; the receiver has to query the discovery service to find out whether the sender declared the capability. Its adoption was low precisely because it depended on end-user participation. For years, a sender’s access point could transmit to a receiver’s access point, get an AS4 acknowledgement confirming gateway delivery, and know essentially nothing about what happened next. The gap was serious enough that Peppol finalised Message Level Status in May 2025 — a provider-to-provider feedback mechanism — specifically because visibility past the gateway was largely opaque.

So on the state’s side: a mandatory, accredited, licensed, per-transaction data flow with legal consequences for failure. On the business’s side: an optional response document with historically low adoption, and a status layer that took until 2025 to standardise. Both are real. They are not symmetrical, and any pitch that presents them as a balanced exchange of value is describing the design intent rather than the deployed system.

What to actually evaluate

Ask who is licensed, not who is connected. The meaningful question about a five-corner market isn’t network topology — it’s who holds the accreditation, for how long, and what they’re obliged to report. In France that’s a renewable three-year registration. Your provider’s licence is now part of your compliance surface.

Check whether the optional layer is actually turned on. Before assuming end-to-end visibility, verify what your counterparties support. A network capability that exists in a specification and not in your trading partners’ configuration is a roadmap item, not a feature.

Value the general-purpose pipe separately from the mandate. If the network only ever carries your invoices, you’ve paid for a clearance system with extra hops. The orders, catalogues and responses are where the four-corner investment repays itself — and they’re outside the mandate, which means nobody will make you adopt them.

Don’t assume the model is settled. France redefined its architecture two years before go-live, and the same commentary that named the change also observed the country would probably move to a five-corner model rather than the Y-schema originally communicated. The topology diagram is the most likely part of any national scheme to change.

Frequently asked questions

What is the 5-corner model?

A four-corner exchange — sender, sender’s provider, receiver’s provider, receiver — plus the tax authority receiving transaction data on a separate leg. It’s also called DCTCE, Decentralized CTC and Exchange. The authority isn’t in the delivery path; it gets a copy.

Is the tax authority really a “corner”?

Not in the sense the other four are. Corners in the original taxonomy were intermediaries in the path between supplier and buyer, which is why the Euro Retail Payments Board’s 2016 model has no corner for a tax authority. The fifth corner can’t be chosen or switched, doesn’t route anything, and imposes obligations on the other corners. It’s a regulator with a data feed.

How is 5-corner different from clearance?

In clearance — Italy’s SdI, India’s IRP — the authority sits in the delivery path and the invoice isn’t valid until the platform returns an identifier. In a five-corner model the invoice travels between private providers and the data goes to the authority separately, so a government outage doesn’t stop invoicing. It also means the state doesn’t build or run the exchange.

Why did France abandon the PPF as a platform?

On 15 October 2024 the DGFiP announced the PPF would no longer issue or receive invoices, keeping only the directory and data-concentrator roles. The official reason was that the private platform ecosystem — 70-plus registered providers — was robust enough to serve businesses. Reporting around the reform’s earlier delays attributes it instead to the development effort for the centralised platform having been significantly underestimated. The two explanations coexist.

Does 5-corner mean I can keep my existing provider?

Only if they hold the relevant national accreditation. That’s the catch: the model preserves your choice of provider in principle while shrinking the eligible set to those the tax administration has registered — in France, for renewable three-year terms.

Sep

2026

SAF-T vs CTC vs E-Invoicing: How They Fit Together

They are not three stages of one evolution. They are three different objects. E-invoicing carries the document you sent to your buyer. CTC transmits the transaction you issued, at the moment you issued it. SAF-T exports what you booked — the general ledger, the master files, the whole accounting record — either when the tax authority asks, or on a monthly cycle.

Those three things can disagree with each other. That is the entire reason a tax administration wants all three. And it’s why ViDA — which people keep describing as the end of periodic reporting — explicitly preserves SAF-T in the same breath as it mandates real-time transmission.

The map: what distinguishes them is the source object

Most explanations sort these by speed, which is why they end up confusing. Sort them by what the data is extracted from and the model resolves.

E-invoicing — source object: the invoice document. Recipient: the buyer. Governed by Directive 2014/55/EU and EN 16931. Deadline under ViDA: ten days from the chargeable event (Article 222). Integrity model: schema plus Schematron validation.
CTC — source object: the transaction as invoiced. Recipient: the tax authority. Governed by Chapter 6 of the VAT Directive as replaced by ViDA. Deadline: the moment the invoice is issued (Article 263(1)). Integrity model: cross-checking your report against your counterparty’s.
SAF-T — source object: the accounting record. Recipient: the tax authority or an auditor. Governed by national law, built on an OECD template. Deadline: on request, or periodically. Integrity model: referential integrity across the file.

Different objects, different owners inside your business. The invoice belongs to billing. The CTC report belongs to tax. The SAF-T file belongs to finance and the chart of accounts. A project that treats them as one integration will discover this the hard way.

SAF-T: the ledger, on request

The OECD’s Committee on Fiscal Affairs published SAF-T version 1.0 in May 2005, built around entries from a General Ledger Chart of Accounts together with master file data for customers and suppliers, and details of invoices, orders, payments and adjustments. Version 2.0, published in 2010, added inventory and fixed assets, and moved the schema from DTD to XML Schema — not fully backward compatible with 1.0.

Read the OECD’s own statement of purpose and the difference from CTC is immediate: SAF-T exists so that errors can be identified and quantified efficiently in the initial stages of an audit, letting auditors target resources at errors with material impact. It is audit tooling. The guidance even frames self-audit as a benefit — businesses reviewing their own transactions and adjusting before a return is filed. Nothing about that is real-time, and nothing about it is transactional control.

Two design details matter for anyone building to it. First, constraints are a deliberate feature: where a customer reference appears at transaction level, there must be a corresponding entry in the customer master file. SAF-T’s integrity model is referential integrity across the whole extract — a fundamentally different test from “does this invoice validate”. Second, the schema includes deliberate extension points, and the OECD is explicit that adding elements anywhere else makes the file incompatible with the OECD model. That is the same narrow-and-widen pattern EN 16931 uses with CIUS and Extensions, arrived at independently.

In practice there is no harmonised European SAF-T. Portugal went first in 2008 — mandatory for large firms using computerised accounting from 2009, extended to all VAT-registered entities by 2013 — and SAF-T (PT) integrates with the e-fatura system. Austria implemented it in 2009 on an on-demand basis. Luxembourg’s FAIA followed in 2011, on request, with penalties reported at up to EUR 5,000 per infraction or EUR 50–1,000 daily. Norway serves it on demand through Altinn. France uses FEC, its own SAF-T-inspired format, entirely separate from the OECD schema. Each country adapts, and the extension points are why they can.

CTC: the transaction, as it happens

Continuous transaction controls invert SAF-T’s direction. Instead of the authority reserving a right to come and look, the data arrives on its own.

Under ViDA, from 1 July 2030, an intra-EU B2B supply is transmitted per individual transaction at the moment the invoice is issued or should have been (Article 263(1)), carrying ten data points fixed identically across every member state (Article 264) — Article 226 points 1 to 4, 6, 7, 8, 11, 16 and 17, plus 11a where applicable. The customer reports within five days of receipt unless the member state waives it. Recapitulative statements are abolished outright: Articles 265 to 271 are deleted.

What CTC can see is exactly one thing: invoices, as issued. That is a narrow window, and it is the reason SAF-T survives.

E-invoicing: the exchange, which is neither of the above

E-invoicing is the only one of the three that isn’t a reporting obligation at all. It’s a private exchange between a supplier and a buyer, and its purpose is that the buyer can book and pay.

The historical proof sits in the Euro Retail Payments Board’s 2016 working group report, which categorises e-invoicing solutions by the number of intermediary platforms in the presentation flow: Supplier Direct, Buyer Direct, three-corner, four-corner. The tax authority is not a corner in any of them. In 2016 that wasn’t an omission — e-invoicing was defined as a two-party exchange, and the industry only invented a fifth corner once tax authorities arrived.

The dependency now runs the other way, and only one way. ViDA’s new Article 217 requires an invoice to be structured “at least in relation to the data referred to in Articles 262 and 271b” — the reporting articles. The reporting layer sets the structured floor for the exchange layer. Not your buyer’s needs. Not yours.

Why ViDA doesn’t kill SAF-T — and says so

This is the part the vendor explainers skip, and it’s decided in the directive’s own text.

ViDA’s recital 23 states that member states should be allowed to keep their national reporting tools — based, for example, on a SAF-T system — alongside the real-time obligations the directive introduces, together with non-general obligations such as those covering cash registers. It then draws the line explicitly: the ability of member states to request information from taxable persons during audits should not be limited, insofar as such information is obtained only at the member state’s request and does not result from active communication by taxpayers.

That sentence is the architecture. Pull versus push. Information the authority asks for is audit logic and stays permitted without limit. Information the taxpayer actively transmits is reporting logic and is now governed by Chapter 6. Article 273 carries it into the operative text: member states may not impose new general transaction-based reporting obligations on Article 262 transactions beyond Chapter 6 — but they may require taxable persons to keep transaction data for preparing the VAT return or for audit purposes, and they may impose reporting obligations for transactions outside Chapter 6’s scope.

So the boundary isn’t speed. It’s who initiates. And it means the practical answer to “does CTC replace SAF-T” is no: CTC takes the invoice-shaped transactions inside Chapter 6, and SAF-T keeps everything else — accruals, fixed assets, stock movements, bad debt relief, the credit note you never issued, the journal entry that reclassified a cost. CTC cannot see any of that, because none of it is an invoice.

Where the three collapse into one: Greece, Lithuania, Poland

The clean model above is a way to reason, not a description of what countries build. Three examples show the layers fusing.

Greece is the sharpest case, and SAP’s August 2024 implementation guide for Greek e-invoicing states it outright: myDATA accepts all revenue, expense and VAT-related documents from Greek businesses, thereby fulfilling the eBooks requirement — and the purpose of myDATA is the reconciliation of the accounting records of the liable entities with the tax authority’s e-books. That is a SAF-T objective. It is delivered over CTC plumbing (real-time submission through a certified service provider, with the platform returning a MARK, a UID and an authentication code) which itself rides on the e-invoicing exchange layer. All three layers, one message.

The tell is in the field list. The myDATA XML carries invoice type, total amount, net amount, VAT category — and then classification category and classification type. Those last two aren’t invoice fields at all; they’re accounting classifications, and SAP’s mapping derives them per document type from the G/L revenue or supplier offsetting account. A field in the invoice message whose value comes from the chart of accounts is the ledger layer bleeding into the transaction layer, in production.

Lithuania keeps them separate and names them. The i.MAS platform runs i.SAF for invoices, i.SAF-T for accounting data, and i.VAZ for goods transport — three modules, three source objects, one platform. The architecture in this article is not a theory; one member state shipped it as a product structure.

Poland runs both, and merged one of them with the VAT return. JPK arrived in July 2016 for large taxpayers and covered everyone by 2018. In 2020 JPK_VAT was replaced by JPK_V7M and JPK_V7K, which fold the VAT return and the underlying records into a single file — the return stopped being a separate document. Of the seven JPK structures, only JPK_V7M/K is submitted on a cycle, by the 25th; the rest, including the general ledger structure, are produced on request. And Poland mandates KSeF for e-invoicing on top. Two obligations, two layers, no overlap in the data.

The decisions, in the order you’ll face them

First: which layer does this requirement live on? If it names a document going to a counterparty, it’s exchange. If it names a transmission at the moment of issue, it’s CTC. If it names the general ledger, master files, or “on request”, it’s SAF-T. Requirements that name a G/L account inside an invoice message — Greece — are telling you the country has fused two layers, and your project scope just doubled.

Second: pull or push? Pull obligations are a data-availability problem: can you regenerate a consistent, referentially intact extract for a period that closed three years ago, after a chart-of-accounts migration? Push obligations are a latency and failure-handling problem: what happens at 14:59 when the endpoint is down and the invoice is issued at 15:00? These are not the same engineering problem and they rarely belong to the same team.

Third: assume they’ll be reconciled against each other. The reason to hold all three is that they’re derived from different objects and should agree. Greece says so explicitly — reconciliation of your accounting records against the authority’s copy. If your invoice data and your ledger data have never been reconciled internally, a tax authority is about to do it for you.

Frequently asked questions

Is SAF-T being replaced by CTC?

No. ViDA’s recital 23 explicitly permits member states to keep national reporting tools based on a SAF-T system alongside the directive’s real-time obligations, and Article 273 lets them require data retention for VAT return preparation and audit, and impose reporting on transactions outside Chapter 6. What Article 273 blocks is new general transaction-based reporting duplicating Chapter 6 for Article 262 transactions.

What’s the actual difference between SAF-T and CTC?

Source object and direction. SAF-T extracts the accounting record — general ledger, master files, fixed assets, inventory — and is typically produced on request. CTC transmits individual invoice transactions as they are issued. A CTC system can’t see a journal entry; a SAF-T file doesn’t arrive in real time.

Is e-invoicing a reporting obligation?

Not inherently. It’s an exchange between two businesses. Mandatory e-invoicing exists in countries with no tax authority controls at all, and in those cases nothing is reported to anyone. It becomes entangled with reporting only where a mandate connects the two — which, from 1 July 2030 for intra-EU supplies, ViDA does.

If a country has CTC, do I still need to file SAF-T?

Country by country, and frequently yes. Poland runs KSeF and JPK. Romania runs RO e-Invoice and the D406 SAF-T declaration. France is introducing mandatory e-invoicing while FEC remains a separate on-demand obligation. Budget for both unless the specific national law says otherwise.

Do the three ever carry the same data?

They overlap and none contains another. The invoice carries line items and delivery details the tax authority never receives. The ViDA report carries ten fields and not the parties’ names and addresses. SAF-T carries fixed assets and journal entries that never touched an invoice. Greece’s classification fields exist in the invoice message purely because myDATA is doing an accounting job through an invoicing channel.

Sep

2026

E-Invoice Status Design: Submitted Is Not Accepted

An e-invoice has at least five statuses, and they are five different questions. Did the bytes arrive at the next hop? Did the document pass validation? Does the invoice legally exist? Does the counterparty agree with it? Can you prove any of this in ten years?

Most implementations collapse these into one field called status, and the collapse is where the defects live. A rejection arrives over a perfectly healthy connection. A delivery failure can be a terminal success. And the single most expensive state — “we don’t know” — usually isn’t modelled at all.

The five layers

Sorted by the question each one answers, not by the order they happen in.

Transport status — did the message reach the next hop? An HTTP code, an AS4 acknowledgement. Purely technical, and it says nothing whatsoever about the invoice.
Validation result — did it pass schema and business rules? Peppol’s MLR, Italy’s notifica di scarto, a JSON syntax error.
Legal status — does the invoice exist for VAT purposes? Greece’s MARK, India’s IRN, Italy’s ricevuta di consegna.
Counterparty acceptance — does the buyer agree? Peppol’s Invoice Response. This is a commercial axis, not a tax one.
Audit evidence — can you reconstruct the above years later? Signatures, authentication codes, retained receipts.

These are not stages of a pipeline. They’re orthogonal. You can be transport-successful and legally non-existent at the same time — that’s the normal case for a rejection.

A rejection is a successful transport

Italy’s Sistema di Interscambio is the clearest vocabulary anyone has built for this, because it names each state separately and attaches different legal consequences to each.

Submit a FatturaPA file and the SdI runs its checks, then returns one of several notifications. A notifica di scarto (NS) is a rejection with a numeric error code — and a rejected invoice is legally treated as never issued. The sender has five days to correct and resubmit, reusing the same invoice number and date to avoid penalties. A ricevuta di consegna (RC) means the invoice is both issued and delivered. And a mancata consegna (MC) means the recipient’s channel was unreachable: the SdI parks the invoice in the buyer’s reserved area on the Agenzia delle Entrate portal, and the invoice is still legally issued — delivery failure doesn’t invalidate it for VAT — but the sender must retain the MC notification as proof and tell the customer.

Read those three again as state transitions:

NS — transport succeeded, invoice does not exist.
RC — transport succeeded, invoice exists, buyer has it.
MC — transport succeeded, invoice exists, buyer does not have it, and this is a terminal success with an obligation attached rather than an error to retry.

All three arrive over the same healthy connection. A system whose status field is set from the HTTP response cannot distinguish any of them. And MC is the one that breaks naive designs: it looks like a failure, it is not a failure, and retrying it is wrong.

Peppol splits the same problem across three message types. The AS4 transport acknowledgement confirms gateway-to-gateway delivery and nothing more. The Message Level Response (MLR) reports the validation outcome, with codes like AP for accepted and RE for rejected. The Invoice Response — the business-level response — carries the buyer’s commercial decision: accepted, rejected, or under query. Three layers, three documents, and the industry considered the gap between them serious enough that Peppol finalised Message Level Status (MLS) in May 2025 specifically because MLR adoption was low and end-to-end visibility after the gateway was largely opaque.

The state nobody models: unknown

The best artefact in this entire subject is buried in SAP Hellas’s August 2024 implementation guide for Greek e-invoicing, and it’s worth reading closely.

The guide introduces a table, zgrein_edogrinv, that carries both a STATUS field and an HTTP_CODE field. Two status columns, side by side, in one table — because they answer different questions. It then defines the print logic in three branches:

Success — http_code = 201. The invoice reached the tax authority and a MARK was assigned. Print the MARK, the UID, the authentication code and the QR code.
Transmission failure between issuer and service provider, or a business error, or a JSON syntax error — http_code is neither 408 nor 201. Print an offline QR code, generated on the fly during the legal printing process.
Transmission failure between service provider and the tax authority — same offline QR treatment, different printed message.

Three things are happening here, and each is a lesson.

408 is carved out deliberately. A request timeout is the one code that means we don’t know — the submission may have landed. It gets neither the success path nor the failure path. That’s the unknown state, explicitly handled, and it’s the state most homegrown integrations skip straight past into a retry loop that duplicates invoices.

Transport failure and JSON syntax error share a branch. A network outage (not your fault, the invoice is fine) and a malformed payload (your fault, the invoice is wrong) both fall into the same condition and produce the same printed outcome. That’s the conflation this article is about, in production, in a vendor’s official guide. The branch is correct for the immediate purpose — print something legal — and wrong for everything downstream, because one of those needs a retry and the other needs a code fix.

When nobody is reachable, you mint your own evidence. The offline QR exists because the invoice has to be printed regardless, for business reasons, when communication fails through network outage or application errors. The API endpoint that issues it is literally named TransmissionFailure. That is a fifth state — issued, unreported, evidence self-generated — and it has no equivalent in any status enum that runs from pending to sent to error.

The same guide contains the whole thesis in one configuration note: the status field can drive specific messages on the invoice printout if it is not SUBMITTED. Submitted is the happy path. Everything else has to say so, on paper, to a human.

Validation is not a property of the document

This one surprises people. SAP’s own documentation on Peppol message types notes that the sending and receiving access points may be checking against different versions of the Schematron rules — so a document can pass validation at the sender’s access point and fail at the receiver’s.

Validity, then, is a property of a document and a validator and a moment in time. Italy makes the same point on a schedule: FatturaPA v1.9.1 takes effect 15 May 2026 with new error codes, and a file that validated two years ago can fail today if your generator hasn’t tracked the specification. If you cache a boolean is_valid against an invoice, you have stored the answer to a question that has since changed.

Worse, absence of rejection is not acceptance. Peppol’s MLR is an optional document — not every sender supports receiving one, and the receiver has to query the SMP to find out whether the sender does. If your model treats “no negative response” as success, it will report success for every counterparty that never agreed to tell you.

Acceptance is a different axis entirely

Tax acceptance and commercial acceptance are unrelated, and conflating them produces the worst class of bug: a legally valid invoice marked as failed because the buyer disputed it, or an accepted invoice that never legally existed.

Peppol keeps them apart by design — an MLR rejection is a technical failure you fix with better validation, while an Invoice Response rejection is a business dispute that requires a conversation. Italy keeps them apart too, and asymmetrically: public administrations can refuse an invoice received through the SdI and the system carries a separate outcome notification plus a deadline notification for when the acceptance window expires. B2B buyers get no such right — once an invoice clears for VAT, the buyer cannot reject it, and the remedy is a credit note.

So “rejected” means at least three unrelated things depending on who said it. Model the speaker, not just the verdict.

Your state machine’s transitions are legislated

Here’s the constraint that catches product teams: the transitions are not yours to design.

SAP’s Greek guide describes a framework offering submission, cancellation, resubmission and deletion of e-documents, with deletion only available in the created status. Then it records that, following a Greek ministerial decision, the cancel function is no longer available at all — companies must issue credit notes as a substitute. A transition was removed from the state machine by law, after the software was built.

The same guide ships a configuration table, EDOMETASTATUSV, whose entire purpose is assigning eDocument process status to status. Roughly twenty process states — matched, match error, cancelled, created, deviation rejected, added to summary — collapse onto three status codes. The mapping table exists precisely because the process status and the status are not the same thing, and someone had to write down the relationship. Note also that the guide’s V3 revision renamed the old status field to http_status. Somebody hit this ambiguity and fixed it in the field name.

What to build

Separate fields, not one enum. At minimum: transport outcome, validation outcome, legal identifier (present or absent), counterparty response, and evidence reference. Greece ships two of these in one table already. Derive a display status from them; never store only the derived value.

Model unknown as a first-class state. Timeouts, not just successes and failures. An unknown submission needs a reconciliation query against the authority, not a retry — retrying an invoice that landed is how you create duplicates in a system where the sequential number is legally significant.

Make failure states carry their obligation. Italy’s MC requires retaining the notification and notifying the customer. Greece’s transmission failure requires printing an offline QR. Neither is “retry later”. If your error state has no field for the obligation it triggers, someone will do it manually or not at all.

Store the evidence, not a log line. Under ViDA, Article 138(1a) removes the exemption for an intra-Community supply where the supplier hasn’t met the transmission obligation or the data is wrong — unless the failure can be duly justified to the competent authorities. “Duly justified” is a data requirement. It means the artefact that proves you tried, retained for as long as the invoice itself: Italy requires ten years of electronic preservation, and audits check the receipts, rejections and resubmission logs alongside the invoices.

Frequently asked questions

What’s the difference between an MLR and an Invoice Response in Peppol?

An MLR is a technical response about validation — it tells you whether the document was structurally acceptable and processed, using codes such as AP and RE. An Invoice Response is a business-level document carrying the buyer’s commercial decision: accepted, rejected, or under query. An MLR rejection is fixed with better validation. An Invoice Response rejection is a dispute.

If I get an HTTP 200, is my invoice filed?

No. The transport succeeded; that’s all you know. In Italy the same successful connection can carry a notifica di scarto, which means the invoice is legally treated as never issued. In Greece, only http_code = 201 with a returned MARK means the tax authority holds it.

What should happen on a timeout?

Not a blind retry. A timeout is the unknown state — the submission may have been processed. Query the authority for the document’s status before resubmitting, because re-sending a landed invoice creates a duplicate against a sequential number that carries legal weight. Greece’s guide treats HTTP 408 as its own branch for exactly this reason.

Can a delivery failure be a success?

Yes. Italy’s mancata consegna means the invoice is legally issued but the buyer’s channel was unreachable, so it sits in their portal area. It doesn’t invalidate the invoice for VAT. It’s a terminal state with two obligations — retain the notification, inform the customer — not an error to retry.

How long do I need to keep the receipts?

As long as the invoices, and treat them as part of the same record. Italy requires ten years of compliant electronic preservation and audits verify the delivery receipts, rejection notifications and resubmission logs. Under ViDA, the ability to duly justify a transmission failure is what stands between you and losing an exemption — which is only possible if the evidence survived.

Sep

2026

E-Invoice Corrections: Why You Can’t Just Cancel It

Once an invoice has cleared a tax authority, it is immutable. You cannot edit it. In most systems you cannot cancel it either, and where you can, the window is measured in hours and closing. What you get instead is a third verb: supersede. Issue a new document that points at the old one, and let the tax authority reconstruct the graph.

This is the part of e-invoicing that product teams model last and pay for first. The send is the easy bit — one document, one API call, one status. The lifecycle is a directed graph of documents that reference each other, some of which your counterparty creates, some of which lock others, and all of which are separately reportable.

Cancellation is a narrow exception, and it’s disappearing

India is the clearest illustration because its cancellation rule has a reason nobody expects. An e-invoice can be cancelled on the Invoice Registration Portal only within 24 hours of the IRN being generated — and the reason commonly given is that the IRP doesn’t store e-invoices for longer than that. The window on a legal operation is set by an infrastructure retention policy. After it closes, the portal simply blocks the option.

Three further constraints stack on top:

Amendment doesn’t exist at all. Once the IRN is generated the data is locked. Taxable value, tax rate, buyer details — none of it can be changed on the original. Changes are made when filing GSTR-1, and those get flagged to the officer, who may come back asking questions.
Partial cancellation is impossible. It’s the whole invoice or nothing.
A downstream document can veto it. If an e-way bill is active against the IRN, the IRP will not permit cancellation. The goods are moving; the invoice is pinned.

That last one is the shape of the whole problem. Your invoice is not a leaf node. Something else is holding a reference to it, and that reference removes an operation from your state machine.

Greece removes the operation differently, and SAP Hellas’s August 2024 implementation guide records it precisely: because the solution uses a service provider under the Greek YPAHES framework, the cancel function is no longer available, and companies must issue credit notes as a substitute for cancellations. Read the causation carefully — cancellation wasn’t banned outright, it was removed by the compliance route. The same SAP framework offers submission, cancellation, resubmission and deletion, with deletion only possible while the document is still in created status. Pick the service-provider path and one of those verbs quietly goes away.

Which means the available lifecycle operations are a function of the country and the architecture, not of your product. You do not get to decide whether your users can cancel.

Everything else is a new document pointing at the old one

The universal fallback is the credit note, and it’s worth being precise about what it is: not an edit, not a reversal flag, but a separate fiscal document with its own identity that references the original.

In India, once the 24 hours have passed, a credit note (for a reduction) or debit note (for an increase) referencing the original IRN is the only route — and that note must itself be e-invoiced where the supplier is inside the mandate threshold, generating its own IRN. The correction is recursive: fixing a reported document produces another reported document. In Italy, credit notes (TD04) and debit notes (TD05) go through the SdI referencing the original, on the same clearance path as the invoice itself.

ViDA then does something that makes this explicit in EU law. From 1 July 2030, Article 226 gains point 16: the sequential number of the corrected invoice, on a corrective invoice. The pointer becomes a mandatory legal field. And Article 264 puts point 16 inside the ten data points transmitted to the tax authority for a cross-border supply — so the edge of the graph is itself reported. The authority isn’t inferring the relationship from your reference field. It’s receiving it.

The simplified-invoice rule (Article 226b) has carried the same logic for years: a corrective document needs a specific and unambiguous reference to the initial invoice and to the specific details being amended. Note the second half. Not just “which invoice” — “what changed”.

What ViDA conspicuously does not add is a cancellation message. There is no “unsend” in the reporting model. Corrections are documents, and documents are all the authority sees.

Two countries, one question, opposite answers

Here’s the finding that should kill any attempt at a single global correction policy.

When Italy’s SdI rejects an invoice with a notifica di scarto, the invoice is legally treated as never issued, and the sender has five days to correct and resubmit — reusing the same invoice number and date to avoid penalties. The number must be reused, because as far as the law is concerned nothing was ever issued under it.

In India, after cancelling an IRN, you must not reuse the invoice number to generate a new one. The number is burned.

Same engineering question — is a document number reusable after a failed attempt? — and two mandates give opposite answers, both mandatory, both penalised. If your sequence generator has a global policy on reuse, it is wrong in at least one jurisdiction. This has to be per-country configuration, and it has to sit at the point where numbers are minted, which is usually the last place anyone wants country logic.

The graph has edges you don’t control

The lifecycle isn’t only yours to drive. Three examples, all live:

Your buyer can report you. Italy introduced document type TD29 in version 1.9 of the FatturaPA specification in April 2025, letting a buyer flag a supplier’s omitted or irregular invoice through the SdI — shifting part of the compliance responsibility onto the buyer. TD20 already allowed buyers to self-invoice omitted or irregular supplies. Your invoice’s lifecycle now has state transitions initiated by someone else’s finance team.

The counterparty’s clock is different from yours. In India, if an IRN is cancelled after the data has auto-populated into GSTR-1, the supplier amends GSTR-1 and the buyer’s GSTR-2B adjusts in the next cycle, generated on the 14th of the following month. The correction is instant on your side and up to a month late on theirs. Anything you build that assumes both parties see the same state at the same time is modelling a system that doesn’t exist.

Delivery failure creates obligations, not retries. Italy’s mancata consegna means the invoice is legally issued but the buyer’s channel was unreachable; the SdI parks it in their portal area, and the sender must retain the notification as proof and tell the customer. That’s a lifecycle branch whose next step is a phone call.

Payments and financing hang off the same document

The graph extends past tax. The Euro Retail Payments Board’s 2016 report defines a Request To Pay as a subset extracted from the invoice — the minimum needed to initiate payment, with a link back to the underlying invoice, and usually no tax detail or line items at all. That’s a fourth representation of the same transaction, with its own lifecycle, joined to the invoice by a reference.

Financing adds a fifth. OASIS built UBL as a general trade format aligned with ISO 20022 and designed to carry invoice financing, factoring and letters of credit. When an invoice is factored, a third party acquires a claim against a document that the tax authority may later treat as never having existed. The credit note that fixes your VAT position is also an event in somebody’s receivables book.

None of this is exotic. It’s the ordinary consequence of one document being referenced by several systems with different rules about what “cancelled” means.

What to model

Immutable documents, mutable graph. Never update a cleared invoice record. Append documents and edges. The tax authority’s view is a log, not a table — model yours the same way and reconciliation gets much easier.

Make the reference a first-class field, not a note. From 1 July 2030 the corrected invoice’s number is a legally mandated field that gets transmitted. Treat “which document does this supersede, and what changed” as structured data from the start; you’ll need both halves.

Model operations as per-country capabilities. Can this document be cancelled? For how long? Can the number be reused? Is a downstream document blocking it? Those are configuration, not code paths — India blocks cancellation with an active e-way bill, Greece removes cancel entirely on the service-provider route, Italy requires number reuse where India forbids it.

Assume corrections are recursive and reportable. A credit note against a reported invoice is itself a reported document with its own identifier and its own failure modes. If your reporting pipeline treats corrections as a special case outside the main flow, you have two pipelines and one of them is undertested.

Give the correction a reason, and keep it. Italy’s ravvedimento operoso lets businesses correct voluntarily and cut penalties substantially, but only where the correction is made before the authority opens a formal inspection — so the timestamp on your correction has money attached. Under ViDA, Article 138(1a) removes the exemption on an intra-Community supply where transmitted data is wrong, unless the failure can be duly justified. “Duly justified” is a field you either populated at the time or cannot reconstruct later.

Frequently asked questions

Can I edit an e-invoice after sending it?

No. In India the data is locked once the IRN is generated and amendment on the portal doesn’t exist. In clearance systems generally, the cleared document is the record; changes come through a new document that references it. Where a portal offers “amendment”, it usually means amending your return, not the invoice — and in India those amendments get flagged for the officer’s attention.

What’s the difference between cancelling and issuing a credit note?

Cancellation removes the invoice from existence, which is why it’s tightly time-boxed or unavailable. A credit note leaves the original standing and reverses its effect with a second document. India permits cancellation for 24 hours, then only credit notes. Greece, on the service-provider route, has no cancellation at all — credit notes substitute for it entirely.

Can I reuse the invoice number after a rejection?

It depends on the country, and the two big mandates disagree. Italy requires you to resubmit a rejected invoice with the same number and date within five days. India forbids reusing the number of a cancelled IRN. Make this configurable per jurisdiction.

Does a credit note need to be e-invoiced too?

Generally yes. In India a credit or debit note must itself be e-invoiced where the supplier is inside the mandate threshold, producing its own IRN. In Italy, TD04 credit notes and TD05 debit notes go through the SdI like any other document. Corrections are not a side channel.

Why can’t I cancel an invoice that has an e-way bill?

Because a downstream document is referencing it. India’s IRP refuses IRN cancellation while an e-way bill is active against it — the goods are in transit under that invoice, so the invoice can’t be unmade. It’s the clearest example of the general rule: your document’s available operations depend on what else in the graph points at it.

Aug

2026

What Is an E-Invoicing Europe API?

Definition

An e-invoicing Europe API is an application programming interface that enables software products to create, validate, send, receive, track, and archive electronic invoices in European markets. It connects SaaS platforms, ERP systems, billing tools, marketplaces, or compliance products with e-invoicing networks, national platforms, tax authority systems, access points, and invoice validation services.

For product, compliance, and SaaS teams, an e-invoicing Europe API is not just a billing connector. It is a regulated data exchange layer that must handle invoice formats, routing, validation, submission status, audit evidence, country-specific rules, and changing regulatory requirements.

Why It Matters for Product Teams

E-invoicing in Europe is shaped by both EU-level standards and national mandates. The EU eInvoicing Directive required public authorities to be able to receive and process electronic invoices that comply with the European standard, with a final deadline in April 2020. The European standard EN 16931 defines the semantic data model for electronic invoices and supports interoperability across EU systems. (Internal Market & SMEs)

Product teams need to understand that “Europe” is not one implementation. E-invoicing workflows can differ by country, transaction type, buyer type, tax rules, network model, platform, and reporting obligation.

An e-invoicing Europe API can support:

invoice creation and validation
EN 16931 data mapping
Peppol routing
national platform submission
B2G and B2B invoice workflows
VAT reporting preparation
invoice status tracking
rejection handling
audit trails and archiving
customer-facing compliance evidence

The product risk is not only whether the API sends an invoice. The real question is whether the system can prove what was sent, when it was sent, whether it was accepted, why it failed, and what the customer should do next.

Common Implementation Questions

What should teams define first?

Start with the invoicing workflow. Identify the country, transaction type, customer type, invoice format, routing network, authority or platform, tax requirements, validation rules, evidence needs, and failure handling.

Is an e-invoicing Europe API the same as Peppol?

No. Peppol is an important e-document exchange network used for e-invoices and other business documents, but it is not the only model in Europe. Some countries use national platforms, clearance models, reporting systems, or specific local requirements. Peppol enables electronic exchange of e-invoices, purchase orders, and other business documents, but product teams still need to map the applicable country workflow.

What is EN 16931?

EN 16931 is the European standard for electronic invoicing. It defines a common semantic data model for electronic invoices, helping systems interpret invoice content consistently across different technical environments. Public entities covered by Directive 2014/55/EU must be able to receive and process invoices that comply with the European e-invoicing standard. (European Commission)

How does VAT in the Digital Age affect e-invoicing?

The EU adopted the VAT in the Digital Age package on 11 March 2025. It is expected to expand the role of e-invoicing and digital reporting across the EU over time, especially for cross-border VAT reporting. Product teams should monitor implementation timelines and national rollout plans instead of assuming one immediate EU-wide technical model.

What is the biggest implementation risk?

The biggest risk is treating European e-invoicing as a single API integration. In practice, teams may need to support multiple formats, validation rules, routing models, local mandates, authority responses, rejection codes, archiving requirements, and customer-specific workflows.

Can a vendor claim e-invoicing compliance?

Use caution. “Fully compliant” is risky unless the vendor defines the country, transaction type, standard, platform, legal role, data scope, evidence model, and date of assessment. Stronger wording explains what the API supports: EN 16931 mapping, invoice validation, Peppol routing, national platform integration, rejection handling, status tracking, archiving, and audit trails.

Related Standards and Frameworks

E-invoicing Europe API implementations often overlap with Directive 2014/55/EU, EN 16931, Peppol BIS Billing, national e-invoicing mandates, VAT reporting rules, tax authority specifications, data archiving requirements, GDPR, ISO/IEC 27001, API security controls, and ERP integration standards.

These frameworks do not create one universal European e-invoicing workflow. They help teams structure interoperability, validation, secure transmission, evidence, archiving, and country-specific compliance operations.

Aug

2026

CRA Reporting Starts 11 September. Looking Starts in 2027

From 11 September 2026, a manufacturer that becomes aware of an actively exploited vulnerability in a product with digital elements has 24 hours to file an early warning with EU authorities. The obligation reaches backwards: it covers products already on the market, including ones shipped years ago and no longer under active development.

The obligation to have a vulnerability-handling process does not start until 11 December 2027. For fifteen months, manufacturers are legally required to report what they are not yet legally required to be looking for.

What the September obligation actually is

The Cyber Resilience Act, Regulation (EU) 2024/2847, entered into force on 10 December 2024. Its main obligations apply from 11 December 2027, which is the date most planning has been built around. Article 14 runs on a separate clock, and that clock starts first.

Two things trigger it: an actively exploited vulnerability contained in the product, and a severe incident having an impact on the product’s security. The timeline is staged — an early warning within 24 hours of becoming aware, a full notification within 72 hours, and a final report no later than 14 days after a corrective measure is available for an exploited vulnerability, or within a month for a severe incident.

“Actively exploited” is narrower than it sounds. It means evidence of real attacks against the product, not theoretical exploitability. A proof of concept or a research finding does not start the clock.

What “aware” means is the operationally difficult part. The Commission’s March 2026 draft guidance set the threshold at a reasonable degree of certainty that a vulnerability is being actively exploited or that a severe incident has compromised the product’s security. In practice that certainty often arrives only after an initial assessment, and manufacturers may hold off notifying until that assessment is complete. An ongoing investigation aimed at full forensic confirmation, however, is in principle no defence for missing the deadline.

Reports go in once, through the CRA Single Reporting Platform that ENISA is required to establish under Article 16. The notification is addressed to the CSIRT designated as coordinator where the manufacturer has its main establishment, and — absent particularly exceptional circumstances — reaches ENISA at the same time. That CSIRT then passes it to CSIRTs in every member state where the product has been made available.

The part that catches people

Article 69(3) is the provision to read before planning around December 2027. It applies Article 14 to products with digital elements that were placed on the EU market before 11 December 2027. A product shipped in 2015 and still on the market is in scope for reporting from September, regardless of what it predates.

Set that against the timing of everything else, and the shape of the gap becomes clear:

Reporting duty: 11 September 2026, covering the installed base.
Vulnerability-handling requirements in Annex I: not legally binding until 11 December 2027.
Essential cybersecurity requirements and conformity assessment: also 11 December 2027.

The practical consequence is that a manufacturer’s September exposure is determined by how quickly it learns things, not by how compliant its products are. Nothing in the Act obliges you to run threat intelligence, monitor exploitation of your own installed base, or maintain intake for third-party reports until the end of 2027. But once something reaches you through any route — a customer, a researcher, a vendor advisory, a news report — the 24-hour clock is running.

One more asymmetry worth noting: where the actively exploited vulnerability sits in an integrated component rather than the manufacturer’s own code, the obligation to notify still falls on the manufacturer of the product.

Whether the reporting channel itself is safe: an argument that has not been settled

The design requires manufacturers to hand governments detailed information about vulnerabilities that are being exploited and, by definition, may not yet be fixed. That has been contested since the legislative stage, and the disagreement is worth understanding on its own terms rather than as a settled question.

The objection during the negotiations, raised by the Electronic Frontier Foundation among others, was directed at what was then Article 11 of the proposal. EFF’s concern was that a reporting duty of this kind raises the risk of a vulnerability being “added to the offensive arsenal of government intelligence agencies.” A separate open letter from security researchers made a related argument: that dozens of agencies holding a live register of unmitigated vulnerabilities creates both a surveillance risk and an attractive target, and urged that only vulnerabilities with available mitigations be reportable.

The final regulation answers part of this through Article 16(2), which lets a manufacturer flag one of three narrow conditions in its 72-hour notification: that exploitation is confined to the member state of its own CSIRT, that wider dissemination would run against that state’s essential interests, or that dissemination poses an imminent high cybersecurity risk. Where a condition is flagged, ENISA initially receives only limited information — that a notification exists, general detail about the product, the general nature of the exploit — until the CSIRT releases the full text. A CSIRT may also delay dissemination where a coordinated vulnerability disclosure procedure is under way. On 11 December 2025 the Commission adopted a delegated act specifying the terms and conditions for applying those cybersecurity-related grounds.

Two points survive that machinery. The first is structural: flagging sensitivity limits who sees the content, but nothing pauses the filing itself. The 24-hour, 72-hour and final-report windows all run from awareness, and the decision to hold back dissemination belongs to the receiving CSIRT, not to the manufacturer.

The second came from the Cybersecurity Coalition and the Hacking Policy Council in their comments on the draft delegated act. Their argument is that the act addresses risk in sharing between CSIRTs but not in the leg before it — between manufacturer and CSIRT. They point to a specific case: a CSIRT may delay reporting via the Single Reporting Platform where the platform has itself been compromised, yet manufacturers are still required to submit through that same platform, and nothing requires ENISA to tell them about such an incident. On their reading, “manufacturers could unknowingly report vulnerabilities through a compromised or insecure channel.”

Reading the delegated act does not dissolve the disagreement. The Commission’s position is that Article 16 and the delegated act provide proportionate safeguards; the industry groups’ position is that the safeguards sit one link further down the chain than the risk. Both readings are available on the text. If your reporting process depends on how this resolves — because you ship security products, or operate in a sector where an unpatched-vulnerability disclosure carries second-order risk — this is a question for security counsel, not for a checklist.

Scope guidance arrived seven weeks before the deadline

Article 26 obliges the Commission to publish guidance helping economic operators apply the CRA, with particular attention to smaller businesses. It approved that guidance on 27 July 2026, document reference C(2026) 5252 — roughly 80 pages, with worked examples and flowcharts, following a consultation draft issued on 3 March 2026. It is not legally binding, but it is the reading that market surveillance authorities and notified bodies will work from.

Most of it addresses scope, which is where the genuine uncertainty has been. For free and open-source software, the guidance confirms that software published without being placed on the market generally falls outside the CRA. Where the publisher is a legal person meeting the definition of an open-source software steward under Article 3(14), only the obligations in Article 24 apply, with steward reporting duties calibrated to the support actually provided.

The line the guidance draws around commercial activity is the operative one. Selling the software, offering a paid enterprise edition, monetising services through it, requiring personal data beyond security or interoperability purposes, or making donations effectively mandatory for access or essential updates all bring a project into scope. Voluntary donations, sponsorships, public funding, and paid consulting, training or support do not, provided the software itself stays freely available. A contributor submitting patches or fixing bugs generally carries no CRA responsibility; obligations attach to whoever controls releases, roadmap and governance. An organisation publishing both a free community edition and a paid enterprise edition is steward of the first and manufacturer of the second — two regimes, same codebase.

If you are not established in the EU

Article 14 sets a sequence for determining which CSIRT receives the notification when the manufacturer has no main establishment in the Union: the authorised representative, then the importer, then the distributor, then the location of users. Working out that answer at the moment a 24-hour clock starts is the wrong time to do it. It is a question to settle in advance and write into the incident procedure, alongside who inside the organisation is authorised to decide that the awareness threshold has been met.

Frequently asked questions

Do I need a full vulnerability-handling process by 11 September 2026?

Not as a legal matter. The vulnerability-handling requirements in Annex I are not binding until 11 December 2027. From September 2026 the only obligation is to report actively exploited vulnerabilities and severe incidents. In practice the two are hard to separate — you cannot report reliably what no process is built to detect — but the deadlines are distinct and require different preparation.

Does this apply to products I shipped before the CRA existed?

Yes. Article 69(3) extends the Article 14 reporting obligations to in-scope products placed on the EU market before 11 December 2027. Age of the product is not a defence, and the practical work is inventorying what you still have on the market.

Can I delay reporting while I investigate?

Only up to a point. The clock starts at a reasonable degree of certainty, and the Commission’s guidance accepts that certainty may require an initial assessment. Continuing to investigate toward full forensic confirmation is in principle not a defence for missing the window. Separately, flagging sensitivity under Article 16(2) limits who sees the content — it does not pause the filing.

Does my open-source project fall under the CRA?

It depends on whether it is placed on the market in the course of a commercial activity. Free availability with voluntary donations, sponsorship or public funding generally stays outside scope; paid editions, monetised services, or donations that are effectively required for access bring it in. The Commission’s July 2026 guidance works through the borderline cases in detail and is the right document to check a specific project against.

What happens if I miss a deadline?

Enforcement sits with national market surveillance authorities, and the CRA’s enforcement model runs primarily through corrective measures rather than immediate financial penalties. That is a weaker deterrent than the AI Act’s or the GDPR’s, and it is also a reason not to treat September as soft: a corrective-measures process aimed at your product line is disruptive in ways a fine is not.

Aug

2026

A TikToker tested a tax system with a fake condom invoice: it has no questions. And only a pharmacist saved the Polish PM’s office — and it’s clean tax record

KSeF Scam Invoices: The PM’s Office Didn’t Buy Condoms

In February 2026, a man walked into a pharmacy in a Polish shopping centre, bought a packet of condoms, and asked for the VAT invoice to be made out to the Chancellery of the Prime Minister. He gave the Chancellery’s tax number. He had no connection to it — no contract, no order, no relationship of any kind. Under rules that had taken effect two weeks earlier, none of that mattered. Had the pharmacist completed the request, the invoice would have been validated by the state and deposited in the Chancellery’s own records, and nobody working there could have refused it.

That is not a loophole. Poland’s Krajowy System e-Faktur routes every structured invoice to whoever’s tax identification number appears on it, and the workflow contains no step at which the recipient accepts or declines. Documents sent this way on purpose have earned a name in Polish practice: faktury scamowe, KSeF scam invoices. France switches on a comparable regime on 1 September 2026.

How a request at a pharmacy counter reaches a government ledger

KSeF became compulsory in phases — 1 February 2026 for taxpayers whose 2024 gross sales exceeded PLN 200 million, 1 April 2026 for the remaining VAT-registered businesses, and 1 January 2027 for micro-entrepreneurs. The production release, KSeF 2.0, went live with the first wave. Volume followed immediately: the Ministry of Finance reported over 87 million invoices from more than 345,000 entities in the first two months of mandatory operation.

In a clearance model, an invoice is not sent to a business. It is submitted to a central government platform, validated there, and then routed to a recipient identified only by the NIP written on the document. Three consequences follow, and none of them existed under invoicing by PDF and email:

Delivery is automatic and unconditional. The document lands in the recipient’s repository whether or not any transaction took place.
There is no accept-or-reject step. Nothing lets a recipient refuse a document before it is recorded against their tax number.
Corrective notes are gone. Errors, including a wrong NIP, are fixed only by the issuer raising a corrective invoice to zero. The recipient cannot correct a document issued against them.

A recipient can hide an unwanted document from their own view of the system. That is a display setting — reversible, invisible to the issuer, and it changes nothing about the document’s existence.

The video, and what happened to the man who filmed it

The pharmacy visit was staged. Tomasz Sidorczuk, a community activist from Bielsko-Biała better known locally for campaigning on cycling infrastructure, filmed the whole thing and posted it to TikTok, where it passed a million views inside a day and reached roughly 4.5 million by the end of the month.

Two facts about the incident matter more than the stunt. The invoice was never generated — the pharmacist declined to issue it. And the tax at stake was 89 groszy, under a quarter of a euro.

On 26 February 2026, Sidorczuk was questioned at the Silesian Customs and Tax Office in Katowice and charged with incitement to issue an unreliable invoice. He denies it and has said that if the case reaches court he intends to fight for acquittal; on the most recent reporting, charges have been presented but no indictment or verdict has followed.

His argument was never that the system can be broken into. It was that verification has quietly become the recipient’s job, at a volume nobody sized for. In a business processing thousands of documents a month, he said, it is bardzo łatwo przeoczyć fakturę wystawioną omyłkowo lub bez podstawy — “very easy to miss an invoice issued by mistake or without basis.”

One side says nothing is broken. The other is not arguing about the same thing.

Poland’s Ministry of Finance responded that the circulating material nie wskazuje na istnienie luki w KSeF — “does not indicate the existence of a gap in KSeF” — and gives no grounds to assert a risk connected with how the system functions. Public broadcaster Radio Kraków was blunter, treating the video as a stunt inflated beyond its worth, on the grounds that możliwość wystawienia faktury na dowolny NIP istniała od zawsze — “the ability to issue an invoice to any tax ID has always existed.”

Both statements are true, and both answer a question nobody asked. Writing someone else’s tax number on an invoice has never been hard. What changed is what happens afterwards.

Practitioners handling the inbound side describe the problem in operational terms rather than architectural ones. As Joanna Łuksza put it, wystawienie scamowej faktury nie zawsze jest proste do wykrycia — “issuing a scam invoice is not always simple to detect” — typically a document from a company the recipient has never dealt with, or for a transaction that never happened. Poland’s Ombudsman has raised a separate concern from a different direction: that the breadth of data gathered in KSeF may sit awkwardly with statutory protection of business secrets and with EU data-protection standards.

The disagreement dissolves once you separate issuing from delivery. Before KSeF, a fabricated invoice had to reach you — by post, by email, through a channel you controlled and could ignore. Under a clearance model it is validated by the state and placed directly into your tax records, with no point at which you can say no. The defence is right that issuing was always possible. It is answering an objection about delivery.

What Article 62 of the Fiscal Penal Code actually says

Coverage of the charges reported three different maximum penalties: three years, a floor of one year, and — attributed to a television journalist — up to eight. The statute settles it. Sidorczuk was charged under Article 18 § 2 of the Criminal Code, read with Article 20 §§ 1 and 2 and Article 62 § 2 of the Fiscal Penal Code of 10 September 1999 (consolidated text, Dz.U. 2025 poz. 633).

Article 62 § 2 provides for a fine of up to 720 daily rates, or imprisonment for a term not shorter than one year, or both. One year is the statutory floor, not the ceiling — and neither three years nor eight appears anywhere in the provision.

What sits immediately after it went unmentioned in the coverage entirely:

§ 2a covers the same conduct where the tax arising from the invoice is of small value. It drops the one-year minimum, leaving a fine of up to 720 daily rates, or imprisonment, or both.
§ 5 provides that in a case of lesser gravity, conduct under §§ 1–4 is punishable by a fine for a fiscal misdemeanour rather than as a fiscal offence.

The tax at issue was 89 groszy. Whether either provision applies here, and how incitement works where the invoice was never issued at all, are questions for the court and for a Polish fiscal-penal specialist — not conclusions to be drawn from reading a statute at a distance. But the gap between the reported exposure and the range the code sets out is wide enough that anyone working from the news figures is working from the wrong numbers.

What you can do when a scam invoice lands

KSeF 2.0 includes an abuse-reporting function: a business can flag a document it believes fraudulent for examination by the National Revenue Administration. Three limits are worth knowing before building a process around it.

Reports go one document at a time. There is no bulk submission.
The function is technical in character — the tax administration does not report back on what it finds.
You can track the status of your report. That is the extent of the visibility.

Where a wrong NIP is a genuine mistake rather than an attempt at fraud, the route is different and faster: contact the issuer, ask for a corrective invoice to zero, then a correctly addressed one. The distinction matters, because an abuse report aimed at what turns out to be a typo burns the only channel you have.

The failure mode worth designing against is mundane. Not a sophisticated attack — an invoice for a service nobody ordered, from a company nobody has dealt with, priced low enough and dated tightly enough to clear an approval queue on a busy week. The warning signs practitioners flag are unremarkable, which is exactly why they can be systematised: language errors in the service description, no reachable contact for the issuer, unusually short payment terms.

France goes live on 1 September 2026

France’s first obligation applies to every business regardless of size — the ability to receive compliant electronic invoices from 1 September 2026. Large and mid-sized enterprises must also issue from that date; smaller businesses follow on 1 September 2027. Invoices move through accredited platforms rather than one central state portal, so the architecture is decentralised in a way Poland’s is not. The property that produced the KSeF argument is the one both models share: a structured invoice addressed to your identifier arrives through a channel you do not control, and arrival is not consent.

Poland suspended financial penalties through the end of 2026, with enforcement beginning 1 January 2027. That has an underappreciated consequence for anyone watching from another jurisdiction — the incident rate visible today is the rate under conditions where mistakes are cheap. Belgium, live since 1 January 2026, moved to progressive penalties on 1 April 2026 once its tolerance period ended.

Two questions are worth settling before a mandate goes live rather than after. Who reviews inbound structured invoices, and does that person have authority to stop payment on a document already recorded against your tax number? And what internal signal separates a wrong-identifier error from an attempt at fraud, given that the remedies differ and only one of them is quick?

Frequently asked questions

Can I reject an invoice sent to my tax ID in KSeF?

No. Structured invoices are assigned to the buyer automatically on the basis of the NIP, with no accept-or-reject step, regardless of whether the transaction took place. You can hide the document in your own view of the system — reversible, and invisible to the issuer — but the document itself remains. Removal requires the issuer to file a corrective invoice to zero.

What should I do if a fraudulent invoice appears in my KSeF account?

Use the abuse-reporting function in KSeF 2.0 to flag it for the National Revenue Administration, one document at a time. If it looks like a simple error rather than fraud — a mistyped NIP, most often — contact the issuer first and ask for a correction to zero, which is faster. Pay nothing you cannot trace to a real order.

Does an invoice in my KSeF account mean I owe the money?

An invoice is a document, not proof of a debt. The obligation comes from the underlying transaction. The real risk is operational rather than legal: a document sitting in your records can be paid by mistake in a busy approval queue, and it still has to be handled correctly for VAT and reporting purposes. For a specific document and a specific exposure, take it to a tax adviser rather than a checklist.

Will France’s system work the same way as KSeF?

Not identically. France routes invoices through accredited platforms rather than a single central state portal. What carries across is that structured invoices addressed to your identifier arrive automatically through a channel you do not control — which is what makes the Polish experience worth reading before 1 September 2026.

When do penalties start in Poland?

Financial penalties for KSeF breaches are suspended through the end of 2026, with enforcement beginning 1 January 2027. That makes the rest of 2026 the window for fixing processes while errors are still cheap.