E-Invoicing & E-Reporting Explained: Governance & ownership

For other episodes in ”E-Invoicing & E-Reporting explained”, click HERE

Tax vs IT vs Finance responsibilities; how to set up a scalable operating model

1. Executive Summary

E-invoicing and e-reporting are no longer isolated departmental projects; they are fundamental “enterprise transaction controls” impacting billing, cash collection, supplier payments, VAT reporting, and audit evidence. The central challenge is not assigning singular ownership to Tax, IT, or Finance, but rather clearly allocating accountability for specific outcomes, decisions, controls, and exceptions across the entire end-to-end process.

A highly scalable operating model separates ownership into four distinct forms: legal/policy, process/financial-control, technology/service, and operational execution. The core principle is that “Tax owns the legal meaning, Finance owns the business process, IT owns the enabling service, and Operations owns execution – but the taxable person retains ultimate accountability.” Scalability stems from effectively governing the hand-offs and shared outcomes rather than centralizing all responsibility in one function. The optimal approach is a “federated operating model” – a globally governed core complemented by parameterized country-specific variants.

Ignoring these governance principles leads to significant risks, including recurring emergencies with each new mandate, duplicated local solutions, and an inability to adapt to the rapidly evolving digital compliance landscape, reinforced by initiatives like the EU’s VAT in the Digital Age (ViDA) package.

2. The Nature and Complexity of E-Invoicing & E-Reporting

E-invoicing and e-reporting fundamentally shift compliance “upstream into the transaction itself,” requiring the generation, validation, transmission, and reconciliation of invoices within tight legal deadlines. This process touches numerous functions and systems, including order management, master data, ERPs, tax engines, middleware, and external platforms.

Beyond Siloed Functions: “No single function controls this chain. Tax can define a rule but cannot deploy an interface. IT can keep an interface available but cannot decide whether a triangular transaction is exempt… Finance can own the invoice process but may not interpret national CIUS rules.” Effective governance must explicitly manage these interdependencies.
Elevated Risk Profile: Digital compliance makes defects “externally visible much earlier.” Errors in VAT codes, missing endpoints, or failed acknowledgements are no longer internal issues but can halt billing, delay cash, jeopardize input tax recovery, or cause “mass rejection events.”
Regulatory Imperative: The European Union’s ViDA package mandates e-invoicing for cross-border B2B transactions from July 1, 2030, and domestic system convergence by January 1, 2035, underscoring the urgency of robust governance.

3. Core Principles of a Scalable Operating Model

The foundation of a scalable model rests on clear allocation of accountability and a federated approach:

Outcome-Based Ownership: Ownership must be “assigned by outcome and decision, not by system, department label or project phase.”
The Federated Model: This approach avoids the pitfalls of both full centralization and unrestricted local autonomy. It involves:
A global common core for capabilities like data extraction, validation, status management, monitoring, archiving, and controls.
Parameterized country variants for specific local requirements, with deviations requiring explicit legal reasons, ownership, and testing evidence.
This limits integration debt and makes multi-country rollouts repeatable, ensuring “Everything that can be common is common; everything that must be local is explicit, approved and observable.”
Go-Live is the Beginning: A program does not end at go-live. “Permanent product ownership, regulatory change governance, controls monitoring and root-cause management are mandatory.”

4. Four Dimensions of Ownership and Functional Responsibilities

A scalable model distinctly separates four forms of ownership, ensuring clear lines of accountability:

Legal and Policy Ownership (Primarily Tax):

Accountability: Interpreting VAT law, defining policy, scope, tax treatment, mandatory content, timing, corrections, archiving, and risk acceptance. Approves legal position and compliance control objectives.
Responsibilities: Maintaining the global and country requirement inventory, defining tax determination principles, approving mappings and rule interpretations, classifying compliance risk, owning regulatory monitoring, and designing VAT-specific controls.
What Tax should NOT do: “Tax should not become the manual operations desk, own infrastructure uptime, or approve technical releases whose risk is purely operational.” Tax cannot delegate its legal judgment.

End-to-End Process and Financial Control Ownership (Primarily Finance):

Accountability: Owning invoice-to-cash and procure-to-pay processes, ensuring alignment of accounting entries, invoice statuses, and reporting statuses. Accountable for end-to-end performance, including embedded compliance and technology.
Responsibilities: Sponsoring master-data governance, approving financial-control changes, funding operations, and owning business continuity decisions related to billing and cash.

Technology and Service Ownership (Primarily IT):

Accountability: Providing a resilient technology platform, integration, security, monitoring, data movement, and technical change management.
Responsibilities: Owning target architecture, platform availability, monitoring, security, identity, deployment, disaster recovery, and vendor service management. Implementing approved rules under controlled processes and providing “technical observability from source transaction through acknowledgement.”

Operational Execution Ownership (Primarily Shared Services/Business Operations):

