Poland, Italy and France: What We Can Learn from Different Models

Service-organisation comparison, not foreign tax instructions or a live-service audit. The cited pages were accessed for this series on 22 September 2026. Poland’s page carries a 1 February 2026 update; AIFE attributes the French redesign to the October 2024 announcement and 2025 legislation. The Italian guide has no update date established here. These are official descriptions, not user-tested availability of every function on the publication date.

A foreign e-invoicing system is not an argument until we identify what it actually does. A central invoice exchange, a free application and a regulated network of platforms can all be described as national digitalisation. They place different obligations on a business and create different operational dependencies.

Poland, Italy and France are useful comparisons because they resist a simple public-versus-private classification. The relevant distinction is not whether private software exists. It is whether a business can satisfy the basic obligation through a public-facing service, which functions require an intermediary, and how commercial invoice delivery connects to tax reporting.

My preference is a direct public baseline with optional commercial services. These examples are tests of both that preference and the provider-led alternative, not proof of either model’s efficiency. Documented functions are known; comparable Slovak costs and operating outcomes are not.

Poland: a public application is a concrete access choice

Poland’s Ministry of Finance describes the KSeF taxpayer application as a tool for issuing, receiving and viewing electronic invoices and managing permissions.13 Its official tools page, updated on 1 February 2026, also identifies free tools for checking processing status and downloading an official acknowledgement, known as UPO KSeF.13

The same page describes integration of the public e-mikrofirma application with KSeF, including invoice issuance, receipt and transfer into VAT records without manual transcription.13 These are specific functions, not a general promise that every accounting task is free.

For the Slovak debate, the important fact is the existence of a publicly provided route to those functions. Commercial accounting software can still be useful. Businesses with complex processes may value integration, delegated workflows and specialist support. A public application does not make those services redundant.

Equally, the application page is not a complete legal guide to the Polish mandate. It does not justify collapsing all taxpayer categories, transition provisions or exceptional transactions into one date. This comparison concerns access architecture. A company implementing KSeF must separately establish its own obligations under the applicable rules.

Italy: distinguish the exchange from the tools around it

Italy’s Revenue Agency documents the public “Fatture e Corrispettivi” portal and its invoicing services. These include preparing and transmitting electronic invoices, registering the telematic address for receipt, and consulting invoices and receipts associated with the Sistema di Interscambio, or SdI.6

The guide also describes a free electronic preservation service requiring the relevant agreement.6 The agency’s separate registration and preservation FAQ confirms voluntary enrolment in its free preservation service and distinguishes the responsibilities associated with it.14 That detail matters: “free public service” does not mean “no conditions, no activation and no operational choices.” Businesses still need to understand the functions they have enabled and the evidence they retain.

The portal page separately identifies services for transmitting receipts data and periodic VAT settlement communications.6 Their presence under the same portal does not make them identical to sending an invoice to a customer. A shared login screen is not a shared legal purpose.

Italy therefore offers a practical comparison for a public baseline: state-provided tools can sit around a national exchange while businesses continue to use commercial systems. It would be a mistake, however, to describe SdI as simply an Italian Peppol access point. The comparison here concerns public access and allocation of functions, not protocol equivalence.

It would also be premature to infer a Slovak cost estimate from the availability of Italian tools. The size of the user population, legacy systems, support arrangements and public procurement choices all affect the result. A foreign service demonstrates possibility, not a transferable price tag.

France: do not repeat an obsolete portal story

France is especially important because an older description can lead to the wrong conclusion. AIFE, the state financial IT agency, explains that the public invoicing portal was refocused on a directory for routing and a concentrator for transmitting invoice and transaction data to the tax administration. The refocusing was announced in October 2024 and, according to AIFE, endorsed by the 2025 Finance Act.12

The tax administration describes approved platforms as the services responsible for transmitting and receiving electronic invoices and for passing required invoice, transaction and payment data to the administration.8 It distinguishes these approved platforms from compatible software that does not itself hold the necessary approval.8

The lesson is not that the public component has disappeared. It is that its role is different from a universal public interface through which every business sends invoices directly to customers. A directory and data concentrator are substantial public infrastructure, but they are not the same service as a business-facing invoice exchange portal.

