Readiness Is Not Measured by a Date: APIs, Testing and the Conditions for a Safe Launch

Proposed readiness criteria—not a test result for Slovakia or an announcement of legal postponement.

A published deadline can mobilise a programme. It cannot demonstrate that an accounting system will recover correctly when a submission succeeds but its response is lost. Nor does a public demonstration show that an ordinary company can understand a rejection, obtain support and complete its obligations. Readiness is evidence about those capabilities, not confidence attached to a calendar.

I support e-invoicing and standardised exchange. My concern is implementation discipline: a mandatory process should have explicit conditions for launch and a clear owner of the decision that those conditions have been met. This article does not claim that a named Slovak interface has failed testing. It proposes the evidence that businesses, suppliers and the responsible authority should require.

An API document is a beginning

An application programming interface, or API, defines how software interacts with a service. OpenAPI Specification 3.1.1 describes a standard, programming-language-independent way to describe HTTP interfaces so that people and software can understand service capabilities without inspecting source code or network traffic.6 That is a useful foundation. It is not a certificate that an implementation is correct or operationally ready.

A usable integration contract also needs a supported version, authentication rules, limits, error meanings, examples and a change policy. Some of this can be expressed in a machine-readable description; some requires accompanying operational guidance. The supplier should distinguish what is guaranteed from what is illustrative, experimental or subject to change.

“Stable” should not mean “never changes.” Security corrections and legitimate requirements will continue. It should mean that changes are identified, their impact is explained, transition periods are specified where appropriate and incompatible versions are not silently substituted. Businesses need a process for adapting, not an unrealistic promise that software will remain frozen forever.

Standards and national obligations need separate tests

Peppol BIS Billing publishes invoice and credit-note structures, validation rules, code lists and downloadable Schematron resources.5 These provide concrete assets for checking document conformity. The OpenPeppol eDelivery catalogue separately publishes transport and metadata specifications, with validity information for releases.4 Implementers should identify the versions they are testing rather than referring vaguely to “Peppol compatibility.”

Passing document validation does not demonstrate the truth of the underlying trade. Nor does it establish that an invoice has reached the buyer’s business workflow or that any separate national reporting obligation is complete. A rollout needs evidence at each relevant boundary: document construction, network delivery, customer integration and the legally applicable reporting process.

This is also why a successful demonstration involving one software package and one destination cannot represent every participant. Coverage should be stated honestly. Which document types, customer sizes, recipient arrangements and integration methods were exercised? Which remain untested? A limited pilot can be useful if its limitations are visible instead of being promoted into universal readiness.

A hypothetical integration team

Imagine a software supplier adapting an accounting application used by small retailers. In its test environment, a sample invoice is accepted and a success message is displayed. The team could call the feature complete. Instead, it asks what happens if the request is accepted but the connection ends before the application receives the response. This is a hypothetical example, not a description of any current simulator.

Without a defined reconciliation mechanism, the application may retry blindly or leave the user guessing. The test must establish whether the existing submission can be queried, how repeated attempts are recognised and how identifiers connect the technical request to the business document. The goal is a recoverable outcome, not merely a successful first attempt.

Now add an expired credential, a rejected credit note and a delayed notification. These cases require different user messages and different actions. An accountant should not be told to correct invoice data when the actual problem is service unavailability. A technically accurate error that nobody can act on is an incomplete product requirement.

Make the sandbox honest

A sandbox is useful when its relationship to production is documented. If it uses different limits, simplified identity checks, simulated recipients or a reduced set of rules, say so. Those differences may be reasonable. The problem is not simplification itself but allowing successful sandbox behaviour to imply untested production capabilities.

Provide synthetic examples that represent normal and exceptional documents. Define expected outcomes so independent teams can compare results. State which tests are permitted and which require separate agreement, particularly load, security and failure exercises. No developer should need to experiment against live public services to discover behaviour that documentation ought to explain.

Test data also needs boundaries. Avoid copying real invoices into loosely controlled environments merely because they are convenient examples. Where personal data is processed, GDPR Article 32 requires risk-appropriate measures and includes regular testing, assessment and evaluation of their effectiveness.10 Testing is not a reason to suspend the safeguards being tested.

