Peppol and e-reporting combined: one integration architecture for e-invoicing, clearance and real-time reporting

Anyone integrating e-invoicing across several countries no longer works with a single exchange model. Peppol and e-reporting are converging: the same invoice that travels from supplier to buyer through the Peppol architecture now also delivers data to the tax authority in a growing number of countries. Sometimes this happens before the buyer receives the invoice (clearance), sometimes in parallel or shortly afterwards (e-reporting). For integrators, the core question is how one integration architecture can serve all three flows without building a new connection for every country. This article compares the models, gives a country overview and closes with a concrete checklist for your integration.

The essentials for integrators

• Treat exchange, clearance and reporting as three separate flows that share one common data model.
• Define routing per country and per recipient as configuration, not as custom code per connection.
• Make one invoice status model authoritative: in a clearance country, an invoice is only legally valid once the government platform has accepted it.
• Plan against fixed dates: France since 1 September 2026, Spain from 6 October 2027, EU-wide digital reporting for cross-border B2B trade from 1 July 2030.

Why Peppol and e-reporting have become one design question

With Directive (EU) 2025/516, the ViDA package, the e-invoice becomes the basis for digital VAT reporting. For cross-border B2B transactions within the EU, the new digital reporting requirements apply from 1 July 2030. Member States that already have a domestic real-time reporting obligation must align it with the EU model and its standards by 1 January 2035. National systems will therefore converge over time. Until then, each country chooses its own route.

Those routes differ considerably. Belgium has used the Peppol architecture for mandatory B2B exchange since January 2026 and is preparing e-reporting from 2028. France routes invoices and tax data through Plateformes Agréées. Poland and Italy operate a clearance model in which a central government platform receives and validates every invoice. Spain combines private exchange with a mandatory copy and status reporting to the tax authority.

For an integrator this means one invoice, several destinations, several status sources and several moments at which a government sees the transaction. Building a separate connection per country leaves you maintaining a collection of islands within a few years. A well-designed CTC e-invoicing architecture prevents that.

Three models side by side: exchange, clearance and e-reporting

The Peppol architecture: exchange between four parties

In the Peppol architecture (often called 4-corner), the supplier sends its invoice through its own Peppol Service Provider to the buyer’s service provider, which delivers the invoice. The sending access point uses the SML and the recipient’s SMP to look up the address and the document types that recipient supports. The content format is Peppol BIS Billing 3.0, based on the European standard EN 16931. The tax authority is not part of the message flow in this model. The invoice is valid once delivered; the sender receives a transport acknowledgement and, where used, an Invoice Response from the buyer.

The clearance model: the government validates before the buyer

In a clearance model, the supplier first sends the invoice to a central government platform. That platform validates the invoice, assigns its own identifier and then makes the invoice available to the buyer. Poland’s KSeF and Italy’s Sistema di Interscambio (SdI) follow this principle. This has three consequences for your integration. The government becomes a synchronous dependency in the invoicing process. A rejection by the platform means that, legally, no invoice has been issued. And the identifier assigned by the platform must flow back to the source system, because follow-up processes need it.

E-reporting and the 5-corner model: the tax authority as fifth party

With e-reporting, the exchange stays between the trading parties. In addition, a data extract goes to the tax authority, usually via the supplier’s service provider or platform and sometimes also via the buyer’s. When that reporting runs over the same infrastructure as the invoice, it is called a 5-corner model: the tax authority is the fifth party next to the four parties of the Peppol architecture. Variants differ by country in three respects: who reports (supplier, buyer or both), which data (a selection of invoice fields, the full invoice or payment data as well) and how fast (near real-time, within a few days or periodically).

What the differences mean for your design

Country overview: Peppol and e-reporting by country

The overview below reflects the position on 8 October 2026, based on the primary sources listed at the end of this article. Legislation still in preparation may change during the parliamentary process.

Several countries deserve a closer look. In Belgium, both supplier and buyer will report, which means the purchasing side of your integration also gets a reporting flow; for the current position, see our article on Belgium e-reporting via 5-corner Peppol. In France, the reporting obligation also applies to companies without a French establishment that owe French VAT; see e-reporting France without a French establishment. The French directory (annuaire) records, for each company, the chosen Plateforme Agréée and its invoicing addresses, which your routing layer can use as a source. In Germany, the transmission route for the Meldesystem is still open; background is in Germany e-reporting 2030 with a pilot in 2029. For Luxembourg, Peppol Luxembourg designated as the network describes the phasing. In Poland, penalties have been postponed but the obligation itself has not; see the KSeF mandate 2027. For Spain, Orden HAC/1028/2026 fixes the dates and the role of the public solution. For the Netherlands, ViDA Netherlands sets out the choices in the Dutch policy letter.

One e-invoicing architecture for Peppol and e-reporting: the building blocks

The countries differ, but the components you need are the same everywhere. The difference lies in configuration, not in fundamentally different software. The seven building blocks below together form an e-invoicing architecture that can handle exchange, clearance and reporting.

1. A canonical data model based on EN 16931

First map invoices from ERP and accounting systems into a single internal model that follows the semantics of EN 16931. From that model, generate the outbound format per channel: Peppol BIS Billing 3.0, XRechnung, Factur-X, the KSeF schema, FatturaPA or the Spanish variants. Country-specific fields, such as a Polish KSeF number or French reporting categories, get their own place in the model rather than in the mapping. A new format version, such as XRechnung 4.0, then only affects the outbound transformation.

2. A routing layer per country and per recipient

Routing decides which channel applies to each invoice: Peppol, a clearance platform, a Plateforme Agréée or another route. The decision rules depend on where supplier and buyer are established, the type of transaction and the recipient’s registration. Use the Peppol Directory and SMP lookups, and the annuaire in France, as data sources. Store the rules as configuration with effective dates, so that a new phase of a mandate becomes a table change.