A public-sector receiving portal should also be distinguished from the B2B access route described here. The existence of a B2G route does not establish an equivalent B2B route. France cannot honestly be cited as proof of a general free direct public B2B alternative merely because a public portal exists somewhere in the architecture.

This article does not use a single rollout date as a proxy for the French system’s entire scope. Receiving, issuing and reporting obligations have to be checked for the relevant business and transaction. The architectural point survives without turning a staged implementation into an oversimplified deadline.

Compare the same layers

These examples suggest a better comparison than a league table of countries. Start with the business-facing interface: can the company use a public application, its accounting software, or an approved platform? Then identify the exchange layer: what service accepts, routes or makes the invoice available? Finally, identify the reporting layer: which data reach the tax authority and for which purpose?

Poland’s public application and Italy’s public portal provide evidence about basic access.13 6 France’s approved-platform guidance and AIFE’s description explain a different split between business-facing services and the public backbone.8 12 None of these facts alone settles the total cost or quality of the system.

For B2G, ask a separate set of questions about the public buyer’s receiving service. For B2B, examine obligations between private trading partners. For tax reporting, examine statutory data submission. A diagram that puts all three under one arrow marked “e-invoicing” hides the very choices policymakers need to justify.

A hypothetical business needs more than an upload button

Consider a hypothetical small engineering company. Its accountant prepares ordinary invoices, but some customers require project references and partial deliveries. The owner delegates invoicing during holidays and occasionally corrects an invoice after submission. None of these details is a report about an actual taxpayer.

In a public-application model, the company would ask whether staff can act under limited permissions, whether the application exports the original structured document, and whether acknowledgements remain accessible. In both models it would also examine total cost, switching and remedies. For a public service that includes budget funding, terms of use, replacement of the operator and a route out; for a commercial service it includes the tariff and contractual responsibility. Neither model gets a free pass on recovery or exit.

If a company operates in all three countries, it should not expect one national account to solve all requirements. The purpose of comparison is not to promise a universal workflow. It is to notice which burdens arise from the underlying obligation and which arise from the chosen access arrangement.

A portal that accepts an invoice but makes corrections or delegation difficult may impose substantial labour costs. A commercial integration that saves that labour may be a good purchase. The policy concern is whether purchase remains a choice based on value or becomes the only available route to ordinary compliance.

The strongest case against my preference

A government may argue that approved commercial platforms offer better integration and customer support than a state application could provide. Concentrating public effort on standards, directories and oversight may be a sensible allocation of scarce technical capacity. France’s documented division of functions makes that argument concrete rather than hypothetical.8 12

There is also a fiscal objection: a publicly funded baseline shifts costs to the budget, including taxpayers who do not use it. Maintaining a service that duplicates market offerings could waste resources. I do not assume that public procurement is automatically efficient or that a zero subscription price means zero social cost.

The answer should be an explicit business case. Compare procurement and operating costs, support demand, integration work, migration burdens and the cost of resolving failures. Include a low-volume user, not only firms that already have enterprise software. Publish what the baseline would and would not do.

What Slovakia should take from the comparison

I would ask for two competing, costed designs: a provider-led route with strong portability and small-business protections, and a public baseline with optional commercial automation. Each must identify the business’s contract partner or public-service terms, who selects and pays the operator, and the boundary between essential functions and optional additions. Both need receipts, corrections, permissions, continuity and accountable recourse.

Test replaceability at two levels: a business changing service and the public customer replacing a contractor. Require continuity for pending invoices, exportable history and affordable migration rather than a promise of eventual exit. The public design should not make its essential functions depend on a separate commercial relationship; the provider-led design should demonstrate competition rather than assume it.

Poland and Italy show public-facing tools that deserve examination. France shows why the presence of public infrastructure is not synonymous with direct public access. The useful European lesson is choice in institutional design—not a claim that Europe has already selected one unavoidable relationship between the state, providers and every business.

Compare the Slovak alternatives over the same period and mandatory scope, with Peppol interoperability, support, security evidence, recovery and migration. France’s redesign challenges my preference, but its reasons and transferability need investigation; the country descriptions do not establish comparative efficiency. For an actual cross-border invoice, ask whether the provider supports the specific recipient and which acknowledgement it supplies. A shared standard alone does not answer that operational question.