What eKasa Teaches Us: Does the State Have the Capacity for Direct E-Invoicing Too?

Institutional comparison: VRP 2 is a public application, not a ready-made e-invoice mailbox.

When I suggest a public baseline for electronic invoicing, an obvious domestic comparison is specifically the public VRP 2 application in the eKasa setting. Slovakia’s Financial Administration already offers a public application for recording takings. Why should basic invoice delivery necessarily require a separately chosen commercial relationship?

The comparison is useful, but only if we resist turning it into a shortcut. An existing public application demonstrates an institutional possibility. It does not prove spare engineering capacity, equivalent transaction patterns, successful security testing or an appropriate budget for another service. The right lesson from eKasa is to ask better questions about capability, not to declare the next system solved.

What the existing public service establishes

The Financial Administration describes Virtual Cash Register 2, or VRP 2, as a free application for recording takings, available from 1 July 2022.3 Its information page describes web access and mobile applications, including availability through Apple’s application store from March 2023.3

These are concrete facts about a public-facing tool. Users are not merely given a technical specification and told to buy any interface they can find. For this defined task, the Financial Administration supplies an application. That is a relevant answer to the sweeping claim that a public authority should never provide a usable baseline tool alongside its requirements.

But the source does not provide a verified estimate of the resources available for a new invoice-delivery service. Nor have I benchmarked VRP 2, inspected its internal architecture or measured its availability. I will not turn the existence of a login page into a performance claim.

Free software is not a costless process

The same VRP 2 page recommends checking printer compatibility and warns that vendors or technicians may charge for updating unsupported printing solutions.3 This is a useful corrective to both sides of the public-versus-private argument.

A free public application can remove a software charge without removing equipment, connectivity, setup or assistance costs. Conversely, the existence of those costs does not make the free application meaningless. It establishes a defined service boundary: this functionality is publicly supplied; other parts of the user’s working arrangement remain their responsibility.

An e-invoicing proposal needs the same honesty. Public registration, delegation, access recovery and conditions of use would still require administration. Add any conversion, specialist onboarding and separate archive to both models on equivalent terms. Removing an individual commercial relationship would not remove all user work; a zero public tariff would not describe the full cost of participation.

This is also why I do not argue that public provision must be cheaper. It may move costs from individual subscriptions to the public budget. Whether that is justified depends on the overall benefit, the users served and the standard of service delivered.

Recording takings and delivering invoices are different tasks

VRP 2 is described as an application for recording takings.3 The eFaktúra guidance, by contrast, describes sending and receiving structured invoices through certified delivery services.2 An invoice-delivery service has to connect the issuing side with the receiving side, not simply make a record available within one public application.

OpenPeppol describes network functions including messaging, security, addressing and capability lookup, and describes end users exchanging documents through certified service providers.4 Any proposed public Peppol channel would have to perform or procure those functions. Reusing an existing public identity or interface component, where appropriate, would not remove that responsibility.

There is a business distinction too. The recipient needs a document it can process, review and retain within its own workflow. A supplier needs to understand the delivery result. The Financial Directorate’s FAQ says that delivery of an electronic invoice does not itself constitute acceptance of its substance by the recipient.6 A public channel must not collapse these stages into one reassuring green status.

Tax reporting is another separate function. OpenPeppol distinguishes its business-document work from its work on reporting consumption-tax data to administrations.4 A service design should specify the two flows independently, even when software automates both.

A hypothetical workshop with two kinds of document

Imagine a hypothetical repair workshop that records relevant customer payments through a cash-register arrangement and also invoices business customers. This is an illustration of workflow, not a determination of the tax treatment of any particular sale. Using a cash-register product does not establish readiness to send or receive structured invoices; check the actual functions of the workshop’s software.

For the recording task, a public application may be enough. The owner learns its interface, uses a compatible device and handles the remaining practical requirements. For a business invoice, the workshop also needs the customer’s receiving route, a compliant structured document and a way to resolve delivery errors.

If it adopted a proposed public invoice channel, the owner should not have to become a Peppol administrator. The service should make the simple task simple. Yet someone operating the service would still have to maintain the network connection, manage changes and help when a customer cannot receive a document.

The workshop illustrates why an existing public application is both relevant and insufficient. It suggests that a public baseline can be intelligible to a small business. It does not show that the transport, support and continuity requirements of the new service have already been met.

Capacity is a collection of testable commitments

The first capacity question is organisational: who owns the service from a user’s perspective? If the application, identity system and network connection are operated by different organisations, the workshop should not be required to diagnose which one failed before it can obtain help.

The second is operational. A proposal should state expected workloads, service hours, recovery objectives, support arrangements and dependency failures to be tested. The source material reviewed here does not establish those measurements for a public e-invoicing baseline. They would have to be produced by the project, not borrowed from another application’s existence.

The third is maintainability. Invoice formats, validation rules and network requirements can require coordinated updates. A public operator needs a release process, test environments and communication that lets connected applications adapt. The budget should include that continuing work rather than treat the initial software delivery as completion.

The fourth is institutional continuity. A contractor might operate the service, but the state would need sufficient knowledge and rights to replace it. Public responsibility without practical supplier exit can create dependence at a different level rather than remove it.

The strongest argument against reusing the precedent

A critic could fairly say that eKasa proves only that the state has delivered one application, not that it should deliver another. Specialist invoice providers may already offer better integration and support. A public project might duplicate their work, divert scarce staff and produce an inferior service.

I agree that the precedent cannot carry the whole case. The proper response is a comparative assessment, not an instruction to enlarge VRP 2 until it becomes an invoice platform. “Use the same team” or “add another form” would be implementation guesses unsupported by the evidence here.

The public option should have a bounded target group and measurable objectives. If existing products meet that group’s needs on durable, transparent terms, a public application might not be the best intervention. Common service conditions or publicly procured access could be more proportionate. My preference for a public baseline is a proposal to test, not permission to ignore an unfavourable result.

What a credible pilot would demonstrate

A pilot should recruit different kinds of users: a low-volume recipient, a small issuer with an accountant and a business importing invoices into existing software. Give each the same tasks and record where assistance is needed. Completion of one demonstration invoice would not be enough.

Test what happens when access is lost, an invoice fails validation, the receiving route changes or an external dependency is unavailable. Verify that users can export the original documents and understand the difference between delivery and reporting status. Test recovery with the records needed to explain what occurred.

The pilot should also compare the proposed public route with actual commercial options, including free versions where available. The Financial Administration’s June 2026 announcement explicitly notes such versions.1 Ignoring them would bias the comparison just as much as ignoring the administrative work of choosing and maintaining a provider relationship.

Publish the limitations alongside the results. A successful small trial would support further development, not establish nationwide readiness. A weak result should lead to redesign or rejection rather than a more ambitious press release.

The lesson is responsibility, not automatic readiness

VRP 2 shows that Slovakia can define a public user-facing baseline for a specific administrative task.3 It does not establish that a direct public e-invoicing service is already funded, tested or available. Businesses should not mistake my proposal for a present compliance route.

What I take from VRP 2 is a reason to include the public option in a comparison, not to prefer it automatically. Both models should provide evidence against the same service brief. Count implementation cost, uncertainty of public estimates, stressed workloads, long-term funding and the other public tasks that the new service could displace.

Ask for a service definition, a comparative cost model and a tested operating plan. That is a more demanding position than either “the state cannot do it” or “eKasa proves it can.” It is also the position most likely to produce a service that businesses can depend on.