Why Not Directly Through the State? A Public Alternative to Commercial Postmen

Policy proposal to test—not an available public mailbox or a decision to procure one.

A state that requires businesses to use structured electronic invoices should be able to explain why basic participation depends on a commercial service relationship. It may have a defensible answer. But “this is how Peppol works” does not, by itself, answer who should contract for the service or what a business should receive as a public baseline.

My proposal is a direct public channel for basic sending and receiving, with optional commercial services for those who want more. It is not a claim that such a general state service already exists in Slovakia. It is a design and procurement option that deserves comparison with the chosen model.

Start from the actual model, not an imaginary one

The Financial Administration says that receiving electronic invoices requires contracting a certified delivery-service provider and that access can be through accounting software, a web application or a mobile application.2 Its announcement of 3 June 2026 describes provider selection on the public portal, followed by activation with the selected provider and acceptance of commercial terms.1

That public selection facility should not be mistaken for a publicly supplied invoice mailbox. It helps establish the provider relationship. The announcement also acknowledges free versions of several solutions and integrated products.1 Those offers matter to users, but a provider’s free tariff and a publicly guaranteed baseline are different institutional arrangements.

Peppol would remain part of the proposed alternative. OpenPeppol describes end users exchanging documents through certified service providers.4 The public channel would therefore need to operate or procure a compliant connection. “Directly through the state” describes the user’s access relationship, not a plan to bypass network functions or invent an incompatible national format.

What the public baseline should do

I would begin with a service limited relative to an accounting suite, not a claim of cheap or trivial operation. A pilot should initially target low-volume recipients and issuers with an accountant, with eligibility, volume limits, support hours and scope-change rules fixed before costing. A business should be able to authenticate, authorise an accountant, create or import a compliant invoice, send it, receive incoming documents, display them readably and export its records. The interface should explain errors in ordinary language and show what each delivery status actually establishes.

This is not a proposed national accounting package. Inventory management, payroll, project billing, payment reconciliation and industry-specific workflows should remain outside the basic scope. Commercial suppliers could compete on those features, on automation and on support beyond the baseline.

Storage requires two separately costed variants: A, delivery with temporary retrieval and export, leaving the business to arrange retention; B, delivery with a defined archive, including its duration, recovery and exit. Neither automatically transfers the accounting entity’s legal obligations to the operator. If it does not provide an archive, it must make export reliable and understandable. “You could theoretically download something” is not enough for a user who discovers the limitation after a supplier change or a lost account.

The baseline should have a documented application interface as well as a simple browser interface. Otherwise businesses with existing software might be forced back into manual uploads. Open specifications and test access would be proposed requirements from the start, not favours negotiated with a successful contractor after implementation.

A hypothetical comparison without invented savings

Consider a hypothetical self-employed translator who receives supplier invoices and issues a modest number of invoices to business clients. Assume the relevant transactions fall within the applicable regime. The translator already uses an accountant and does not want an enterprise software project.

Under the commercial model, a free or paid integrated service might work perfectly well. Under the proposed public model, the translator could use a basic public interface and give the accountant appropriate access. Neither route is automatically cheaper overall: devices, connectivity, support and the user’s time still have a cost.

Now consider a hypothetical manufacturer with purchasing workflows and production software. A public browser form would probably be inadequate for its operational needs. The manufacturer should remain free to use a commercial provider with deep integration and contractual support. There is no reason to make it pass through the public user interface merely to satisfy an ideological preference.

These examples define different user needs, not measured adoption rates. A pilot would have to establish whether the simple service genuinely helps the first group without imposing costs or bottlenecks on the second.

Public responsibility does not require public coding

A public service could be operated in-house or procured from private suppliers. Baseline transport itself has commercial value; the dispute is who procures and pays, not whether providers are useful. State procurement could remove the individual commercial relationship for the minimum. Registration, delegation, access recovery and public-service conditions would remain and must be counted fairly against the administration of commercial offers.

I am not claiming that any procurement route is automatically lawful or easy. Competition rules, funding, service eligibility, network accreditation and public accountability would need assessment. The question for policymakers is whether this arrangement can produce a clearer baseline at an acceptable total cost, not whether the word “public” resolves those questions.

The state should retain control of the service definition, operational evidence and exit plan even if a contractor writes every line of software. Buying technical expertise should not mean surrendering the practical ability to change supplier. These are proposed procurement conditions, not findings that the present arrangements lack them.

Keep delivery separate from tax collection

A business invoice is sent to a customer for a commercial purpose. Tax reporting serves another purpose. OpenPeppol’s own description distinguishes business-document exchange from work on reporting consumption-tax data to tax administrations.4 A public baseline should preserve that separation in its architecture, permissions and user explanations.

Public operation should not mean that every official can inspect every invoice. The proposed design should identify the data needed for routing, the data used in delivery, the information required for tax reporting and the access justified for each function. Retention should be specified for each purpose rather than inherited from a convenient database setting.

The service should also avoid implying that successful transport validates the underlying transaction. The Financial Directorate’s FAQ explicitly distinguishes delivery from the recipient’s substantive acceptance of an invoice.6 A public logo does not prove that goods were delivered, that a price was agreed or that a tax treatment is correct.

These boundaries are safeguards to design and verify. They are not claims of a demonstrated breach, unlawful processing or proven weakness in today’s providers.

The strongest objections deserve a serious answer

The first objection is an oversized, costly programme dependent on one contractor, with an outage affecting many users. Require limited scope, reviewed continuity arrangements, documented interfaces, portable data and configuration, and the documentation and usage rights a replacement operator needs for takeover. Price exit in advance and test that another operator can actually take over. Compare single- and multiple-operator designs: several operators may support competition, but their number alone guarantees neither independence nor continuity.

The second objection is market distortion. A subsidised public product could displace affordable services that already work. The answer cannot be “private suppliers will adapt.” Government should publish the proposed service boundary, estimate its full costs and assess whether the same objective could be achieved more proportionately through common service terms, targeted support or public procurement of access.

The third is that free commercial offers may already solve the low-volume problem. They could. But the evaluation should examine continuity, eligibility, tariff changes, exports and support, not merely the current headline price. A public baseline should be justified by a durable service need, not by hostility to businesses selling useful software.

What would count as evidence?

A pilot should compare participants performing the same tasks through the existing market and the proposed public channel. Measure successful onboarding, assistance needed, time to retrieve a received document, clarity of failed-delivery messages and successful export to another application. Include accountants and users who are not technically confident.

Operational tests should cover recovery from a failed component, a user losing access, a contractor change and a reporting failure that does not coincide with a delivery failure. Compare equivalent support, recovery, retention and exit in a public application, publicly financed access through several providers and lighter interventions such as common terms or targeted support. Cost estimates should include support staff, security work, maintenance and migration. Publishing only development expenditure would leave the central governance question unanswered.

Success should not mean forcing everyone onto the public route. It should mean that a defined group can meet the baseline need more simply, while private services remain interoperable and attractive where they add value. If the pilot cannot demonstrate that, the proposal should change or be rejected.

A practical choice, not a slogan

Slovakia already offers a free public application for a different task: the Financial Administration describes VRP 2 as a free application for recording takings.3 That is a relevant precedent for public service responsibility, not proof that an invoice-delivery service would be equally simple or already available.

The next step should be a published options assessment with a bounded prototype, not an immediate promise of universal free invoicing. Businesses should continue preparing for the existing requirements while that assessment takes place.

I want electronic invoicing to succeed. A public baseline with voluntary commercial enhancements is one way to ask a precise question: can the state guarantee basic access without making each affected business separately enter the relationship through which that access is delivered?