Accountability: Executing daily controls and resolving exceptions within defined parameters.
Responsibilities: Monitoring queues, triaging exceptions, applying first-line fixes, escalating unresolved issues, performing reconciliations, and initiating root-cause problem records. Operations should not interpret novel legal questions; “decision trees and escalation paths must distinguish standard fixes from Tax decisions and IT defects.”
Local Teams: Preserve jurisdictional knowledge, language, authority interaction, and sign off on local legal requirements and process feasibility.

5. Governance Bodies, Roles, and Decision Rights

Effective governance requires defined structures and clear decision-making:

Key Governance Bodies: Include an Executive Steering Committee, Global Design Authority, Product/Service Board, Country Readiness Forum, Operational Control Forum, and Major Incident Team.
Permanent Roles: Critical roles like Executive Sponsor, Global Process Owner, Tax Policy Owner, Product Owner, IT Service Owner, Data Owner, Control Owner, Country Owner, Operations Lead, and Vendor Manager must be filled by “named individuals” with defined accountability. “A mailbox, committee or vendor cannot be accountable.”
Beyond RACI: Standard RACI charts are often too coarse. A robust decision-rights matrix must be “built around concrete decisions and deliverables,” specifying who is Accountable (A), Responsible (R), and who requires consultation/sign-off (C). This includes defining who can accept warnings, stop deployments, or decide on actions during authority outages.

6. Lifecycle Governance and Continuous Assurance

E-invoicing demands continuous governance across its lifecycle:

Regulatory Intake: A single, governed process to capture new mandates, including sources, effective dates, scope, fields, timing, and sanctions. Tax owns the legal baseline; the product owner prioritizes delivery.
Impact Assessment & Design: Cross-functional mapping of requirements to processes, data, systems, and controls. Requirements should be “written as testable outcomes.”
Build & Configuration: Version-controlled rules and mappings with traceability to approved requirements. The common core must be protected from unmanaged local customization.
Testing & Acceptance: Comprehensive testing (legal accuracy, schema validation, end-to-end transport, ERP postings, reporting, archive retrieval). Requires sign-off from Tax (legal), Finance (process/accounting), IT (technical/service), and Operations (readiness).
Cutover & Hypercare: Explicit readiness criteria and enhanced monitoring, transitioning to a sustainable BAU model.
Business-as-Usual Product Management: The capability is managed as an enduring product with a single backlog for regulatory changes, defects, and improvements.

7. Controls, Reconciliation, and Data Governance

Robust internal controls and data quality are paramount:

Control Ownership: A control owner is accountable for its design, performance criteria, and remediation, even if operations execute it. Minimum control domains include scope completeness, master data, tax determination, transmission, reporting, corrections, access/change, retention, and resilience.
Three Essential Reconciliations: A mature model reconciles “what the ERP says was issued or received; what the network or authority accepted, rejected or left pending; and what was posted and reported.”
Evidence by Design: Automatic generation of evidence is crucial, including approvals, mapping versions, test results, structured invoices, acknowledgements, timestamps, and incident decisions.
Data Governance: Critical data fields (VAT IDs, addresses, payment details) need “a business owner, system of record, steward, validation rule, permitted override, quality metric and remediation route.” Reject rates are data-quality signals; the goal is “fix once at source.”

8. Vendor and Platform Governance

While vendors can perform services, legal accountability remains with the taxable person:

Outsourcing Limits: A provider can handle conversion, validation, routing, or archiving, but “The provider handles it” is not an operating model. The organization retains accountability for tax treatment, source data, scope, and statutory obligations.
Contract Requirements: Contracts must specify clear scope, SLAs linked to legal deadlines, access to acknowledgements and raw responses, change management, security, data ownership, and exit provisions.
Multi-Vendor Accountability: If multiple vendors are involved (ERP, tax engine, e-invoicing platform), the enterprise must own the “end-to-end service” with an internal service owner possessing cross-platform observability.

9. Funding, Capacity, and Maturity Model

Funding: Distinguish between foundational global platform costs and incremental country deployment costs to avoid duplication or unfunded central capacity.
Capacity: Plan scarce resources (Tax, architecture, testing) across a multi-year roadmap, using a portfolio board to manage collisions and sequencing.
Maturity: Progression from reactive local projects (Level 1) to an adaptive model with predictive monitoring and continuous improvement (Level 5).

10. Common Anti-Patterns and Corrections

Several common pitfalls can undermine e-invoicing success:

“Tax owns it” / “IT owns it”: Fails due to lack of control over process/data or conflation of technical success with legal/reporting correctness. Correction: Define explicit, complementary accountabilities for Tax (legal policy), Finance (process), and IT (service).
“The vendor is accountable”: Fails because contracted services don’t transfer statutory responsibility. Correction: Retain internal process, Tax, and service owners; govern vendor evidence and exit.
Country-by-country projects: Leads to duplication and inconsistent controls. Correction: Use a common core, rollout factory, and governed local variants.
Project ends at go-live: No owner for ongoing releases, controls, or regulatory changes. Correction: Create permanent product, service, and control ownership.
RACI without thresholds: Labels without concrete decision authority. Correction: Add decisions, named approvers, risk limits, and escalation paths.

11. Conclusion

