Peppol

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.

E-invoicing is an exchange: a supplier sends a structured document to a buyer so the buyer can book it and pay it. E-reporting is a transmission: a taxpayer sends fiscal data to a tax authority so the authority can cross-check it. Different recipient, different payload, different deadline, different consequence when it fails. They are two flows that happen to be derived from the same source document.

They get conflated because one service provider usually sells both, and because in some countries the same API call does both. But they are independent axes. Sweden, Finland and Norway have mandatory invoice exchange over Peppol with no tax authority controls involved at all — mandatory e-invoicing, zero e-reporting. Meanwhile India’s mandate is routinely called “e-invoicing” and its output is frequently an emailed PDF. Getting the distinction right determines what you build.

The two flows, side by side

Under ViDA — Council Directive (EU) 2025/516, the adopted text — the two flows are defined in different chapters of the VAT Directive, and every parameter differs.

• Recipient. E-invoicing: the buyer. E-reporting: the tax authority that issued the VAT number used for the transaction (Article 262(2)).
• Payload. E-invoicing: the invoice, complying with EN 16931 by default (Article 218(3)). E-reporting: ten data points (Article 264).
• Deadline. E-invoicing: within ten days of the chargeable event (Article 222). E-reporting: at the moment the invoice is issued or should have been (Article 263(1)).
• Who acts. E-invoicing: the supplier. E-reporting: the supplier and the customer, within five days of receiving the invoice — unless the member state waives it (Article 262(4)).
• Harmonisation. E-reporting for cross-border is identical in every member state, with no possibility of requesting additional data. Domestic e-reporting is whatever each member state decides (Article 271b(4)).

One document, two consumers, and the consumers want different things. There is also a third: the ERPB’s 2016 working group report defines a Request To Pay as a subset extracted from the invoice, carrying the minimum needed to initiate payment plus a link back to the underlying invoice — and it notes that this message usually contains no tax details and no line items at all. Three parties, three data sets, one source document.

The buyer gets the invoice. The authority gets ten fields.

The concrete version comes straight from Article 264 as replaced by ViDA. From 1 July 2030, for an intra-Community supply, what gets transmitted to the tax authority is Article 226 points 1 to 4, 6, 7, 8, 11, 16 and 17, plus 11a where applicable. Ten data points.

Not on that list: point 5, the full name and address of both parties. The authority resolves identity from the VAT numbers via VIES; it doesn’t need the street. Also not on the list, for the supplier: the VAT rate and the VAT amount — an intra-Community supply is exempt, so there is no rate to report. The customer’s report of the same transaction does carry the rate and the amount, because in the customer’s country the transaction is taxable. Supplier reports ten fields, customer reports twelve, same transaction.

Now compare that with what the buyer needs from the same document: line-level descriptions and quantities, the purchase order reference, the delivery address, payment terms, the supplier’s bank details, an accounting cost code for coding it to the right centre. Almost none of that is reportable. It is the entire reason the invoice exists.

The two data sets overlap. Neither contains the other.

Different failure modes, and this is where it gets expensive

If e-invoicing fails, the buyer doesn’t get an invoice, and eventually somebody calls somebody. It’s a commercial problem with a commercial remedy.

If e-reporting fails, the tax consequences are structural. ViDA amends Article 138(1a) so that the exemption for an intra-Community supply does not apply where the supplier has not met the Articles 262 and 263 transmission obligation, or where the data transmitted doesn’t contain the correct information required by Article 264 — unless the supplier can duly justify the failure to the competent authorities. Miss the report, and a zero-rated cross-border supply becomes a taxable one.

On the other side, ViDA adds a subparagraph to Article 168 letting member states provide that a customer may deduct or reclaim VAT only where it holds an electronic invoice issued in accordance with Article 218(3). Note the scope: that option attaches to transactions subject to the domestic reporting requirements of Article 271a(1). It is an option, not an obligation, and it is national.

So the same missing message costs a late payment on one plane and an exemption on the other. Systems that treat the report as a downstream side effect of a successful invoice send are mis-modelling the risk — the report has the sharper teeth.

Where the tax authority actually sits: the corner models

The ERPB’s 2016 report categorises e-invoicing solutions by the number of intermediary platforms in the presentation flow: Supplier Direct, where the supplier runs the whole lifecycle and the payer comes to the supplier’s portal; Buyer Direct, where suppliers post into a platform on the buyer’s side; the three-corner network, where one service provider sits between both parties; and the four-corner network, where each party has its own provider and flows are routed between the two platforms.

The tax authority is not a corner in any of them. That isn’t an oversight in 2016 — it’s the definition. E-invoicing was a two-party exchange, and intermediaries were counted by how many sat in the presentation path.

When tax authorities arrived, the industry had to invent a fifth corner, and the name it settled on gives the game away: DCTCE, Decentralized CTC and Exchange. Two functions, named separately, in one acronym. France’s model is drawn as a Y for the same reason — two branches for exchange (issuing and receiving through approved platforms) and a third branch for e-reporting, submitting invoice, transaction and payment data to the tax authority through the public portal.

And here the vendor pages that inspired this article contradict each other outright. Some describe the five-corner model as one where invoices must first pass through a government platform to be validated and registered before continuing to the buyer. Others describe the same model as one where a copy is sent to the tax authority before or immediately after delivery, while the invoice reaches the buyer through their own access point. Those are different architectures, and the difference is load-bearing: one commentary notes the decentralised version is gaining ground precisely because pre-clearance submission undermines established billing processes and makes the authority’s portal a single point of failure.

