Is ViDA only an e-invoice format change?

No. ViDA introduces a real-time digital reporting model based on e-invoicing for cross-border B2B transactions, while national mandates such as France and Germany already change domestic invoice operating flows.

What should finance teams implement first?

Receiving readiness, master-data cleansing, and one canonical invoice event model should come before platform-specific connector work.

ViDA e-invoicing is not a format change. It is an ERP tax control system.

The thesis: e-invoicing moves the control point upstream.

The old ERP control model assumed the invoice document could arrive messily and finance would clean it up before posting, paying, reporting, or auditing it. That model breaks when tax administrations expect structured invoice data and platform acknowledgements close to the transaction event.

The European Commission says the ViDA package was adopted on March 11, 2025, entered into force on April 14, 2025, and will roll out progressively through January 2035. The key finance-ops date is earlier than 2030 for many companies because national mandates are already live or scheduled. France requires all companies in scope to receive e-invoices from September 1, 2026. Germany already removed paper-invoice priority from January 1, 2025 and phases mandatory B2B issuance into 2027 and 2028.

That makes e-invoicing an ERP tax control project. It touches customer master, supplier master, AR billing, AP intake, approval workflows, VAT reporting, subledger posting, payment timing, platform exception management, and audit evidence. The format matters. It is not the main event.

What changed, exactly.

ViDA creates an EU-level direction of travel: real-time digital reporting for cross-border B2B trade based on e-invoicing from July 1, 2030, with domestic real-time reporting systems converging by January 1, 2035. The Commission’s 2026 work programme is more concrete: it plans implementing regulations for the common electronic message and central VIES design work in 2026, with explanatory notes and stakeholder consultations during the year.

France is the immediate operational forcing function. The public-service timetable says the obligation to receive electronic invoices applies to all companies from September 1, 2026. Large and mid-sized companies must issue from the same date; SMEs and micro-companies follow for issuance from September 1, 2027. The French reform also uses the same timetable for e-reporting transaction data to the administration.

Germany shows the second pattern: domestic B2B e-invoicing begins as receiving readiness and becomes issuance obligation. The European Commission’s Germany profile states that from January 1, 2027, companies with prior-year annual revenue above 800,000 euros must send B2B e-invoices, and from January 1, 2028, all companies must send B2B e-invoices.

Why “just add a connector” is the wrong architecture.

Real-time VAT compliance works only when platform acknowledgements, tax reporting, and accounting all attach to the same invoice event.

A platform connector can transmit a payload. It cannot decide whether the customer legal unit is valid, whether the invoice should be taxable, whether a rejection should reverse revenue, whether a corrected invoice should reopen AP approval, or whether the VAT report ties to the GL. Those are ERP control decisions.

The practical architecture is one canonical invoice event model, with platform adapters around it. Each country or network can have its own transport and syntax, but finance should not tolerate separate truths for AR, AP, VAT reporting, and accounting. If those states diverge, the month-end close becomes the reconciliation layer for problems that should have been blocked at invoice creation or receipt.

The data model finance actually needs.

A compliant invoice payload is not enough. The ERP needs to retain the normalized business fact that generated the payload, the source document, the tax decision, the platform route, the acknowledgement, the accounting entry, and the reporting hash. Otherwise, the company has a successful transmission but weak evidence.

Example canonical invoice event

{
  "invoice_event_id": "inv_evt_01jz3d8rxv",
  "direction": "outbound",
  "entity_id": "fr_subsidiary",
  "counterparty_tax_id": "FR12345678901",
  "counterparty_legal_id": "siren_123456789",
  "platform_route_id": "pdp_customer_primary_2026",
  "jurisdiction": "FR",
  "invoice_format": "EN16931_CII",
  "invoice_status": "DELIVERED_TO_PLATFORM",
  "tax_point_date": "2026-09-03",
  "amount_minor": 1482500,
  "currency_code": "EUR",
  "vat_breakdown": [
    { "rate": "20.00", "taxable_minor": 1235417, "vat_minor": 247083 }
  ],
  "gl_posting_id": "je_2026_09_003812",
  "vat_report_payload_hash": "sha256:7f8d...",
  "evidence_ref": "s3://tax-evidence/fr/2026-09/inv_evt_01jz3d8rxv/"
}

The important fields are not glamorous: legal entity, counterparty identifier, tax point date, invoice status, route, VAT breakdown, posting reference, payload hash, and evidence location. These are the fields that let finance answer the only question that matters during audit or tax inquiry: exactly what happened to this invoice, when, why, through which system, and with which accounting effect?

Control design for real-time tax operations.

