Message IconCustomer SupportUser IconContact SalesLock IconLogin

Identity: A forgotten theme in Digital Tax Reporting

What is the identity of the person submitting a tax report illustration
Credit/Source:AI generated

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 is allowed to send them.

That means adding:

  • Verified C1, and possibly C4, identity data
  • 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.

Contact Us

FAQs Hero Image

FAQs

Do I need to upgrade my SMP immediately?

No, but don’t wait until the last moment. Migration to HTTPS must be complete by Feb 1, 2026, and you can begin moving from Nov 1, 2025. Early testing is strongly recommended.

Will the switch to NAPTR records disrupt document exchange?

Not if you prepare. Both CNAME and NAPTR will work in parallel from May 1 – Nov 1, 2025, giving you a testing window. By Feb 1, 2026, all systems must use NAPTR.

Do I need new infrastructure to comply?

In most cases, no. You’ll need:

  • Valid TLS certificates for HTTPS
  • DNS updates to support NAPTR records
  • Updated software configurations for Access Point lookups

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.

Glossary Hero Image
More Stories
What is the identity of the person submitting a tax report illustration
Identity: A forgotten theme in Digital Tax Reporting

As tax reporting moves into real time, identity can no longer be assumed. In a world of continuous transaction controls and outsourced compliance, tax authorities must instantly know who is submitting a report, on whose behalf, and under what authorization. Without verifiable identity, automation breaks and trust with it.

Difference between VAN networks and Peppol networks illustration
The difference between the Peppol network and traditional e-invoicing networks

The Peppol network is a decentralized, international e-invoicing infrastructure using a 4-corner model. This allows organizations to exchange e-invoices through certified service providers without needing bilateral agreements between senders, receivers, or providers. It ensures interoperability and avoids vendor lock-in. Traditional e-invoice (VAN) networks rely on bilateral agreements, creating a fragmented ecosystem.

Surreal paintaing of PDF inspired by Magritte with person looking at painting
Get ready for the Belgium e-Invoicing mandate

Belgium’s B2B e-invoicing mandate is now law. From 1 January 2026, nearly all Belgian VAT-registered businesses must send and receive structured electronic invoices using Peppol BIS Billing 3.0, aligned with EN 16931. PDFs and paper invoices will no longer suffice. The framework also prepares Belgium for near real-time VAT e-reporting by 2028, with penalties for non-compliance already defined.