Require evidence gates rather than a single green light

I would use several linked readiness gates. The specification gate requires a named release, accessible documentation, examples and a change log. The functional gate requires agreed document and error scenarios with recorded outcomes. The interoperability gate requires exchange across representative independent implementations rather than only within one supplier’s product family.

The operational gate requires support ownership, monitoring, incident communications, reconciliation and demonstrated recovery. The legal gate requires authoritative explanations of obligations, acknowledgements, fallback arrangements and exceptional procedures. The adoption gate asks whether ordinary users can complete onboarding and understand what to do when something goes wrong. These are proposed decision criteria, not claims about an existing certification scheme.

Before testing, freeze a prioritised minimum: recoverable ordinary submission, correction, uncertain delivery, reporting where applicable, support and export. The accountable owner should set severity criteria and acceptance thresholds in advance; unexplained document loss or duplication is a proposed blocker, while a cosmetic defect may be accepted with mitigation and a deadline. Do not invent new hurdles after seeing the results. These are proposed criteria, not findings that a Slovak service failed them.

Separate platform, integration, customer and public-rule readiness. Each gate should name its decision owner, executing party, dependency owner, evidence, deadline and change-control process. A blocked external dependency is not automatically a provider defect. Each gate should have a decision record. A known limitation can sometimes be accepted with a mitigation and a deadline. A missing critical capability should not be converted into a minor issue simply because launch is near. Risk acceptance must name who accepts the risk and who bears its consequences.

Include recovery in acceptance

NIST’s contingency-planning guide includes testing, training, exercises and maintenance, not merely preparation of a plan.7 For invoice rollout, an acceptance exercise should therefore continue beyond service restoration. Can the parties explain every document that was pending when the interruption began? Can they distinguish rejection from uncertainty and complete the remaining work without accidental duplication?

Recovery time and recoverable data state are different concerns; NIST distinguishes RTO and RPO accordingly.7 An application that becomes available again may still require backlog processing and reconciliation. Readiness evidence should include those business activities rather than ending with an infrastructure health check.

Do not prescribe one identical architecture for every business. A microbusiness using a supported portal and a large company using automated integration need different operational arrangements. They should nevertheless receive coherent status information and a usable escalation path. The mandatory baseline must work for participants who do not employ an integration team.

Deadlines still matter

The strongest counterargument is that demanding complete evidence can become an excuse for permanent delay. Every complex system has imperfections, and some problems appear only when real users adopt it. Suppliers also need a credible date to justify investment and coordinate releases. Readiness governance must recognise those constraints.

The answer is bounded, risk-based staging rather than perfection or blind urgency. Start with a clearly scoped cohort, publish limitations, measure outcomes and widen participation only when agreed criteria are met. Define what would pause expansion, what can be corrected without interruption and what requires a wider contingency decision. Any staging of a legal obligation requires the relevant legal authority; a pilot decision cannot create a postponement. Businesses must prepare under the applicable rules. An unavailable public test summary proves neither that testing did not occur nor that a business may wait. Legal obligations must be aligned with the actual authorised transition arrangements, not informal technical optimism.

A direct public baseline channel, which I favour, should pass the same scrutiny as a commercial service. Government procurement can arrange delivery, but it cannot turn an incomplete interface into a reliable one by changing the operator’s logo. Commercial providers should remain able to compete for customers and public contracts, not only for add-ons. I would require comparable acceptance criteria, interoperable interfaces and tested operator replacement in public procurement. My preference for a public baseline concerns access to a mandatory function, not a permanent monopoly for its operator.

Publish a decision that can be examined

Before launch, the responsible programme should publish a concise readiness statement: the supported versions, the tested scope, significant unresolved limitations, operational contacts and the basis for proceeding. Sensitive implementation details need not be public, but the decision should be accountable. Businesses should be able to distinguish a mandatory requirement from a roadmap promise.

For an individual company, the immediate actions are simpler: identify the supported integration, complete representative tests, rehearse an uncertain delivery, verify export and recovery arrangements, and train the people who will handle exceptions. Keep the resulting evidence. A date tells us when a system is expected to operate. Readiness tells us why we can reasonably expect it to work, and what we will do when it does not.