A proposed proportionality framework, not a finding of excessive collection or a substitute for current reporting duties.

“Collect everything now; decide how to use it later” is a convenient engineering brief and a poor statement of public purpose. Yet the opposite claim, that tax administration never needs invoice detail, is equally unconvincing without evidence. The useful question is narrower: which information is necessary for which task, who needs access to it, and for how long? An e-invoicing reform should answer that question before collecting business-document data for tax administration.

I favour digital invoicing and more effective administration. I do not see data minimisation as a demand to make tax control ineffective. It is a discipline for identifying the least intrusive workable design, then being explicit about the residual information and risk. The discipline is strongest when supporters of a reform can explain why they rejected narrower alternatives.

does not make all corporate information personal data. Article 4 concerns information relating to an identified or identifiable natural person.16 A document may mix corporate information, personal contact details and information about a sole trader. Its treatment therefore requires looking at actual fields and context, not choosing between the slogans “all invoices are personal” and “business data are never personal”.

For personal data, Article 5 requires that the information be adequate, relevant and limited to what is necessary for the purposes of processing; it also addresses purpose limitation, storage limitation and accountability.16 “Necessary” does not mean the smallest imaginable number of fields regardless of function. It means that a collection decision needs a defensible connection to the specified purpose.

Lawfulness is a separate question. GDPR Article 6 recognises, among other grounds, necessary processing for a legal obligation and for a task in the public interest or exercise of official authority; Article 6(3) addresses the legal basis for those grounds.16 It would therefore be wrong to say that a tax authority always needs a person’s consent to process invoice information. Equally, a reference to public interest is not a complete explanation of every possible use or retention period.

Do not merge delivery with reporting

A customer may need product descriptions, quantities and references to reconcile a purchase. A tax authority has a different function. An intermediary may need sufficient information to route and process a message. Giving these actors identical payloads might be technically convenient, but their individual purposes should still be analysed.

Peppol’s architecture distinguishes message exchange from addressing and capability lookup.1 An SMP publishes service metadata; it should not be described as a database of invoice contents. Likewise, the fact that an invoice travels through a delivery network does not establish the contents of a national tax report. The reporting dataset should be specified on its own terms rather than inferred from the format used between supplier and buyer.

This distinction opens practical options. A reporting service could, as a design proposal, receive a defined subset while the buyer receives the full commercial invoice. Another option might retain detailed data under more restricted access. Neither is automatically appropriate or legally sufficient. Their value is that they give policymakers alternatives to compare, instead of treating the first technically available payload as inevitable.

A hypothetical field-level review

Consider a fictional consultancy billing a sole trader for a project. Its draft invoice includes the recipient’s identifying information, the period of service, a fee, a project reference and a lengthy narrative copied from an internal work record. Suppose a proposed reporting interface would receive every field. We should not begin by declaring the entire transfer unlawful. We should ask what each field contributes.

The parties’ identifiers and financial information may serve transaction matching. The service description may have a distinct accounting or control function. The copied narrative could contain personal or commercially restricted context unnecessary for routine billing. The business should first ask whether that narrative belongs on the invoice at all. A regulator should separately explain whether receiving it improves a specified public task enough to justify collection.

This review should not encourage false descriptions or the removal of legally required particulars. If a shorter description or reference is proposed, verify its adequacy under applicable invoicing rules. A privacy measure that prevents the customer from understanding the bill or the authority from carrying out a lawful check is not a successful design. The goal is an accurate document and a justified reporting dataset, not an opaque one.

A necessity test that can be evaluated

I recommend a public field-purpose register as one way to demonstrate proportionality, not a legally prescribed form. For each field or justified group of related fields, give the purpose category, legal source, access rules, retention and alternatives considered. Some information has value only in combination. Detailed detection rules and test results should be examined by authorised oversight under protected conditions, not published as an evasion manual. Distinguish demonstrated operational need from hypothetical future analytics.

