Identity: A forgotten theme in Digital Tax Reporting

What is the identity of the person submitting a tax report illustration

Credit/Source:AI generated

Dec 22, 2025

Digital reporting of tax and VAT for businesses is being rolled out and will be a reality in many countries in a few years from now.

As Tax Authorities realize this shift with e-reporting and Continuous Transaction Controls (CTC), one theme is becoming impossible to ignore: identity.

Not just “who are you?” – but “who are you submitting a report for?”, “who authorized you to submit”, and “can that be verified in real time?”

Today a business submits periodical tax and VAT reports directly to the Tax Authority. Simple.

In the world of VAT in the Digital Age (ViDA) and CTC, that same business is likely to outsource report submission to its e-invoicing Service Provider. The provider submits Tax Data Documents (TDD) and handles compliance. Also relatively simple, until you look at it from the Tax Authority’s perspective and realize that every system built on automation requires certainty and trust. It must know which provider submitted the report, which taxpayer they represent, and whether that authorization is valid at the time of submission. Without that, real-time controls fall apart. CTC relies on trust. Trust relies on identity.

CTC relies on trust. Trust relies on identity.

Why the chain of identity matters

Every transaction involves at least four core identities in the 5-corner model that is likely to get widespread use in digital tax reporting:

Corner 1 (seller) – The entity with tax obligations.
Corner 2 – The Service Provider of the seller, submitting reports on the seller’s behalf.
Corner 3 – The Service Provider of the buyer, submitting reports on the buyer’s behalf.
Corner 4 (buyer) – The entity whose status determines deductions and rules.
Corner 5 – The Tax Authority

If either identity is wrong, mismatched, or unverifiable, the entire chain of accountability breaks.

For example, a TDD submitted by an unauthorized Service Provider is not just an error, it’s a risk. Authorities can’t reconcile data, fight fraud, or guarantee the legal source of the report.

This is why identity is no longer a check-box in a system or in a form. Identity must be a part of the infrastructure.

The authorization challenge

When a business outsources its e-reporting, the tax authority must see evidence, not assumptions, that the service provider is allowed to report on behalf of the business.

Different countries solve this in different ways:

Authorization registries where a taxpayer pre-registers their service provider, such as in UAE and in France.
Digital delegation tokens cryptographically linking C1 → C2, such as in Italy and Portugal.
API-based authorization flows where the tax authority issues tokens only after validating the authorization.

The pattern is the same: build an unbroken, auditable link from the taxpayer to the submitter.

Cross-border identity: where it gets messy

Domestic identity is not always easy, but cross-border identity is a much more challenging problem to solve.

Inside the EU, eIDAS 2.0 and digital wallets will strengthen interoperability. A company in one EU country will be able to prove its identity, and its authorizations, to another country’s tax authority.

But the moment a non-EU entity enters the picture, everything gets complicated:

Different trust frameworks
Different PKI systems
No shared authorization model
No automatic recognition of service providers

This is where frameworks such as the Peppol network can play an increasingly important role.

SMPs: from routing registries to trust registries

Today’s Service Metadata Publishers (SMPs) mainly tell you where to send documents.

In a CTC-driven world, they may also need to tell you who are the end users exchanging data and who are their respective Service Providers that report on their behalf.

That means adding:

Verified C4, and possibly C1, identities
Delegation information
Tax authority residency
Tax eligibility
Validation rules for specific jurisdictions

If SMPs evolve in this direction, they become more than directories, they become trust anchors for tax identity in a real-time reporting world.

The bottom line

CTC isn’t just about sending structured data. It’s about proving authenticity in a complex, fast-moving ecosystem. Therefore, identity needs to become an essential backbone of that ecosystem. This creates a need for companies or partnerships between companies that create solutions which support identity, authorization, and interoperability, across borders and regulations.

Curious to hear how Arratech can help? Get in touch and we can explain how our platform is setup to support CTC.

FAQs

Does the UK mandate use Peppol, or will it have its own format?

The UK government has signalled that it will align with international standards and will most likely adapt to the Peppol Network, the same network already mandatory in Belgium, Germany, Australia, and Singapore and used in many other countries. Full technical specifications are still being finalised by HMRC, but the direction is clear: structured XML invoices exchanged via an approved network, consistent with the EN 16931 European standard. This is good news for vendors already connected to Peppol elsewhere. Slovakia, Belgium, and the UK are all expected to use the same underlying infrastructure model, meaning you can work with one Peppol Access Point infrastructure provider such as Arratech and cover all of them. Arratech monitors HMRC guidance continuously and will update customers as the UK framework is confirmed.

My platform serves both UK and European customers. Do I need separate integrations for each country?

No and this is one of the strongest arguments for acting now. Peppol is a single network with country-specific configurations, not a collection of separate systems. Through working with an infrastructure provider such as Arratech, you can cover UK, Belgium, Germany, France, Slovakia, and many other mandate markets through one connection. The invoice format (EN 16931 XML) is the same European standard across all of them. The difference between countries is which Peppol Authority accredits providers, which syntax variants are accepted, what additional reporting obligations apply. Arratech's unified API handles this per-country complexity automatically, so your platform doesn't need a separate integration for each jurisdiction.

We're a software vendor, when should we start preparing for the UK e-invoicing mandate?

The demand from your customer does not correlate with the deadline of 2029, it's that your enterprise customers will start asking about what you are doing to stay compliant already in 2027, and procurement cycles for infrastructure changes run 12–24 months. The practical answer is almost always to partner with a dedicated experienced Peppol Access Point provider rather than build your own. Building and certifying your own Peppol AP takes 12+ months, requires ongoing OpenPeppol certification maintenance, and demands a dedicated compliance engineering function. Partnering gives you the certainty of being live well before deadline, compliance updates being handled by your partner and provides one simple connection for the increasing complexity as each country implements its own flavor of Peppol Network. The vendors who are ready in 2027 are the ones making the partnership decision in 2026.

Glossary

Peppol Service Metadata Publisher (SMP)

A Service Metadata Publisher (SMP) is a registry on the Peppol network that stores essential details about a business or organisation — such as which types of electronic documents (e-documents) it can receive (e.g., e-invoices, purchase orders) and how those documents sho

If your organisation wants to receive e-documents via Peppol, it must be registered in an SMP. Without this registration, other companies and government agencies cannot find the technical information they need to deliver documents to you.

Service Metadata Locator (SML)

The Service Metadata Locator (SML), the only central component in the Peppol eDelivery Network. It keeps track of where each participant’s Service Metadata Publisher (SMP) is located. When a sender wants to deliver an electronic document, their Access Point queries the SML to find the correct SMP address for the recipient. The SMP then provides the detailed technical information needed to send the document securely and correctly.

CNAME record

A DNS record type formerly used for SML lookups (pointing one domain name to another) that is being deprecated in this context.

NAPTR (U-NAPTR) record

A DNS record type that replaces CNAME in the new lookup method. It supports more advanced and flexible routing for metadata resolution.