An operational continuity checklist; permitted transport, document format and any deadline relief require separate checks.

A reassuring availability percentage does not tell an accounts team what to do with an invoice whose status is unknown. Has it left the accounting system? Has the delivery provider accepted it? Has the buyer received it? Does a separate reporting obligation remain outstanding? Those are operational questions, and a useful continuity plan must answer them before the first serious interruption.

I support e-invoicing because structured exchange can remove unnecessary handling. A required structured document does not mean that every alternative delivery route disappears. Part 06 discusses agreed alternative transport; that is distinct from a special outage procedure or deadline relief. Check the applicable current rules separately for format, permitted delivery and reporting. A mandatory digital process should not leave businesses improvising legal interpretations while suppliers debate whose dashboard is correct. This article proposes purchasing and rollout requirements; it does not report an actual Slovak outage or claim that a particular fallback is currently permitted.

Delivery is not one event

For an implementation, I would require a documented sequence of states: created, locally validated, submitted, accepted for processing, transported, delivered to the relevant receiving component, and accepted or rejected in the recipient’s business process. Where tax reporting applies separately, its submission and acknowledgement states need their own track. These are proposed operational distinctions, not a claim that every provider uses the same vocabulary.

The distinction matters because a technical acknowledgement may establish only one step. A buyer’s accounting team may still reject an invoice for a commercial reason. A provider accepting a request does not, by that fact alone, establish that every later obligation has been completed. The contract and implementation documentation should explain exactly what each receipt proves and what it does not.

OpenPeppol publishes separate specifications for AS4 transport and for service metadata publishing and location.4 That component structure reinforces the need to identify the failed dependency. Failure to locate a destination is not the same event as loss of stored invoice content. Nor should an SMP metadata service be casually described as the database containing every invoice.

A hypothetical afternoon interruption

Imagine a maintenance company sending invoices after completing a set of jobs. Its accounting application receives no final response for several submissions. The provider’s status page reports an interruption. The company needs to close its working day, but the buyer’s payment process depends on receiving the documents. This is a hypothetical scenario, not a reported incident.

The unsafe response is to repeatedly create new invoices and send copies through every available channel. That can turn uncertainty into duplicate business documents and conflicting records. The company instead needs stable document identifiers, a view of pending submissions and a supported way to reconcile each uncertain outcome. Repeated technical attempts should be connected to the same business event rather than silently becoming new invoices.

A useful procedure would tell the accountant which items to leave queued, when to contact support, which evidence to preserve and who can authorise an alternative route. It would also explain what the buyer should see. A technical team may describe the event as “partial degradation”; an accountant needs to know whether to wait, correct, reconcile or escalate.

Recovery time and recovery point are different

NIST’s May 2010 contingency-planning guide distinguishes a recovery time objective, RTO, from a recovery point objective, RPO.7 RTO concerns how long a resource can remain unavailable before unacceptable impact; RPO concerns the point before disruption to which data can be recovered.7 They answer different questions. “We restore quickly” is not an answer to “Which acknowledged submissions might be missing?”

For an invoice service, I would ask for both objectives for each relevant component, then ask how they were demonstrated. A provider’s infrastructure recovery target might not cover the time needed to replay a backlog, reconcile uncertain deliveries or make the customer’s accounts usable again. NIST also distinguishes the wider maximum tolerable downtime and explains why additional processing time matters.7

The objectives must be interpreted with their contractual scope. A number in a procurement appendix may relate to one component, one class of incident or one support period. It should not be promoted into a guarantee for the entire invoicing chain without checking the actual commitment. I make no claim here about the recovery terms of any existing Slovak contract.

Sending a PDF by email may help a trading partner understand what is owed. It does not automatically satisfy whatever structured-invoice or tax-reporting obligation applies. The continuity plan must distinguish a commercial communication aid from a legally recognised substitute. A provider cannot create a statutory exemption simply by recommending a workaround.

The responsible authority should publish the applicable procedure in advance: the trigger for exceptional treatment, the evidence a business must keep, the permitted temporary action, and the steps required after restoration. If there is no authorised substitute, that too should be stated plainly, together with the treatment of affected deadlines and the available escalation route. These are policy recommendations, not assertions about existing relief.

Businesses should also separate external service failure from their own local failure. A public fallback designed for a nationwide incident might not cover an expired credential, an incorrect invoice or a broken office connection. The procedure needs clear boundaries so that an ordinary rejection is not treated as an outage and an actual outage is not disguised as user error.

Continuity includes communications and evidence

An incident message should state which service is affected, when the problem began if known, what customers should do and when the next update will be provided. Unknown facts should remain unknown rather than being filled with reassuring guesses. Status information should be accessible without depending entirely on the failed customer interface.

The company should preserve the original document, submission identifiers, relevant acknowledgements and a chronological record of actions. It should avoid distributing full invoice contents unnecessarily in support tickets. Evidence collection is useful only if it does not create a second, uncontrolled store of commercially sensitive or personal information.

Where personal data is involved, Article 32 explicitly addresses availability, resilience, timely restoration and regular testing or evaluation of security measures.10 This supports a risk-appropriate security baseline, not an entitlement to every premium recovery or support tier. Faster recovery and integration assistance may be separately priced; the relevant legal duties still apply. It does not establish that every interruption is a GDPR infringement. The actual measures, risks and circumstances still matter.

Practise the uncomfortable cases

A continuity exercise should include more than a completely unavailable service. In an authorised test environment, rehearse a response lost after acceptance, a temporary routing failure, a rejected document, a backlog after restoration and a customer support request that arrives without complete evidence. The purpose is to check decisions and records as well as technical recovery.

NIST’s guide includes testing, training, exercises and plan maintenance as parts of contingency planning.7 For invoicing, I would add an explicit reconciliation sign-off: someone must confirm that pending, delivered and rejected items have been accounted for after recovery. A green infrastructure dashboard is not the same as a reconciled sales ledger.

Small firms need a proportionate version. A short procedure, a clear support contact, a visible pending queue and a periodic rehearsal may be more valuable than a long document nobody can use. Larger organisations need wider integration exercises, but length alone is not evidence of readiness. The test is whether staff can make the right decision under uncertainty.

The strongest objection: resilience costs money

Providers reasonably argue that unlimited redundancy and immediate recovery are expensive. Customers should not demand impossible guarantees while buying the cheapest service. Different business processes tolerate different delays, and the cost of resilience should be visible rather than hidden in vague promises.

Compare service levels by measured segment, exclusions, RTO, RPO, queue replay and the party responsible for reconciliation. A public option must be costed at the same level; neither operator can promise statutory relief for an outage.

My answer is not universal maximum availability. It is an explicit baseline for a mandatory process, with additional commercial options where justified. I favour a direct public baseline channel alongside optional value-added providers, but such a channel would also need funding, recovery evidence and an authorised fallback. Public ownership is not a substitute for operational discipline.

Before onboarding, obtain a state model, scoped recovery objectives, an incident communication procedure, reconciliation instructions and the authoritative fallback rules. Then rehearse them with the people who issue and receive invoices. Continuity is achieved when a business can explain both what happened to its documents and what it is allowed to do next—not when a contract merely contains an impressive percentage.

Sources

[4] OpenPeppol eDEC Specifications

[7] NIST 800-34, Rev 1 Contingency Planning Guide for Federal Information Systems

[10] GDPR adopted text, Article 32 (official reproduction)