A non-EU headquartered multinational expands into multiple European countries. Its group accounting system records sales perfectly well for management purposes: customer, invoice amount, invoice date and payment date are all there.
Then the local accountant asks a different set of questions. Which VAT period does the transaction belong to? What is the customer’s VAT identification number? Which EU member state is involved? Is the transaction domestic, intra-EU or outside the EU? And can the customer-level reporting be reconciled to the VAT return?
The system is not necessarily wrong. It was simply designed to answer a different question. That distinction matters, because many crossborder VAT problems begin long before anyone prepares a tax return.
One transaction, three dates
A single sale can contain at least three relevant dates: the date of supply, the invoice date and the payment date. They are not interchangeable. Under Article 63 of the EU VAT Directive, the general principle is that VAT becomes chargeable when goods or services are supplied, with special rules for areas such as advance payments, continuous supplies and intra-community transactions (ICPs). National implementation then determines how that principle works in practice.
The relevant tax point has to be understood locally
In the Netherlands, for example, businesses using the normal invoice system generally report VAT by reference to the invoice date, while a cash-accounting system applies in qualifying situations. Belgium applies its own rules around the taxable event, invoicing, payment and continuous supplies.
For a group finance team, the lesson is practical rather than theoretical: a global setting that says ‘use invoice date’ or ‘use payment date’ cannot safely be assumed to work for every entity and every transaction. The relevant tax point has to be understood locally.
The missing VAT data
Timing is only the first gap. EU crossborder reporting often requires information that a non-European headquarters system was never built to hold. Article 264 of the EU VAT Directive requires recapitulative reporting to identify the customer’s VAT number in another member state and the value of relevant supplies for that customer. In practice, this means that finance may need a data set that goes beyond the ordinary sales ledger: legal customer, country of VAT registration, VAT ID, transaction type, tax treatment and reporting-period value.
What looks like a tax problem is often a data-design problem
A headquarters ledger may show €100,000 invoiced to ‘Customer A’. For group reporting, that may be enough. For European VAT reporting, it may not be. If those fields are missing, the local team is left reconstructing them from invoices, contracts, emails and customer records at quarter-end. What looks like a tax problem is often a data-design problem.
Build the reconciliation chain
Consider a simplified example based on situations that arise in crossborder finance. A headquarters sales ledger shows €1.2m of quarterly sales. Once the transactions are reviewed for local VAT purposes, €800,000 is domestic, €250,000 relates to intra-EU business-to-business transactions, €100,000 is non-EU and €50,000 is a timing adjustment.
Four checks before filing
- Tax point: are transactions assigned to the correct VAT reporting period under the applicable local rules?
- VAT ID: does every reportable intra-EU customer have the correct VAT identification number and country?
- ICP to VAT: does customer-level recapitulative reporting reconcile to the corresponding amount in the VAT return?
- VAT to general ledger: can VAT turnover be reconciled to the general ledger, with timing and scope differences documented?
The €250,000 intra-EU amount then has to be supported at customer level. It might comprise €120,000 for a German customer, €80,000 for a French customer and €50,000 for a Dutch customer, each linked to the relevant VAT ID.
In the Netherlands, the tax authority describes the ICP declaration as the specification of intra-EU supplies and services reported in box 3b of the VAT return. The customer-level total should therefore reconcile to the corresponding amount in the VAT return. If the return says €250,000 but the ICP declaration file totals €230,000, the €20,000 difference needs to be understood before filing.
Possible explanations include a missing VAT number, the wrong country classification, a credit note, a transaction placed in a different period or an item incorrectly classified as domestic or non-EU.
Reconciliation does not mean equality
The next bridge is from the VAT return to the general ledger and, at year-end, to the financial statements. Here, an important principle is often missed: reconciliation does not mean equality.
VAT turnover and accounting revenue can legitimately differ because of tax-point timing, accruals, deferred income, advance payments, credit notes, foreign exchange, out-of-scope transactions, fixed-asset disposals or year-end adjustments. The control objective is not to force the numbers to match; it is to make the difference explainable. Chart 1 below illustrates the reconciliation requirements.
When the ERP cannot change
The obvious answer might be to add the missing fields to the headquarters ERP. In a multinational group, that is often neither realistic nor proportionate. A local European finance team may have no authority to alter the global customer master or transaction logic.
A practical alternative is a controlled local compliance layer: a VAT master file or local module that enriches the source ledger with VAT IDs, country codes, transaction classifications, local tax points and VAT treatments.
The important issue is not whether every field sits in one system. It is whether the bridge from source data to the statutory return is controlled, reproducible and auditable.
Local advisers remain essential, but group finance still needs ownership of the bridge between the accounting data and what is ultimately filed.
A system can be perfectly correct for group accounting and still be inadequate for local VAT compliance. In crossborder finance, the objective is rarely to make every number identical. It is to make every difference traceable.