The question of who “owns e-invoicing” is complex, with no single-function answer. Instead, it demands a robust, integrated governance framework where Tax defines legal meaning, Finance owns the business process, IT ensures technical service, and Operations executes controls. The ultimate accountability always rests with the taxable person.

By adopting a federated operating model with a global core, explicit local variants, clear decision rights, durable product ownership, integrated controls, end-to-end evidence, and disciplined escalation, organizations can transform e-invoicing and e-reporting from a series of “separate emergency” mandates into continuously managed and governed releases.

12. References and Further Resources

“E-Invoicing Governance: Building a Scalable Operating Model” (Source document)
VATupdate.com: An essential resource for staying abreast of global VAT and customs regulations, including e-invoicing mandates, e-reporting rules, and cross-border compliance. (Cited source: “New Note”)
European Commission – VAT in the Digital Age (ViDA)
Council Directive 2006/112/EC (VAT Directive)

Executive summary

E-invoicing and e-reporting are not standalone Tax projects and not merely IT integrations. They are enterprise transaction controls that sit on the critical path for billing, cash collection, customer acceptance, supplier payment, VAT reporting and audit evidence. The central governance challenge is therefore not deciding whether Tax, IT or Finance “owns e-invoicing” in the abstract. It is allocating accountability for each outcome, decision, control and exception across the end-to-end process.

A scalable operating model separates four forms of ownership: legal and policy accountability; process and financial-control ownership; technology and service ownership; and operational execution. Tax should remain accountable for VAT interpretation and the compliance control framework. Finance should own the end-to-end invoice processes and their business outcomes. IT should own the resilient technology platform, integrations, security and technical change. Shared services or business operations should execute daily controls and exception resolution. Local teams preserve jurisdictional knowledge and legal accountability, while a global design authority governs the common core.

The model fails when accountability is transferred to a vendor, when every country builds its own solution, when a programme ends at go-live, or when RACI charts describe functions but do not identify decisions, evidence, service levels and escalation rights. The correct target is a federated operating model: a globally governed core, parameterised country variants, explicit control ownership, durable product management and measurable assurance.

Central thesis. Tax owns the legal meaning, Finance owns the business process, IT owns the enabling service, and Operations owns execution – but the taxable person retains ultimate accountability. Scalability comes from governing the hand-offs and shared outcomes, not from declaring one function the single owner of everything.

Key messages

Ownership must be assigned by outcome and decision, not by system, department label or project phase.
Finance is the natural end-to-end process owner because invoice flows govern revenue, receivables, payables, close and working capital; Tax defines the VAT rules and compliance controls embedded in that process.
IT is accountable for availability, integration, security, observability, data movement and technical release management, but cannot determine tax treatment or accept legal risk on behalf of the business.
A provider may operate a platform or access point, but outsourcing execution does not outsource the taxable person’s legal accountability.
A scalable model uses a global common core with controlled local variants, one demand backlog, one design authority, standard evidence, common KPIs and country-specific legal sign-off.
Go-live is the start of operations. Permanent product ownership, regulatory change governance, controls monitoring and root-cause management are mandatory.
RACI is useful only when supplemented by decision rights, service levels, evidence requirements, escalation paths and named accountable individuals.

1. Why governance is the decisive capability

1.1 E-invoicing crosses organisational boundaries

A conventional VAT return process may be concentrated in Tax or Finance after transactions have posted. E-invoicing and digital reporting move compliance upstream into the transaction itself. The invoice may need to be generated in a prescribed structured format, validated, transmitted or cleared, acknowledged, archived and reconciled within a short legal deadline. The process touches order management, customer and vendor master data, ERP tax determination, billing, accounts receivable, accounts payable, integration middleware, identity and certificates, external platforms, reporting engines and records retention.

No single function controls this chain. Tax can define a rule but cannot deploy an interface. IT can keep an interface available but cannot decide whether a triangular transaction is exempt, reverse charged or locally taxable. Finance can own the invoice process but may not interpret national CIUS rules. A scalable model therefore governs dependencies explicitly instead of pretending they do not exist.

1.2 Digital compliance changes the risk profile

When invoice data is transmitted to a customer, network or tax authority at or near transaction time, defects become externally visible much earlier. A wrong VAT code, missing endpoint, expired certificate or failed acknowledgement is no longer merely an internal accounting correction. It may stop billing, delay cash, jeopardise input tax recovery, create reporting inconsistencies or produce a mass rejection event. The European Union’s VAT in the Digital Age package reinforces this direction through e-invoicing-based digital reporting for cross-border B2B transactions from 1 July 2030 and convergence requirements for domestic systems by 1 January 2035.

Authoritative reference: European Commission – VAT in the Digital Age (ViDA)

1.3 The operating model is itself a control

A good operating model ensures that every legally significant obligation has an accountable owner; every technical service has a service owner; every control produces evidence; every exception has a route and SLA; every local deviation is approved; every regulatory change enters a governed backlog; and every material failure reaches the person authorised to make a risk decision. Governance is not an administrative overlay. It is the mechanism that converts legal requirements into repeatable operational outcomes.

