A confidentiality risk assessment, not a report of a leak or a finding that existing safeguards are absent.

A customer needs enough information to check a bill. An invoice is one record of a declared transaction; its accounting and tax use requires the relevant particulars and supporting context, not merely its existence. A tax authority may have a lawful reason to obtain information about it. None of those propositions means that the invoice is commercially unimportant outside accounting. Unit prices, negotiated discounts and recurring relationships can be useful to someone who has no legitimate reason to see them. The right response is not to abandon electronic invoicing, but to govern what each participant receives and retains.

I support Peppol because structured exchange can remove unnecessary handling between trading partners. That support does not require treating every additional copy as harmless. Equally, concern about confidentiality does not justify claiming that every invoice contains a secret formula, personal data or classified information. We need a more precise vocabulary before designing protections.

Four different meanings of sensitive

First, information can be commercially sensitive without meeting a particular legal definition. A supplier may not want a customer-specific discount circulated to other customers. That is a practical business concern even before a lawyer assesses remedies. It is reasonable to ask a delivery provider not to reuse such information for unrelated purposes.

Second, a trade secret has legal conditions. Article 2 of Directive (EU) 2016/943 requires secrecy, commercial value because of that secrecy, and reasonable steps by the lawful controller of the information to keep it secret.3 A public list price is not transformed into a trade secret simply because it appears in XML. Conversely, a carefully protected combination of terms may deserve examination even if some individual components are public.

Third, personal data concern an identified or identifiable natural person under Article 4.16 An invoice involving a sole trader or naming an individual contact can contain such data. A corporate purchase of standard components is not automatically personal information in every field. The test concerns the information and its relationship to a person, not whether somebody has labelled the document “B2B”.

Fourth, special-category personal data and officially classified information are not synonyms for valuable business information. GDPR Article 9 identifies particular categories, including data concerning health, and imposes additional conditions for processing.16 An expensive purchase is not thereby special-category data. Nor does a supplier’s confidentiality preference create a national-security classification. Keeping these categories separate avoids both underprotection and exaggerated legal claims.

What a sequence of invoices might reveal

Imagine a fictional manufacturer buying specialised components and selling a finished assembly. Its purchasing invoices identify suppliers, product codes, quantities and prices. Its sales invoices identify customers and negotiated terms. If an unauthorised person obtained a sufficiently broad dataset, the combination might support inferences about procurement patterns, dependencies or changes in commercial activity.

The word “might” matters. An invoice is not necessarily a bill of materials. Components may enter stock, serve several products or be bought through distributors. Labour, waste, overhead, financing, rebates and timing complicate margin estimates. Even access to purchase and sales invoices would not automatically disclose the exact manufacturing recipe or profitability of each unit. A responsible risk assessment should state both the possible inference and its uncertainty.

Still, incomplete information can be useful. A competitor might not need a perfect margin model to exploit knowledge of an unusual supplier relationship or a confidential discount. The architectural concern is therefore about combinations and access, not an assertion that every line item reveals a complete business strategy. Assessment should consider the dataset a role can see over time, not only a single document displayed on a screen.

Follow the copies, not just the transmission

OpenPeppol separates Access Points exchanging messages from addressing and capability lookup.1 An SMP is not the repository of the manufacturer’s component purchases. A security discussion should not attach the risk of invoice-content disclosure to a metadata service merely because both are part of the same programme.

Instead, trace where invoice content is actually processed. In a proposed service, possible locations to examine include the sender’s application, transport queues, the receiving application, any purchased archive and any separate reporting service. Diagnostic logs, support attachments and backups should also be checked. These are audit questions, not a finding that every provider stores full invoices in all of those places.

Compare the same business process before and after the change, including email attachments, local archives and the accountant’s handling that structured exchange may replace. A controlled queue or backup is not equivalent to an uncontrolled copy. Assess purpose, readability, permissions, retention and the consequences of compromise, not just the number of copies. This article does not establish which complete model is safer.

