A Public Baseline for E-Invoicing: Conditions for Security and Competition

A public-baseline proposal with conditions, not a security guarantee. Public and commercial designs must demonstrate the same controls, recovery and remedies. Ownership is not a comparative test result.

A public alternative to commercial invoice delivery should be more than a slogan and less than a promise of perfect security. Its purpose would be straightforward: enable a business to meet the basic obligation without having to enter a separate commercial relationship, while leaving room for providers to sell useful automation and support.

That is a policy and architecture proposal, not a description of an already implemented Slovak service. It needs a legal basis, a business case, procurement, testing and sustainable operation. Public ownership alone does not establish safety. The question is whether we can design a baseline whose responsibilities and data boundaries are clearer than the alternatives.

I would keep Peppol interoperability, separate customer delivery from tax reporting, and make the state accountable for the basic channel it requires businesses to use.

Define “direct” from the business user’s perspective

Direct public access need not mean the absence of private contractors. The state could procure operation, hosting and support while offering one publicly accountable service to businesses. The intended difference is that the business would not separately have to choose a commercial provider and accept its terms merely to use the baseline. Commercial tariffs may also be free; the objection concerns the mandatory relationship, not a universal fee or individually negotiated contract.

There are limited foreign precedents for public-facing access alongside providers. Finland’s instructions offer a free online route for invoicing government agencies when suitable software is unavailable, while also describing operator and Peppol routes.1 The Swedish Tax Agency offers its suppliers a free portal provided by a commercial company.2 Neither example proves that a universal Slovak B2B service would have the same costs or scope.

The proposed baseline should include both sending and receiving, understandable status information, corrections, delegated access and export. A service that only submits tax data should not be marketed as complete invoice delivery. Nor should a receiving mailbox be mistaken for long-term legal archiving unless that function is explicitly included.

Separate the flows before drawing the servers

I would define three connected but distinct functions. The first is creation and business exchange: an invoice moves from the supplier’s software or public form to the customer. The second is statutory reporting: the required data reach the tax authority. The third is evidence and operational support: acknowledgements, error records and recovery information explain what happened.

For each function, the design must identify the recipient, purpose, data fields and retention period. A single document may supply inputs to more than one flow, but that does not justify giving every component access to every field.

This separation also prevents an important semantic error. A tax-report acceptance is not automatically evidence that the customer received the invoice. A customer-facing delivery acknowledgement is not automatically a tax acceptance. The business should see both outcomes without needing to understand the internal topology.

If future legislation requires a particular reporting dataset, the architecture must meet it or the law must change. Calling unnecessary data “metadata” does not remove legal duties, and calling every invoice field “necessary” does not demonstrate proportionality.

Minimise routine access, not legitimate evidence

For personal data, the GDPR requires purpose limitation and data minimisation, and Article 25 requires appropriate safeguards by design and by default.21 Those duties inform the proposal, but they do not prescribe one national invoice topology or establish that a competing topology is unlawful.

My starting point would be a field-by-field justification for routine tax collection. Keep the dataset needed for the stated control and reporting purposes; explain any need for additional item detail. Supporting contracts and sensitive attachments should not be copied into every operational component simply because they exist.

That is not a proposal to make evidence unavailable. Where an authorised inquiry needs more information, a controlled request can provide it, with access and retention rules appropriate to that purpose. Nor is a document hash an adequate substitute for every reporting field. A hash can help check whether a document matches a reference; it does not disclose the taxable amount or prove that the underlying supply happened.

Business confidentiality also extends beyond personal data. The design should protect prices and commercial relationships without incorrectly labelling every company record as GDPR-protected personal information. Legal classifications need to be accurate before controls are assigned.

Apply zero trust without selling invulnerability

NIST’s Zero Trust Architecture publication explains that trust should not be granted merely because an account or asset sits inside a particular network or belongs to the organisation.10 That is a useful principle for the public baseline: crossing the perimeter should not confer broad authority to read invoices.

I would use narrowly scoped service identities, separate operational roles, controlled administrator access and recorded exceptional access. Keys and credentials need rotation and recovery procedures. Authentication, authorisation and monitoring should address the particular operation, not just the location of the caller.

