Classified transactions and professional secrecy: where e-invoicing must have boundaries

A proposal for understandable special-handling procedures—not a determination of today’s Slovak exemptions for a profession.

An e-invoicing system should not force an accountant to choose, at the moment of submission, between disclosing protected information and missing an obligation. If exceptional transactions need different treatment, the applicable boundary and usable procedure should be made clear before submission, building on existing rules rather than assuming a legal vacuum. That is a case for precise rules and workable alternative procedures, not for abandoning digital invoicing or treating every confidential commercial relationship as a national-security matter.

The temptation in this debate is to argue that if some state transactions require protection, every business must receive an identical exemption. That skips the difficult part. Different information can justify different safeguards. The important question is whether the distinctions are grounded in applicable law and actual risk, with a proportionate process that ordinary users can follow.

An important European exception, with a limited scope

Directive 2014/55/EU of 16 April 2014 concerns electronic invoicing in public procurement. Article 1 excludes certain invoices resulting from contracts within Directive 2009/81/EC where procurement and performance are declared secret or require special security measures under national rules, and the Member State has determined that the essential interests cannot be guaranteed by less intrusive measures.17 That final condition is important: the text does not simply say that everything connected with defence is exempt.

It is equally important not to extend this source beyond its subject. A public-procurement directive does not by itself establish the full list of exceptions to a Slovak domestic business invoicing or tax-reporting obligation. Nor does it prove that every invoice involving an intelligence service follows a particular technical route. Those propositions require the relevant national provisions and implementation documents.

The narrower lesson is still valuable. The European framework recognises that invoice processing can intersect with essential security interests, and it expresses a test involving less intrusive measures.17 Designers should therefore be prepared to explain their handling of exceptional information. They should not treat every departure from the ordinary route as an attempt to resist modernisation.

Three categories that must not be collapsed

Slovakia already provides a specific boundary in the published law for the transitional regime beginning on 1 January 2027. Section 85o(2) prohibits issuing the electronic invoice defined in subsection (4) for the relevant supply where the recipient is the Slovak Information Service or Military Intelligence, or where the supply is connected with, requires or contains classified information. This is not a general professional-secrecy exemption and does not identify the permitted technical route for every protected transaction.18

Official secrecy concerns an applicable legal classification or special security regime. Professional secrecy concerns duties attached to particular activities and relationships. Commercial confidentiality concerns a business’s legitimate interest in protecting information, sometimes including legally protected trade secrets. These can overlap, but no single “sensitive” checkbox resolves all three.

Trade-secret protection has its own threshold. Directive 2016/943 requires secrecy, commercial value because of secrecy and reasonable steps to preserve it; it also recognises acquisition, use or disclosure required or allowed by law.3 It would be misleading to claim that marking an invoice “confidential” automatically removes it from a statutory reporting obligation. Equally, a lawful obligation to provide information does not answer every question about subsequent access and handling.

GDPR addresses a different dimension. Its Article 9 sets additional conditions for special categories of personal data, including health data.16 Article 90 permits Member States to adopt specific rules reconciling certain supervisory powers with professional or equivalent secrecy obligations.16 Article 90 is not a general exemption from invoicing or tax reporting. It illustrates why professional secrecy must be analysed in its actual legal context rather than reduced to a generic privacy label.

A hypothetical legal-services invoice

Imagine a fictional law practice preparing a bill for a business client. A routine invoice description states the service period and refers to an engagement. An attached time record, however, describes litigation strategy and names individuals. The example is deliberately hypothetical; it is not a finding that any Slovak provider requires such an attachment or that this particular transaction is exempt.

The existence and scope of a current Slovak professional-secrecy procedure for this law-practice example have not been verified here. The first design question is whether that narrative needs to travel with the invoice at all. The client may need supporting detail through a restricted channel, while billing and reporting may require a different level of description. The responsible professionals must verify what can be omitted or separated without making the invoice incomplete or misleading. A software vendor should not invent the legal answer through a mandatory free-text field.