Start with the reported fields already described from the January 2026 guidance in Part 05; do not assume collection of everything. For that review, I would distinguish the substantive reporting sponsor, which should explain the purpose and expected benefit; the technical implementer and operator, which should demonstrate safe, reliable and correct processing; and the rule-making authority, which should justify the scope, proportionality and safeguards. This is a functional accountability model, not an assertion about the Slovak organisational chart or a substitute for determining legal data-protection roles. Functions may share an organisation. IT remains responsible for its design, validation, security, recovery and ; implementing a requirement does not exempt it from scrutiny. The provider should also explain its own queues, logs and other operational processing. Neither the provider nor the customer may unilaterally omit required data. Proposed narrower messages also need testing for transformation errors, version maintenance and implementation cost.

Testing can compare alternative datasets on representative, lawfully handled cases. Does a proposed detail improve identification of a defined problem? Does it increase false positives? Could a targeted request obtain the same information when needed? No single result settles the whole policy question, but a documented comparison is more informative than assuming either that current summaries are sufficient for everything or that exhaustive data are inherently superior.

The test should also cover time. Information needed to resolve a current discrepancy need not automatically remain equally accessible forever. Retention rules, restricted historical access and eventual deletion should correspond to legal requirements and purposes. GDPR Article 25 expressly connects protection by default with the amount collected, extent of processing, storage period and accessibility.16 That gives architects several levers beyond simply deleting columns.

Trade secrets require a parallel assessment

Commercial confidentiality does not disappear where GDPR stops. Under Article 2 of Directive 2016/943, a trade secret must meet the requirements of secrecy, commercial value because of secrecy and reasonable protective steps.3 Those requirements should be assessed rather than presumed for every price or product code.

The same directive recognises in Article 3(2) that acquisition, use or disclosure is lawful to the extent required or permitted by Union or national law.3 It follows that pointing to a trade secret does not, on its own, prove a tax collection unlawful. The relevant questions concern the applicable legal authority and safeguards, with specialist advice where the situation requires it.

As a governance proposal, I would extend a minimisation review to valuable non-personal information too. Not because GDPR secretly covers all business data, but because unnecessary collection creates operational obligations and potential consequences. A public system should be able to explain why an employee, contractor or analytical process can access sensitive commercial detail, even when no natural person is identified.

Impact assessment is a method, not a verdict

Article 35 GDPR requires a data protection impact assessment before processing likely to result in a high risk to individuals, taking account of its nature, scope, context and purposes.16 It is not accurate to say that every electronic invoice automatically triggers a separate assessment. Nor should we infer from an unpublished assessment that no assessment exists.

For a large reporting design, the project owner should document the applicability analysis and, where required, perform the assessment before the relevant processing. Article 35(7) includes necessity, proportionality, risks and envisaged safeguards in its required content.16 Publication of a useful non-sensitive summary would improve scrutiny, while details that expose security weaknesses can be handled appropriately. That publication request is my governance recommendation, not an assertion that GDPR requires publishing every full assessment.

Roles also matter. The controller determines purposes and means; a processor acts on its behalf under the GDPR definitions and Article 28 framework.16 A network diagram or the label “digital postman” does not settle the role for every activity. Delivery, statutory reporting and independent secondary use should each be considered. Contract wording needs to reflect actual functions rather than create a universal label for a whole supply chain.

The strongest objection and the next step

Authorities can argue that narrow collection leaves blind spots and targeted requests create delay. That is a serious operational concern. It should be answered with testing and design, not dismissed as a pretext. Some detail may prove necessary. Safeguards may then include restricted access, shorter retention for certain uses, meaningful logs and independent review rather than an absolute prohibition on collection.

My conclusion is not that the Slovak model has been proven to violate GDPR. Part 05 supplies a source-bounded starting point for the legal scope; this article has not mapped it to the complete current payload, purposes and safeguards. No specific redundant field is established here, and a register not reproduced here must not be presumed absent at the operator. My conclusion is that public confidence requires those matters to be explainable. Publish the field-purpose register, distinguish delivery from reporting, document the impact assessment decision and test less extensive alternatives. A reform that passes that examination will be more credible, not less digital.

Sources

[1] Peppol Interoperability Framework - OpenPeppol

[3] Directive - 2016/943 - EN

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