Encryption in transit and at rest is important, but neither makes misuse impossible. Transport encryption protects a connection, not against every authorised endpoint that can read the payload. Encrypting the invoice so that only the final customer can read it would require careful compatibility analysis for validation, conversion, support and lawful reporting.

I therefore would not promise end-to-end payload secrecy as a feature that can simply be switched on without changing the workflow. Any such design must identify who can decrypt what, how keys are recovered and how necessary functions still operate. Zero trust reduces inappropriate implicit trust; it does not deliver zero risk or automatic legal compliance.

A hypothetical outage should have a defined outcome

Imagine a hypothetical small manufacturer submitting an invoice through the public channel. Customer delivery succeeds, but the reporting service is temporarily unavailable. A vague green tick would be misleading; so would a generic error that encourages the user to send the same invoice again.

The proposed system should retain a stable submission identifier, show the two statuses separately and queue the outstanding reporting step according to documented rules. Repeated submission should not silently create a duplicate business invoice. When service resumes, reconciliation should establish whether the missing step completed.

The law must define the consequences of an outage, including acceptable evidence of attempted compliance and any permitted delayed submission. A technical queue cannot create a legal grace period. Equally, an availability target in a contractor’s agreement cannot alone determine whether the taxpayer fulfilled a statutory duty.

Testing should exercise partial failure, expired credentials, revoked delegation, delayed acknowledgements and corrections—not merely demonstrate one successful invoice. Apply those tests to both models, including replacement of the operator and dependencies shared across nominally separate suppliers. Recovery needs observable acceptance criteria, including restoration of data and reconciliation of uncertain outcomes.

Assign responsibility before an incident

The business remains responsible for the information it supplies, subject to the applicable law. The public service should accept responsibility for the functions it undertakes. The contractor’s duties should be enforceable by the public customer without requiring each affected business to discover which subcontractor caused the failure.

I would publish a responsibility matrix covering identity, routing, validation, reporting, evidence, retention, incident response and user support. This is a proposal for operational clarity, not a statement that one matrix can replace statutory liability rules.

Data-protection roles must follow the actual allocation of purposes and means. They cannot be settled merely by calling everyone a processor in a contract. Article 26 of the GDPR addresses joint determination of purposes and means, while Article 28 governs processor arrangements.21 The relevant role should be assessed separately for each processing activity.

The business also needs a usable remedy: a single support route, preserved incident evidence, clear escalation and published handling of failed submissions. Liability caps, exclusions and compensation rules require legal and economic review. “The state stands behind it” is inadequate if nobody can explain what happens after a loss.

Keep the commercial market useful and contestable

I support a public baseline, but it must leave a contestable market for providers. Publish documented interfaces and equal integration conditions, define the funded baseline narrowly enough to distinguish optional additions, and prohibit exclusive technical dependencies that prevent competing services from connecting. Businesses should be free to buy automation, analytics or international support without buying access to their own mandatory records. The public baseline must be usable in its own right, not deliberately made inconvenient to force businesses into paid extras.

Require practical exit on both sides. Business switching must preserve structured invoices, evidence, addressing, permissions and pending transactions. Public procurement must require usable documentation, transition assistance and tested operator takeover, including necessary data and operational access under controlled conditions. Cost the replacement before award and rehearse it before dependency becomes unavoidable. A nominal right to terminate does not make replacement feasible.

The strongest objection and the decision test

The strongest objection is that a public channel could concentrate operational risk, consume public money and become a slow-moving competitor to better private services. A commercially operated ecosystem may deliver better support and resilience. These are real possibilities; the proposal must earn its place through comparison.

I would commission costed alternatives and pilot them with low-volume firms, integrated businesses and users needing delegated access. Publish task completion, support demand and failure recovery results without inventing savings in advance. Article 32 of the GDPR explicitly includes resilience, restoration and testing among the relevant security considerations for personal-data processing.21

The proposal fails its own criteria if it cannot demonstrate replaceability at reasonable total cost and genuine competitive space for optional services. It also fails without credible security, recovery and recourse evidence. A public label cannot rescue those failures. I still prefer an accessible public baseline, but an improved provider-led design may win the comparison. Adoption should follow measured capability, sustainable funding and clear responsibility, not ownership or a promise of perfect safety.