2. Four dimensions of ownership

2.1 Legal and policy ownership

Tax owns the interpretation of VAT law and the policy choices derived from it: scope, tax treatment, mandatory invoice content, timing, corrections, self-billing, currency and exchange-rate rules, archiving requirements, reporting obligations and country-specific risk acceptance. Tax also defines the compliance control objectives and approves the legal position embodied in mappings and business rules. This is accountability for meaning, not responsibility for every configuration activity.

2.2 End-to-end process ownership

Finance should normally own the invoice-to-cash and procure-to-pay processes because it controls the business process, financial posting, receivable or payable, close, reconciliation and working-capital consequence. The process owner is accountable for end-to-end performance, including the points where compliance and technology are embedded. This avoids treating e-invoicing as a sidecar that is “finished” once a document leaves the ERP.

2.3 Technology and service ownership

IT owns architecture, integration, platform availability, monitoring, security, identity, certificates, environments, deployment, technical testing, disaster recovery and vendor service management. Where there is a dedicated Tax Technology function, it can translate between legal requirements and technical implementation, but its mandate must be explicit: it may act as product owner, solution owner or rule-configuration owner without displacing Tax’s legal accountability or Finance’s process accountability.

2.4 Operational execution ownership

Shared services, accounts receivable, accounts payable, billing operations or specialised compliance operations execute the daily process. They monitor acknowledgements, triage exceptions, correct permitted data, coordinate customer or supplier follow-up, trigger reprocessing, preserve evidence and escalate unresolved or material issues. Operations should not be asked to interpret novel legal questions during a production incident; decision trees and escalation paths must distinguish standard fixes from Tax decisions and IT defects.

Ownership dimension	Primary accountable function	Typical evidence
Legal / policy	Tax	Legal requirement register, tax policy, country sign-off, control objectives
Process / financial outcome	Finance process owner	Process design, control performance, reconciliation, KPI ownership
Technology / service	IT or designated platform owner	Architecture, SLA, monitoring, release and recovery evidence
Execution	GBS / SSC / business operations	Queue management, runbooks, case records, SLA performance
Local statutory accountability	Local Tax / Finance leadership	Local approval, filing or statutory evidence, risk escalation

3. What each function should own

3.1 Tax responsibilities

Maintain the global and country requirement inventory, including effective dates, scope, transaction types, data fields, deadlines, corrections and retention.
Define VAT policy, tax determination principles, invoice content rules and legal control objectives.
Approve tax mappings, rule interpretations and country deviations; document assumptions and open legal questions.
Classify compliance risk and determine when an incident requires disclosure, correction, authority contact or formal risk acceptance.
Own regulatory monitoring and translate legal change into testable business requirements.
Approve compliance acceptance criteria and evidence that the implemented process meets them.
Design and monitor VAT-specific controls, including completeness, accuracy, timeliness and invoice-to-report reconciliation.
Provide second-line expertise for complex exceptions and recurring root causes.

Tax should not become the manual operations desk, own infrastructure uptime, or approve technical releases whose risk is purely operational. Equally, Tax cannot delegate its legal judgement to IT or a provider simply because rules are coded in their systems.

3.2 Finance responsibilities

Own invoice-to-cash and procure-to-pay process design and performance from business event through posting, settlement and reconciliation.
Ensure accounting entries, invoice statuses and reporting statuses remain aligned and that revenue, receivables, payables and close are not driven by false technical statuses.
Own customer and supplier experience for rejections, disputed documents and communication channels.
Operate or sponsor master-data governance for legal names, addresses, VAT IDs, endpoints, payment details and transaction attributes.
Approve financial-control changes, segregation of duties, posting logic and operational procedures.
Fund and resource business operations, exception management and month-end controls.
Own business continuity decisions affecting billing, cash collection, supplier payment and close, with Tax and IT input.

3.3 IT responsibilities

Own the target architecture and integration standards across ERP, tax engine, middleware, e-invoicing platform, authority interfaces, archive and analytics.
Provide resilient services with monitoring, alerting, capacity management, certificate management, backup, recovery and disaster-recovery testing.
Implement approved mappings and rules under controlled software-development and release processes.
Maintain environments, access controls, security, privacy, logging and technical evidence.
Operate incident, problem, change and configuration management; distinguish defects from legal or data issues.
Manage providers against contracts, SLAs, service credits, security obligations, exit plans and data portability.
Provide technical observability from source transaction through acknowledgement, not only platform uptime.

3.4 Shared services and business operations responsibilities

Monitor outbound and inbound queues, acknowledgements, rejects, warnings, ageing and unprocessed backlogs.
Apply approved first-line fixes and reprocess safely without creating duplicates.
Follow runbooks and decision trees; preserve the original document, response and correction history.
Escalate within defined severity and legal-deadline thresholds.
Perform daily and period-end reconciliations and certify completion.
Aggregate repeat failures and initiate root-cause problem records rather than repeatedly repairing individual documents.
Maintain operational knowledge, coverage, training and segregation of duties.

3.5 Local teams and global teams