A second question arises even if the narrative is removed. In some circumstances, the identity of a client, the timing of a service or a reference may itself be sensitive. Replacing an attachment with a code does not automatically remove every disclosure risk. The process needs a route for competent assessment, rather than an instruction to upload the document first and ask for protection afterwards.

A hypothetical restricted procurement

Now imagine a supplier billing for work on a project subject to an applicable security regime. The invoice’s relationship to the protected project matters more than whether the underlying product is ordinary equipment. The same item could be sold in an unremarkable commercial transaction elsewhere. Classification should not be inferred merely from the product name or from the customer’s institutional identity.

For this scenario, the invoicing authority should already have determined who can approve the route, which system may receive the content, what acknowledgment is produced and how the transaction remains auditable. None of this requires publishing protected operational details. A public procedural description can identify the competent contact and decision process without exposing the protected facts themselves.

The exception must cover the whole handling chain. Moving the final invoice to a restricted channel is insufficient if a support ticket, validation error or test dataset exposes its contents through the ordinary service. This is a proposed threat-model exercise, not a report of a discovered leak. It helps ensure that the protective rule survives contact with implementation and troubleshooting.

Metadata can matter without becoming invoice storage

Even when payloads are restricted, addresses, participant identities and event records deserve examination. OpenPeppol describes the SMP as part of addressing and capability lookup and distinguishes it from the Access Points exchanging messages.1 That means an SMP is not an invoice-content archive; it does not mean that all metadata are inherently inconsequential.

For an exceptional workflow, identify which metadata must be published or exposed and to whom. Also distinguish the network’s discovery information from a provider’s transaction logs. These are not the same dataset. Assertions that a public directory reveals a particular protected relationship require evidence, not just the fact that a directory exists.

Designers should test the full observable result using synthetic examples. What would appear in a customer dashboard? What can support staff search? Which identifiers are included in exported logs? The goal is to check whether the chosen protection actually covers the intended information, without conducting experiments using real classified or professionally protected material.

Exceptions must not become an unreviewable escape hatch

The strongest objection is that broad confidentiality claims can undermine consistent reporting. If any firm could exempt itself by adding a label, authorities would face missing transactions and uncertain enforcement. It could also disadvantage businesses that comply through the ordinary route. That is a substantial objection and a reason to design exceptions carefully.

I would therefore require an identifiable legal ground, an authorised decision-maker, a recorded rationale and review where circumstances change. Different grounds may need different decision processes. A narrowly reduced dataset might be enough in one case; a distinct authorised channel could be necessary in another. These are design options to validate, not assurances that businesses may choose them unilaterally.

Auditability should remain even when access is restricted. The permitted record could document that a transaction was handled under an approved procedure without circulating the protected substance to every participant. The precise records and access rights need to be settled by the applicable regime. Confidentiality should control who can verify, not become a synonym for nobody being accountable.

Give businesses a procedure before a deadline

If legal assessment confirms that individual approval is necessary and permissible, I propose a process identifying who may apply, what evidence is needed, how it is safely submitted and what rules apply while a decision is pending. This does not establish that such an application exists or suspends an obligation; some situations may require clarification or legislative change. The competent authorised decision-maker—not the transport provider by default—determines legal eligibility. The provider implements the documented permitted route within its remit. Technical refusal, a legal exemption decision and pending-period rules must remain distinct.

For professional services, standard examples developed with the relevant competent bodies would help separate normal invoice particulars from unnecessary case detail. They should be examples, not a substitute for advice in difficult cases. Training should also cover accidental disclosure in attachments and support communications, since a well-written legal exception cannot correct every poorly configured template.

The statutory restriction described above should not be generalised into an exemption for every institution or profession. The operational question remains how to implement the applicable boundary through a verified process. A direct public baseline channel, which I support, would need that process just as commercial providers do. Trustworthy digital invoicing recognises that some information needs special handling, and makes that handling lawful, proportionate and operationally possible.