Who Is Responsible for an Error or Data Leak: The Business, the Delivery Provider, the Software Supplier or the State?

A map of questions and evidence, with GDPR examined in more detail—not a complete allocation of Slovak e-invoicing liability or a ruling on who pays.

When several organisations participate in a mandatory digital process, responsibility can disappear between their contracts. The software supplier points to the delivery provider. The provider points to the information supplied by the customer. The customer points to rules set by the state. Meanwhile, someone must correct the invoice, contain the incident and establish what happened.

The answer is not to declare one participant responsible for everything. It is to separate the questions that the word “responsibility” conceals. Who must act now? Who owed a particular duty? Who bears a contractual loss? Who has a regulatory obligation? Who may ultimately owe compensation? An e-invoicing framework should make those questions easier to answer, not multiply the places in which a business must search.

Begin with functions, not labels

For a proposed service, I would map the business issuing the invoice, its accounting software supplier, the delivery provider, relevant subcontractors, the recipient and any public authority receiving a separate report. Identify the action each performs and the evidence available at each boundary. Do not assume that one provider operates every component or that delivery to a buyer proves completion of reporting to an authority.

The map should distinguish invoice content from routing metadata, customer administration, security records and retained copies. An error in a customer-maintained recipient identifier raises different questions from unauthorised access inside the provider. A failure to deliver a valid document differs from software calculating an incorrect amount. Responsibility must follow the actual event and applicable duties.

This is especially important for personal data. GDPR Article 4 defines the controller by determining the purposes and means of processing, and the processor by processing personal data on behalf of a controller.13 The commercial name “digital postman” does not resolve that classification. Different activities may require different analysis, including activities performed under a statutory purpose.

A hypothetical incident with several possible causes

Imagine a consulting company discovering that an invoice containing an individual contact’s details reached an unintended recipient. Its accounting software shows the intended customer, while the provider’s record shows a different destination. This is a hypothetical case, not an allegation about an actual service.

Several explanations remain possible. The identifier may have been entered incorrectly before submission. A mapping defect may have changed it. A routing error may have occurred later. The displayed records may themselves be incomplete. It would be premature to declare either the customer or provider legally liable before preserving the relevant evidence and reconstructing the sequence.

The immediate response nevertheless cannot wait for a final legal opinion. The parties should contain further misdelivery, secure records, identify the affected information and use the agreed incident contacts. They should preserve the original document and the transformations applied to it, while limiting unnecessary additional disclosure. Operational cooperation is compatible with reserving legal positions; it should not depend on an early admission of fault.

An invoice may contain personal data, but not every item of commercial information is personal data. Article 4’s definition concerns information relating to an identified or identifiable natural person.13 A dispute over a confidential corporate price list therefore should not automatically be presented as a GDPR claim. It may involve other legal or contractual protections requiring separate analysis.

Where processing is performed on behalf of a controller, Article 28 requires a contract or other binding legal act covering the specified processing and duties.9 These include documented instructions, confidentiality, assistance, and information supporting compliance and audits.9 A generic confidentiality sentence is not a substitute for analysing those requirements.

The same article addresses subprocessors and states that the initial processor remains fully liable to the controller for a subprocessor’s performance of the relevant obligations.9 This matters when a service is assembled from several suppliers. It does not justify treating every software vendor, hosting company or public authority as a subprocessor without examining the relationship.

Notification duties are not interchangeable

Under GDPR Article 33, a processor must notify the controller without undue delay after becoming aware of a personal data breach.11 The controller’s notification to the competent supervisory authority is subject to a different rule: without undue delay and, where feasible, within 72 hours of awareness, unless the breach is unlikely to result in a risk to individuals’ rights and freedoms.11 These are not two interchangeable deadlines.

A contract that allows slow escalation can therefore frustrate the customer’s ability to assess its own obligations. I would require a notification process that begins with the information available, identifies uncertainty and provides updates. Article 33 expressly allows information to be supplied in phases without undue further delay where simultaneous provision is not possible.11

Not every technical fault is a personal data breach, and not every breach triggers the same notifications. The assessment needs facts about the affected data, event and risks. Other duties may also apply under the relevant law and contract. This article is a governance analysis, not a determination of the notification obligations in a real incident.

Compensation and service credits answer different questions

GDPR Article 82 provides a right to compensation for material or non-material damage resulting from an infringement, with specific rules for controllers, processors, responsibility and recourse.12 It does not say that the mere existence of an invoice-processing incident automatically establishes compensation. The conditions of the provision must be examined.

A contractual service credit is a different instrument. A provider may promise a reduction in fees when a defined service level is missed. The buyer should ask whether that is the exclusive contractual remedy, what losses are excluded, what liability limits apply and how claims are made. Compare specific loss scenarios, control over the cause, available evidence and the claims process. A transport service should not silently become unlimited insurance for customer input, a third-party ERP and all consequential loss. Price any wider assumption of risk separately, but do not treat a low tariff as proof that every exclusion is lawful. The legal effect of those terms depends on the applicable law; I do not assume that every limitation is either valid or invalid.

Nor should a private contract be read as eliminating the statutory rights of people who are not parties to it. The service agreement, processing arrangement and mandatory law operate at different levels. A proper review examines how they fit together rather than treating a broad disclaimer as the last word.

Give the state an explicit role without inventing a guarantee

If the state requires a digital process, it should define who owns the interface rules, who publishes authoritative status information and who explains exceptional procedures. If access depends on commercial services, businesses need understandable minimum conditions for those services. This is a policy position, not a claim that the state already guarantees every private provider’s performance. For each proposed condition, identify the competent instrument: Financial Administration guidance, network-authority rules, a contract, public procurement or legislation. The tax administration cannot be assumed to award compensation or alter statutory liability through guidance alone.

My preference is a direct public baseline channel with optional commercial services for integration, automation and support. The state could procure technical operation while remaining the clear public counterpart for the baseline. That model would still need legislation, funding, service responsibilities and remedies. Public operation would not remove the need to identify controllers, processors and accountable decision-makers.

The strongest counterargument is that a state-backed baseline could centralise failure and weaken supplier incentives. That deserves serious design work. I would require fair competition for public contracts, comparable service requirements, usable interfaces and tested operator replacement, not permanent dependence on a favoured supplier. Commercial providers should remain free to compete for customers as well as public operation; a public baseline is not a proposal for a mandatory monopoly. Public accountability should not become unlimited liability for every customer mistake, just as competition should not become a justification for leaving mandatory users without practical recourse.

Put the responsibility map into the purchase

Before signing, request a responsibility schedule covering data entry, validation, transformation, delivery, reporting, retention, export, incident handling and exit. For each function, name the party performing it, the evidence produced, the escalation contact and the relevant contractual commitment. Where an answer depends on law, identify the authoritative rule rather than substituting a sales assurance.

Add separate rows for tax-reporting duties and public-law consequences, accounting correctness and recordkeeping, and contractual commercial-loss claims. Mark their specific Slovak legal bases and allocation as requiring separate verification; the GDPR discussion does not settle them. A task matrix is not a liability judgment.

Then walk through an ordinary error and a serious incident. Who stops further harm? Who can obtain the logs? Who tells the customer what is known? Who decides whether notification is required? Who corrects the business record without destroying the original evidence? If the parties cannot answer during procurement, the same ambiguity will be harder to resolve during disruption.

A workable system does not promise that disputes will disappear. It prevents uncertainty about immediate action from becoming an additional source of damage. Businesses should retain responsibility for their own decisions, providers for their actual commitments and duties, and the state for clear public rules. The objective is not a convenient party to blame. It is a chain of responsibility that still functions when something goes wrong.