Global ownership brings standards, leverage and visibility; local ownership brings statutory knowledge, language, authority interaction and business context. A federated split works best: the global team owns the common architecture, methodology, control baseline, data model, provider strategy and portfolio; local Tax validates legal requirements and signs off local compliance; local Finance confirms process feasibility and statutory accounting impacts; global operations execute standard work where possible; and local teams retain only those activities that legally or practically cannot be centralised.

4. The target scalable operating model

4.1 A federated model: global core, governed local variants

The practical target is neither full centralisation nor unrestricted country autonomy. It is a federated model in which one global core covers common capabilities – source extraction, canonical data model, validation orchestration, status model, monitoring, archiving, reconciliation and controls – while country requirements are implemented as parameterised, version-controlled variants. Local deviations must state the legal reason, owner, effective date, test evidence and retirement condition.

This approach limits integration debt and makes multi-country rollout repeatable. It also prevents “global standard” from becoming an excuse to ignore mandatory local rules. Everything that can be common is common; everything that must be local is explicit, approved and observable.

4.2 Governance bodies

Body	Purpose	Core membership	Cadence
Executive steering committee	Set strategy, funding, risk appetite and resolve cross-functional conflicts	CFO sponsor, Tax leader, CIO/IT leader, GBS leader, business representatives	Quarterly and ad hoc for critical risk
Global design authority	Approve architecture, process standards, data model, controls and local deviations	Tax, Finance process owners, IT architecture, Tax Technology, Security, Data	Biweekly during rollout; monthly in BAU
Product / service board	Prioritise backlog, releases, capacity, technical debt and service improvements	Product owner, service owner, Tax policy, operations, provider	Monthly
Country readiness forum	Track requirements, decisions, testing, cutover and local sign-off	Country Tax/Finance, global rollout lead, IT, operations	Weekly per deployment wave
Operational control forum	Review KPI, exceptions, reconciliations, incidents and root causes	Operations, Tax controls, Finance, IT service management	Weekly / monthly
Major incident team	Restore service and manage legal/business exposure	Incident commander, IT, Operations, Tax, Finance, Communications	Event-driven

4.3 Permanent roles

Role	Accountability
Executive sponsor	Enterprise outcome, funding and conflict resolution
Global process owner	End-to-end invoice process performance and control
Tax policy owner	Legal interpretation, requirement baseline and compliance risk
Product owner	Prioritised roadmap and value/risk trade-offs across functions
IT service owner	Availability, capacity, resilience, security and provider performance
Data owner / steward	Quality rules and remediation for critical data domains
Control owner	Design and effectiveness of a named control
Country owner	Local requirement validation, readiness and statutory sign-off
Operations lead	Daily execution, staffing, runbooks and SLA delivery
Vendor manager	Commercial, service, risk, change and exit governance

Named individuals should occupy these roles. A mailbox, committee or vendor cannot be accountable. Deputies, succession and minimum coverage must be defined for critical roles.

5. Decision rights: beyond a generic RACI

5.1 Why ordinary RACI charts fail

Many programmes create a high-level RACI in which Tax is “consulted,” IT is “responsible” and Finance is “accountable.” This is too coarse to guide real decisions. It does not tell teams who approves a tax mapping, who may accept a warning, who can stop deployment, who owns an expired certificate, who decides whether invoices may be issued during an authority outage, or who informs customers. The matrix must be built around concrete decisions and deliverables.

5.2 Illustrative decision-rights matrix

Decision / deliverable	A	R	C / required sign-off
Interpret legal mandate and scope	Tax policy owner	Country Tax	Finance, Legal, Tax Technology
Approve end-to-end process design	Global process owner	Finance transformation / GBS	Tax, IT, business
Approve target architecture	IT architecture owner	Solution architect	Tax Technology, Security, Finance
Approve canonical data model	Data owner	Data / integration team	Tax, Finance, IT
Approve tax mapping and rules	Tax policy owner	Tax Technology / configuration team	Country Tax, Finance
Approve local deviation	Global design authority	Country owner	Tax, Finance, IT architecture
Release to production	Product owner / service owner per policy	IT release manager	Tax and Finance acceptance owners
Operate exception queue	Operations lead	AR/AP or compliance operations	Tax, IT support
Accept temporary compliance risk	Authorised Tax / Finance executive	Risk owner	Legal, IT, country leadership
Declare major incident	IT incident commander or process owner	Incident team	Tax, Finance, Communications
Submit correction / disclosure	Country Tax owner	Tax compliance team	Finance, Legal
Approve provider change	Service owner	Vendor manager	Tax, Procurement, Security, Finance

A = Accountable; R = Responsible. The organisation should add exact names, thresholds and delegates. Where law imposes local statutory responsibility, global governance must not obscure the local accountable person.

6. Lifecycle governance: from law to production

6.1 Regulatory intake

Every new or amended mandate should enter one governed intake process. The requirement record should capture authoritative source, publication and effective dates, legal status, affected entities and transactions, invoice and reporting obligations, fields, codes, timing, correction process, fallback, retention, sanctions, open questions and dependency on secondary guidance. Tax owns the legal baseline; the product owner owns entry into the delivery portfolio.