Retention changes the risk. A service that needs temporary access to transmit a document has a different operational purpose from an archive purchased for long-term retrieval. Keeping an additional copy “in case it is useful” deserves a specific explanation. For personal data, purpose limitation and storage limitation are explicit GDPR principles.16 For other confidential information, I would make equivalent questions part of procurement and contract design rather than pretend that GDPR covers all corporate data.

Encryption is necessary context, not a complete answer

It is useful to ask whether a transfer is encrypted. It is more useful to ask where readable content exists and which identities can access it. If a provider must validate or transform a document, the service design should explain how that operation is performed and protected. “Encrypted” does not, by itself, describe every processing stage, administrative permission or backup.

I would require a provider to distinguish routine automated processing from human access. Can support personnel retrieve an entire customer’s invoice history, or only inspect a narrowly scoped case? Is exceptional access approved, time-limited and logged? Can the customer receive meaningful evidence of that access? These are proposed controls, not a claim that the current market lacks them.

I have not established that today’s Slovak access regime lacks these restrictions. I ask for a proportionate public account of existing access, confidentiality and oversight rules, with protected verification of their operation—not publication of investigative techniques.

The same reasoning applies to the state. A reporting purpose should translate into authorised tasks, not unrestricted browsing. If a particular investigation needs more detail, access could be separately justified and recorded. The feasibility and legal basis of that arrangement require design work, but it is a more productive starting point than treating confidentiality as an obstacle to all tax administration.

The strongest case for collecting detail

Tax officials can reasonably argue that totals alone may not answer every question. Description, quantity and context may help distinguish transactions that look identical in aggregate. Businesses also benefit when detailed structured invoices reconcile automatically with purchase orders. Eliminating useful fields from the commercial invoice could destroy part of the benefit of the reform.

I do not propose making invoices deliberately vague or withholding legally required information. Nor does trade-secret law provide an absolute veto over public collection. Article 3(2) of Directive 2016/943 recognises lawful acquisition, use or disclosure to the extent required or allowed by Union or national law.3 A confidentiality concern must therefore be assessed alongside the applicable authority, purpose and safeguards, not treated as proof that collection is prohibited.

The answer is to distinguish the customer’s document from each additional dataset. Retain detail where the purpose requires it, and test whether a narrower reporting message would achieve a particular public objective. If authorities demonstrate that selected line-level information materially improves a specified control, the debate should address that evidence. A promise that more data will always produce better enforcement is not an adequate substitute.

A practical classification exercise

Before choosing a provider, a business can examine representative invoice types with accounting, sales and security staff. Identify required fields, optional descriptions, personal contacts and commercially restricted attachments. Record why each is present. Do not use real customer documents in public demonstrations when synthetic examples can test the same workflow.

Then review templates. A free-text note copied from a project file may contain details that no billing recipient needs. Removing unnecessary narrative is different from disguising the supply or omitting mandatory particulars. Where a contract reference or separate restricted attachment is appropriate, confirm that the resulting invoice remains legally and commercially sufficient rather than assuming that an opaque code solves the problem.

Finally, ask how the service handles bulk export, cross-customer access, incident investigation and deletion at the end of the relationship. A confidentiality clause should match the operational design. It should not promise secrecy while leaving unclear which subcontractors, support teams or analytics functions may use the data.

Protect the transaction without stopping it

The test of an e-invoicing design is not whether it can promise that nothing will ever go wrong. It is whether the necessary transaction can proceed with justified access, controlled copies and clear responsibility. Commercial sensitivity should be considered at design time, before a dataset grows into an asset that nobody has explicitly agreed to govern.

My preferred public baseline channel would be subject to the same test as any commercial provider. Public ownership is not a confidentiality guarantee, and private operation is not evidence of abuse. Publish the data flows, constrain secondary use and give firms credible access and retention commitments. That is how we keep the value of structured invoicing without dismissing the value of the information it carries.

Sources

[1] Peppol Interoperability Framework - OpenPeppol

[3] Directive - 2016/943 - EN

[16] GDPR: original EU Regulation 2016/679 (official UK archive, adopted text)