Risk	Control	Evidence
Wrong counterparty identity	Customer and supplier tax identifiers are validated before invoice issue or acceptance.	Tax ID validation log, master-data version, approver, platform directory response.
Invoice stuck outside the ERP	Every inbound and outbound e-invoice has a canonical lifecycle state owned by the ERP.	State transition log, delivery receipt, rejection reason, retry history.
VAT report mismatch	The VAT reporting payload is generated from the same controlled invoice event as the accounting entry.	Invoice event ID, VAT payload hash, GL posting ID, submission acknowledgement.
Platform routing failure	Platform selection and routing IDs are stored as effective-dated master data, not free-text invoice fields.	Routing table version, effective date, supplier/customer mapping, change ticket.
Duplicate invoice after reissue	Replacement, correction, cancellation, and rejection flows preserve a link to the original invoice.	Original invoice ID, correction ID, status chain, credit note or reversal evidence.
Uncontrolled manual fallback	Manual PDF/email fallback requires exception reason, tax owner approval, and later reconciliation to the canonical invoice state.	Exception ticket, approval, uploaded evidence, clearing reconciliation.

The control owner should not be “IT.” Tax owns the VAT treatment. Controllership owns posting and reconciliation. AR and AP own operating exceptions. ERP or integration teams own delivery reliability and idempotency. Internal audit or SOX owns whether the process change materially alters the control environment.

Implementation checklist before France 2026.

Inventory every AR and AP invoice source, including billing tools, subscription systems, procurement portals, intercompany flows, and manual credit-note processes.

Define a canonical invoice event model before choosing connectors, because platform integrations should map into finance truth rather than become separate ledgers.

Add required jurisdiction fields to customer and supplier master data: tax ID, SIREN where relevant, legal-unit status, platform identifier, delivery address, VAT regime, and effective dates.

Build receiving readiness first. France requires all companies to receive e-invoices from September 1, 2026, even if smaller companies issue later.

Separate technical delivery status from accounting status. A delivered invoice is not necessarily posted, approved, deductible, payable, or reportable.

Run parallel invoice dry-runs with real supplier and customer samples, including rejections, corrections, credit notes, partial payments, and invoice-with-VAT-on-debits scenarios.

Tie every reporting payload to an immutable invoice event, not to a month-end spreadsheet extract.

Preserve a complete evidence packet for each invoice: source payload, normalized data, validation results, platform acknowledgements, accounting entry, VAT treatment, and user approvals.

The receiving mandate is the cleanest first milestone because it forces supplier master data, AP intake, exception queues, and document retention to work before the company depends on outbound invoicing for revenue operations. If inbound e-invoices cannot be received, normalized, rejected, corrected, approved, posted, and archived without heroic manual work, outbound will be worse.

Failure modes that will show up in close.

Treating e-invoicing as PDF replacement instead of controlled transaction exchange.

Letting AR, AP, tax, and integration teams each define invoice status differently.

Choosing a platform before cleansing customer and supplier master data.

Posting invoices from one path while reporting VAT from another path.

Ignoring rejected and corrected invoices until month-end close.

Assuming national mandates will converge perfectly by 2030 and postponing a common data contract.

The expensive failure is not that a payload fails validation once. That is visible and fixable. The expensive failure is silent divergence: the tax platform thinks the invoice is rejected, AR thinks it is collectible, the GL has revenue, and the VAT report is built from a manually repaired file. That is a control break disguised as integration debt.

What ERP buyers should ask vendors now.

Does the product maintain one canonical invoice event across AR issue, AP receipt, tax reporting, posting, approval, payment, correction, and audit?

Can the ERP store platform routing and legal-entity identifiers as versioned master data, with effective dates and reviewer evidence?

How does the system model rejection, correction, cancellation, replacement, and credit-note chains without losing the original tax and accounting trail?

Can VAT reporting payloads be generated from the same facts used for GL and subledger posting, or are they built from a separate compliance extract?

What happens when a platform is unavailable, a counterparty has no routing match, or a supplier sends an invoice in a valid but unexpected format?

A credible vendor answer will describe state machines, idempotent events, evidence retention, validation rules, master-data governance, and jurisdiction-specific adapters. An answer centered on “we support the format” is incomplete.

Market signals.

The public conversation around ViDA is useful mostly as a timing signal. Official EU adoption is done, business groups are watching implementation, and national mandates are moving from policy into operating deadlines. These posts are included for context; the article relies on the cited official sources for operative facts.

European Commission Taxation and Customs Union post on ViDA adoption

Public X post: European Commission Taxation and Customs Union post on ViDA adoption.

BusinessEurope post welcoming ViDA adoption

Public X post: BusinessEurope post welcoming ViDA adoption.

Practical takeaway.

ViDA and national e-invoicing mandates are turning invoice processing into a near-real-time tax control surface. The winning finance architecture is not one connector per mandate. It is a canonical invoice event, jurisdiction-aware adapters, clean master data, explicit exception workflows, and evidence that ties platform traffic back to accounting and VAT reporting. Build that layer once, then localize it. Anything else turns every new mandate into a fresh reconciliation project.