6.2 Impact assessment and design

A cross-functional impact assessment maps each requirement to process, data, systems, controls, customers, suppliers, entities and countries. Requirements should be written as testable outcomes rather than copied legal prose. For example: “For affected intra-EU supplies, the system records the legal invoice issue timestamp and makes the required transaction data available for reporting within the statutory deadline, with evidence of submission and response.”

6.3 Build and configuration

Rules, mappings and workflows must be version controlled. Configuration changes require traceability to approved requirements and test cases. The common core should be protected from unmanaged local customisation. Emergency changes require retrospective review and should not bypass the duty to preserve legal and technical evidence.

6.4 Testing and acceptance

Testing should cover legal rule accuracy, schema and semantic validation, national rules, end-to-end transport, acknowledgements, ERP postings, reporting, archive retrieval, roles and access, performance, negative scenarios, duplicate prevention, failover and high-volume reconciliation. Tax signs legal acceptance; Finance signs process and accounting acceptance; IT signs technical and service acceptance; Operations signs runbook and support readiness. No single approval substitutes for the others.

6.5 Cutover and hypercare

Country go-live requires explicit readiness criteria: production credentials, endpoint registration, certificates, master data, opening backlog treatment, support coverage, legal fallback, customer/supplier communication, monitoring, reconciliations and rollback decision rights. Hypercare should have enhanced thresholds and daily cross-functional review, but it should transition into a sustainable BAU model rather than depend indefinitely on project experts.

6.6 Business-as-usual product management

The capability should be managed as an enduring product and service. A single backlog should include regulatory changes, defects, control gaps, new countries, vendor releases, technical debt, performance improvements and user needs. Prioritisation should consider legal deadline, compliance exposure, business interruption, transaction volume, customer impact, dependency and effort. This replaces the recurring cycle of urgent country projects followed by abandoned solutions.

7. Controls and assurance governance

7.1 Control ownership is not the same as task execution

The control owner is accountable for the design, performance criteria, evidence, deficiencies and remediation of a control. The operator may execute it. For example, Operations may run a daily rejected-invoice report, while Finance owns the end-to-end completeness control and Tax owns the legal timeliness threshold. The documentation must state which risk the control addresses and what happens when it fails.

7.2 Minimum control domains

Control domain	Illustrative control objective	Likely owner
Scope completeness	All in-scope entities, transactions and channels are identified and processed	Tax / global process owner
Master data	Critical VAT, legal-entity and routing data is valid before use	Finance data owner
Tax determination	Tax treatment and invoice content reflect approved policy	Tax
Generation and validation	Structured documents meet syntax, semantic and national rules	Product / IT with Tax criteria
Transmission and acknowledgement	Every sent document reaches a terminal monitored status	IT service owner / Operations
Reporting completeness	Issued, cleared, posted and reported populations reconcile	Finance and Tax
Corrections and duplicates	Corrections are lawful, traceable and do not create duplicates	Finance / Tax
Access and change	Only authorised changes reach production with required approvals	IT
Retention and audit trail	Original data, document, responses and changes are retrievable	IT records owner / Tax
Resilience	Outages are detected, managed and recovered within legal/business limits	IT and process owner

7.3 The three reconciliations that prevent false assurance

A mature model reconciles at least three populations: what the ERP says was issued or received; what the network or authority accepted, rejected or left pending; and what was posted and reported. A platform dashboard showing “success” is not enough. Differences must be explained by status and aged to resolution. The same logic applies inbound: received structured invoices, AP postings, blocked items and deducted input VAT must be connectable.

7.4 Evidence by design

Evidence should be generated automatically wherever possible: requirement approvals, mapping versions, test results, release records, original structured invoice, technical and authority acknowledgements, timestamps, exception history, correction links, reconciliation results, control sign-offs and incident decisions. Article 233 of the VAT Directive requires authenticity of origin, integrity of content and legibility to be ensured from issue until the end of retention; governance should identify how the organisation demonstrates those properties throughout the lifecycle.

Legal reference: Council Directive 2006/112/EC (VAT Directive)

8. Exception, incident and problem ownership

8.1 Classify before assigning

Exceptions should be classified by cause and consequence: data, tax determination, mapping, semantic rule, routing, platform, certificate, authority, customer/supplier, posting, reporting or reconciliation. Severity should reflect legal deadline, number and value of transactions, jurisdictions, customer or supplier impact, cash exposure, recoverability and evidence loss. Correct classification determines the fix owner and prevents every issue being sent to Tax or IT by default.

8.2 Three levels of work

Incident: restore or protect the current flow. Owned under service and business-continuity procedures.
Exception case: resolve a specific document or transaction under an approved workflow.
Problem: eliminate a recurring root cause through data, process, configuration or architecture change.

Closing individual cases while leaving the structural cause open creates false performance. Governance should report both case closure and root-cause elimination, with recurring issues remaining visible until preventive remediation is effective.

8.3 Major incident command