Both descriptions are accurate — about different systems. Clearance (the authority is in the exchange path, and the invoice isn’t valid until it comes back) and near-real-time reporting (the authority gets a copy on a separate leg) are distinct designs. ViDA mandates the second for intra-EU: transmit at the time of issue. It does not put the authority between supplier and buyer.

The mandates called “e-invoicing” that are really e-reporting

Two of the clearest examples come from implementation guides rather than marketing pages.

India. Sigitek’s SAP e-invoicing solution documentation describes the flow: every SAP billing document is pushed as JSON to the Invoice Registration Portal via an authorised GSP; the IRP checks the IRN against the GST system’s central registry for uniqueness, signs the invoice data, adds a QR code and returns the digitally signed JSON with the IRN to SAP; the IRP then shares the signed data with the GST system and the E-Way Bill system, and GSTR-1 is auto-populated on a T+1 basis. The buyer appears nowhere in that flow. The last step in the vendor’s own architecture diagram is “Print or Email Invoice”. The structured data goes to the government; the buyer gets a printout with a QR code on it.

Greece. SAP’s August 2024 implementation guide describes the same shape. Invoices route through a certified service provider to myDATA, which returns a MARK, a UID and an authentication code — and the requirement is then that the QR code, MARK, UID, authentication code and the provider’s name are printed on the invoice. Real-time submission, rendered as ink.

In both cases the mandate is an e-reporting mandate wearing an e-invoicing label. The tell is simple: ask who receives the structured data. If the answer is “the tax authority, and the buyer gets a PDF”, that’s e-reporting. The exchange plane hasn’t been digitised at all.

The one place they genuinely couple

The flows are separable, but not independent — and the dependency runs one way.

The new Article 217, applying from 1 July 2030, defines an electronic invoice as one issued, transmitted and received in a structured electronic format allowing automated processing — “at least in relation to the data referred to in Articles 262 and 271b”. Articles 262 and 271b are the reporting articles. The reporting requirement is what sets the structured minimum for the invoice. ViDA’s recital 11 says it plainly: the invoice should contain, in structured format, all the data that has to be transmitted to the authority, so that transmission can be automated from it.

That single qualifier explains two things people find confusing. It’s why hybrid formats like ZUGFeRD and Factur-X survive — the reportable data is in the XML, so the PDF layer is legally irrelevant. And it’s why e-reporting is driving e-invoicing rather than the other way round: the tax authority’s data needs define the floor of the format your buyer receives. Not the buyer’s needs. Not yours.

Meanwhile the old periodic report dies. ViDA deletes Articles 265 to 271 from 1 July 2030 — recapitulative statements disappear, replaced by transaction-by-transaction transmission. That’s the actual reform: not new reporting, but the same reporting moved from monthly batch to per-transaction, which is only affordable if it’s derived automatically from a structured invoice.

How to tell which one you’re being sold

Four questions cut through most vendor pages:

• Who receives the structured data? Buyer, authority, or both. “Both” is a five-corner or DCTCE architecture. “Authority only” is e-reporting with an e-invoicing label.
• Is the authority in the path or beside it? Clearance means the invoice isn’t valid until the platform returns an identifier. Reporting means a copy travels separately and the invoice is valid regardless.
• What happens if the report fails but the invoice arrives? If the answer is “nothing”, the flows are decoupled. If it’s “the exemption goes”, you’re inside Article 138(1a).
• Which data set is being mapped? Ten header fields is a reporting integration. Around 170 EN 16931 business terms is an invoicing integration. They’re different projects with different costs.

Frequently asked questions

Is e-reporting just e-invoicing sent to the government?

No. Under ViDA it’s a defined subset — Article 226 points 1 to 4, 6, 7, 8, 11, 16 and 17 — transmitted per transaction on its own leg, without the parties’ names and addresses. In some national systems a full invoice copy does go to the authority, which is why the misconception is durable, but the EU cross-border design transmits data, not documents.

Can you have e-invoicing without e-reporting?

Yes, and several countries do. Invoice exchange over Peppol is mandatory in Sweden, Finland and Norway, and it isn’t a CTC model because there are no tax authority controls involved. Mandatory structured exchange, no fiscal transmission.

Can you have e-reporting without e-invoicing?

Yes — that’s what India and Greece currently demonstrate at the buyer’s end, where the structured data reaches the tax authority and the counterparty receives a printed or emailed document carrying a QR code.

Do both the supplier and the buyer have to report under ViDA?

By default yes: the supplier at the time of issue, the customer within five days of receiving the invoice. But Article 262(4) lets member states drop the customer-side obligation, and ViDA’s recitals explain why — the customer’s report exists to cross-check the supplier’s, so a member state that already has assurance the supplier will report can waive it.

Does ViDA make my country’s clearance system illegal?

No. Member states with a domestic real-time transaction-based reporting obligation in place on 1 January 2024 have until 1 January 2035 to align those domestic systems, and Article 273 lets existing general reporting obligations continue until a compliant system replaces them. The convergence is real but slow, and it applies to domestic flows — the intra-EU leg is harmonised from 2030.