3. Layered validation

Validate before sending at three levels: syntax (XML schema), the EN 16931 rules and the country-specific rules (CIUS and national extensions). In a clearance country, a rejection by the platform is costly, because the invoice then does not exist. Running the same validation artefacts locally catches most errors before the platform sees them.

4. One status model across all channels

Peppol transport acknowledgements, Invoice Responses, KSeF confirmations, SdI notifications, French lifecycle statuses and Spanish acceptance, rejection and payment messages each have their own vocabulary. Translate them into one internal status model with a limited set of states, such as submitted, accepted by government, delivered, rejected, paid and reported. Feed that status back to the source system so that accounts receivable works from a single source.

5. A separate pipeline for real-time reporting

Treat reporting as a flow of its own, even when it runs through the same service provider. Reporting can succeed while delivery fails, and vice versa. In Belgium and France the buyer reports as well, and in Spain the buyer reports rejections and payments. Real-time reporting therefore also touches your purchasing process and payment handling. Design the pipeline so that you can configure per country which fields, which moment and which party reports.

6. Archiving and evidence

Store, per invoice, the message sent, the government identifier assigned, all status messages and the reporting acknowledgements as a single record. Statutory retention periods differ by country; your archive must therefore support a retention period per country and keep the original XML unaltered.

7. Idempotency and error handling

Give every invoice a unique, stable key so that a repeated submission never results in a duplicate invoice or duplicate report. Distinguish temporary errors (time-out, platform unavailable), which are retried automatically, from content errors, which go to a work queue. For clearance countries, add a contingency procedure for outages of the government platform, in line with that country’s rules.

Practical guide: what Peppol and e-reporting mean for your integration

Use the steps below as the sequence for an integration project that serves several countries.

1. Map countries and roles. Record per country whether your client is supplier, buyer or both, whether there is a fixed establishment and which thresholds apply (turnover, company size). This determines which obligations and dates apply.
2. Put the mandate dates in your plan. At a minimum: France 1 September 2027 (SMEs and micro-enterprises, and reporting by buyers), Germany 1 January 2027 and 1 January 2028, Poland 1 January 2027, Spain 6 October 2027 and 6 October 2028, Luxembourg 2028 and 1 January 2029, Belgium e-reporting 2028, EU reporting 1 July 2030, Netherlands 1 July 2030 and 1 July 2031.
3. Design the canonical model first. Test it against EN 16931 and against the field lists of the clearance and reporting countries in your scope before you build a single mapping.
4. Choose the channel and partner per country. Decide whether you connect directly to KSeF, the SdI or the AEAT solution, or route through a Peppol Service Provider or Plateforme Agréée. Check whether that party also handles the reporting flow and the status messages.
5. Build validation and the status model before the first go-live. Include the official validation artefacts in your test pipeline and define the status model, including rejection and payment.
6. Set up the purchasing side. For Belgium, France and Spain, the receiving side must also report or return status. Link receipt, approval and payment to those messages.
7. Test failure scenarios explicitly. Simulate rejection by a clearance platform, an unreachable recipient, a duplicate submission and a government outage. Verify that no scenario results in a duplicate invoice.
8. Manage changes centrally. Assign an owner for regulatory updates and format versions, and document how a change reaches production through configuration.

For software vendors, Peppol Service Providers and business owners

Software vendors are well advised to build the canonical model and the status model into the product itself, so that customers do not need country-specific custom work. Peppol Service Providers take on a role in reporting to the tax authority in 5-corner variants, which requires demonstrable reliability for both delivery and reporting. Business owners do not need to build the architecture themselves, but they do need to know in which countries they become subject to reporting as supplier or buyer, and to ask their provider how this is covered.

Sources

1. Council Directive (EU) 2025/516 of 11 March 2025 (ViDA), EUR-Lex
2. European Commission, VAT in the Digital Age (ViDA)
3. Government of the Netherlands, Cabinet chooses to introduce e-invoicing and reporting for businesses (11 September 2026, Dutch)
4. Belgian federal government, Introduction of the obligation to report invoice data electronically (18 July 2026, Dutch)
5. FPS Finance, e-invoice.belgium.be: General questions about e-reporting
6. Chamber of Deputies of Luxembourg, bill 8815 (French)
7. Chamber of Deputies of Luxembourg, summary of the bills on VAT and mandatory e-invoicing
8. French Ministry of the Economy, Tout savoir sur la facturation électronique pour les entreprises (French)
9. impots.gouv.fr, E-reporting for foreign companies without a permanent establishment in France (French)
10. impots.gouv.fr, Facturation électronique et plateformes agréées (French)
11. French Ministry of the Economy, What is the e-invoicing directory? (French)
12. German Federal Ministry of Finance, FAQ on mandatory e-invoicing (German)
13. German Bundestag, hib 590/2024: Federal Government reply on the reporting system (German)
14. Polish Ministry of Finance, National e-Invoice System: implementation plan (Polish)
15. BOE, Orden HAC/1028/2026 of 2 October 2026 (public e-invoicing solution, Spanish)
16. Spanish Tax Agency, Public E-invoicing Solution (SPFE) (Spanish)
17. Spanish Tax Agency, Information note: extension of the deadline for invoicing software (Spanish)
18. Italian Revenue Agency, La fattura elettronica (Italian)

Which Peppol Service Providers and integration platforms support Peppol and e-reporting for the countries in your scope? In the Peppol.now comparison tool you can compare providers by country coverage, channels and integration options, so you find a suitable party for every route in your architecture.