A major incident needs one incident commander, one business-process lead and one Tax risk lead. IT coordinates restoration; Finance assesses billing, cash, payment and close; Tax assesses legal deadlines, fallback, correction and authority implications; Communications manages consistent messages; the executive risk owner decides on extraordinary workarounds or temporary risk acceptance. Every material decision should record time, facts, options, owner and rationale.

9. Data governance: the hidden ownership layer

9.1 Data fields need owners

Structured invoicing exposes deficiencies that PDFs and manual processes can hide. Legal entity names, VAT identifiers, addresses, buyer references, endpoint identifiers, unit codes, exemption reasons, payment data and supply attributes must be accurate and consistently sourced. Each critical element needs a business owner, system of record, steward, validation rule, permitted override, quality metric and remediation route.

9.2 The canonical data model

A canonical invoice data model decouples source systems from multiple country formats and networks. Tax defines the legal semantics; Finance confirms business meaning and source; Data/IT defines technical representation, lineage and transformations. Country syntax mappings are then controlled projections of the canonical model rather than independent interpretations constructed by each provider or local project.

9.3 Data-quality accountability

Reject rates should not be treated only as operational metrics. They are data-quality signals. Governance should assign recurring failures to the domain that can fix the source – customer master, supplier master, material master, tax determination, order entry or mapping. The target is “fix once at source,” not “repair every invoice downstream.”

10. Vendor and platform governance

10.1 What can and cannot be outsourced

A provider can perform format conversion, validations, routing, clearance connectivity, certificate operations, archive services, monitoring or first-line support. The organisation may allocate contractual responsibility for those services, but it retains accountability for correct tax treatment, complete source data, legal scope, timely action on rejections and statutory obligations. “The provider handles it” is not an operating model.

10.2 Contract and service requirements

Clear service scope by country, document type and channel; no ambiguous “compliance” promise.
Availability, response and resolution SLAs linked to legal and business deadlines.
End-to-end status and acknowledgement access, including raw responses and timestamps.
Change-notice periods, release calendars, regression testing and backward compatibility.
Security, privacy, subprocessor, data-location and audit rights.
Business continuity, capacity, incident communication and disaster-recovery evidence.
Data ownership, export, retention, deletion, interoperability and exit assistance.
Liability and escalation provisions proportionate to business and compliance exposure.

10.3 Multi-vendor accountability

Where ERP integrator, tax engine, middleware provider, e-invoicing platform, access point and archive are separate, the enterprise must own the end-to-end service. Individual vendors will otherwise show that their component worked while the invoice remains unresolved. An internal service owner needs cross-platform observability, joint incident procedures, correlation identifiers and authority to convene suppliers.

11. KPIs, KRIs and operating reviews

11.1 Measure outcomes, not activity

Dimension	Illustrative measure
Compliance	Percentage issued/reported within legal deadline; unresolved legal breaches; correction timeliness
Completeness	ERP-to-platform and platform-to-report reconciliation differences
Quality	First-time acceptance rate; warning rate; recurring rejection rate by root cause
Operations	Exception backlog and ageing; mean time to resolve; SLA breaches; rework volume
Service	Availability; latency; failed transmissions; certificate incidents; recovery performance
Data	Critical-field defect rate; invalid VAT IDs/endpoints; source-domain recurrence
Change	On-time regulatory releases; escaped defects; emergency changes; test coverage
Business	Billing delay; cash or payment impact; customer/supplier complaints
Control	Control completion and effectiveness; open deficiencies; overdue remediation

11.2 Avoid misleading green dashboards

Averages can conceal material failures. A 99.9% acceptance rate may still leave thousands of invoices unresolved. Governance should view absolute volumes, country and entity breakdown, maximum ageing, high-value items, legal-deadline breaches and repeat causes. Status definitions must be common: generated, validated, sent, delivered, accepted, cleared, posted, reported, reconciled and archived are different states.

11.3 Review rhythm

Daily operations should focus on queues, deadlines and incidents. Weekly reviews should focus on ageing, recurring causes and planned fixes. Monthly control reviews should certify reconciliations, controls, service and country compliance. Quarterly steering should address strategy, portfolio, vendor performance, risk appetite, resilience and investment. The same data should roll upward without being reinterpreted at each layer.

12. Funding and capacity model

12.1 Separate foundational and country costs

The funding model should distinguish the shared global platform and operating capability from incremental country deployment. Otherwise, early countries bear the cost of reusable foundations or later countries create duplicate local solutions because central capacity is unfunded. Run costs must include licences, infrastructure, provider charges, monitoring, archive, support, regulatory change, controls and continuous improvement – not only implementation.

12.2 Capacity should follow the mandate portfolio

A rolling multi-year roadmap should combine mandate deadlines, ERP transformations, provider changes and internal release freezes. Scarce Tax, architecture, testing and data resources must be planned across countries. The portfolio board should expose collisions early and make explicit risk-based sequencing decisions rather than allowing each country to escalate independently.

13. Common anti-patterns and their correction

Anti-pattern	Why it fails	Correction
“Tax owns it”	Tax lacks control of process, data and technology capacity	Tax owns legal policy; Finance and IT take explicit process/service accountability
“IT owns it”	Technical success is mistaken for legal and reporting correctness	Define Tax acceptance and Finance process controls alongside IT service ownership
“The vendor is accountable”	Contracted service does not transfer statutory responsibility	Retain internal process, Tax and service owners; govern provider evidence and exit
Country-by-country projects	Creates duplicated integrations, inconsistent controls and support debt	Use common core, rollout factory and governed local variants
One global template with no deviations	Ignores mandatory national rules and operating realities	Parameterise and approve justified local variations
Project ends at go-live	No owner for releases, controls, incidents or legal change	Create permanent product, service and control ownership before launch
RACI without thresholds	Teams know labels but not who may decide under pressure	Add decisions, named approvers, risk limits, SLAs and escalation paths
Manual spreadsheet reconciliation	Does not scale and weakens evidence	Automate population matching, status lineage and exception workflows
Fixing rejected invoices one by one	Backlog clears but root cause remains	Open problem records and assign source-domain remediation
Platform “green” equals compliant	Only one component or status is visible	Reconcile ERP, platform/authority, accounting and reporting outcomes

14. Implementation roadmap

14.1 Phase 1 – Diagnose and mobilise

Map current countries, entities, channels, systems, providers, volumes and mandate dates.
Identify accountable people for Tax policy, Finance process, IT service, data and operations.
Assess control, reconciliation, exception, resilience and vendor gaps.
Create one enterprise risk statement and secure executive sponsorship.
Establish interim governance for imminent mandates while the target model is built.

14.2 Phase 2 – Design the target model

Define global principles, operating-model layers and decision rights.
Establish design authority, product board, control forum and incident governance.
Design the common process, canonical data model, status taxonomy, control baseline and evidence model.
Define global-versus-local responsibilities and deviation governance.
Agree service catalogue, support tiers, SLAs, KPIs and risk thresholds.

14.3 Phase 3 – Build the platform and rollout factory

Implement reusable integrations, validation, monitoring, archive and reconciliation components.
Create standard requirement, design, test, cutover, sign-off and runbook templates.
Establish country-wave planning and readiness gates.
Contract or remediate providers and implement end-to-end service monitoring.
Train Tax, Finance, IT and Operations on shared concepts and escalation.

14.4 Phase 4 – Transition to BAU and assure

Transfer ownership from project leads to permanent role holders before hypercare ends.
Run control certification, service reviews, maturity assessments and resilience tests.
Maintain the mandate backlog and deploy controlled regulatory releases.
Use root-cause analytics to reduce recurring exceptions and manual work.
Review the operating model annually or after material incidents and reorganisations.

15. Maturity model

Level	Characteristics	Priority
1. Reactive	Local projects, unclear ownership, manual fixes, vendor dependence	Stabilise critical countries and name owners
2. Coordinated	Cross-functional projects and basic RACI, but fragmented technology and controls	Standardise governance, status and evidence
3. Standardised	Global core, controlled variants, common controls, defined service and operations	Automate reconciliation and root-cause management
4. Managed	Product model, measurable SLAs/KPIs, integrated change and control assurance	Optimise data quality, resilience and portfolio capacity
5. Adaptive	Predictive monitoring, reusable country deployments, continuous control and policy-to-code traceability	Continuously improve and exploit trusted data

16. Practical governance checklist

Is there one named global process owner for outbound and inbound invoice flows?
Is Tax accountable for legal interpretation and compliance acceptance criteria?
Is there one IT service owner with end-to-end observability across vendors?
Are critical invoice data fields assigned to named data owners and stewards?
Does each country have a Tax and Finance sign-off owner?
Are global standards and local deviations documented and version controlled?
Do decision rights identify who can stop a release, accept risk and invoke fallback?
Are acknowledgements, corrections and reporting statuses reconciled to ERP populations?
Are exception SLAs tied to legal deadlines and business impact?
Are recurring exceptions converted into owned root-cause problems?
Are provider obligations measurable and is an exit/data portability plan tested?
Are product funding and regulatory-change capacity permanent rather than project-only?
Are business continuity scenarios tested jointly by Tax, Finance, IT and Operations?
Can the organisation produce a complete evidence chain for a sample invoice?
Does executive governance receive absolute backlog, ageing and breach data rather than only percentages?

17. Conclusion

The question “Does Tax, IT or Finance own e-invoicing?” has no useful one-word answer. Tax owns the legal meaning and compliance framework. Finance owns the business process and its financial outcomes. IT owns the technology service and resilience. Operations owns controlled execution. Data owners, local teams and providers each have defined parts. The enterprise – and ultimately the taxable person – remains accountable for the combined result.

The scalable solution is to make these accountabilities complementary rather than competitive: one global common core, explicit country variants, named decision rights, durable product and service ownership, integrated controls, end-to-end evidence and disciplined escalation. Organisations that build this operating model can absorb new mandates as governed releases. Those that do not will continue to experience each mandate as a separate emergency.

18. Authoritative and practical references