E-invoicing mandates are a master data project wearing a tax label

E-invoicing lands on the plan as a tax deadline. Someone from finance owns it, procurement shortlists a service provider, and IT is asked for a connector and a test window. That framing survives right up until the first batch of structured invoices goes out and a portion of them come back rejected. Then everyone looks at the connector, and the connector is fine.

What failed is a customer record. The buyer VAT identifier is stored without its country prefix. Or the routing address the network needs to deliver the document has never existed as a field in any system you own, so somebody typed it into a note. The mandate is not asking you to send a different file. It is asking you to prove, on every document, that you know precisely who the other party is, in a format a validator can check without a human in the loop. That is a master data requirement with a legal deadline attached, and I have yet to see it budgeted as one.

The mandate is a schema, not a portal

Under the European standard EN 16931, and the Peppol profile most countries have settled on, an invoice is a structured document checked against a rule set before it counts as issued. Not read, not scanned. Validated. In Italy the clearance platform runs hundreds of checks and a rejected invoice that goes uncorrected within five days is treated as never issued at all. In Poland the document only becomes a legal invoice once it has passed validation and been given an identifier back.

Read through those rules and something becomes obvious. Very little of what gets checked is transactional. Amounts and dates come from the order and they are almost always right, because your ERP has spent twenty years making sure of it. The checks that fail are about the counterparty, and the counterparty comes from a record that no validator has ever inspected before.

This is why the failures cluster. One bad customer record does not produce one rejected invoice. It produces every invoice to that customer, rejected the same way, for as long as the record stays wrong. The distribution of errors follows the master data, not the traffic.

The field your ERP does not have

Start with the one that catches almost everybody: the electronic address. Peppol rules PEPPOL-EN16931-R010 and R020 make the buyer and seller electronic addresses mandatory, and rules BR-62 and BR-63 require each of them to carry a scheme identifier. It takes two values: a scheme code drawn from the EU-maintained Electronic Address Scheme list, plus the identifier itself. A participant on the network is written scheme::value, and both halves have to survive the trip from your database to the document.

No ERP customer master built before the mandates has a home for that, because before the mandates there was nothing to route. So it ends up in a free-text remarks field, and the scheme half is the part that gets dropped, because it looks like a technical prefix rather than data. A GLN and a national company number can be the same digits under different schemes and mean different mailboxes. Storing the value without the scheme is storing half a key.

The fix is unglamorous and it is the whole job: two governed attributes on the counterparty record, the scheme constrained to the published code list rather than typed freely, and a validation that refuses one without the other. That is a data quality rule at the point of entry, which is the only place it is cheap.

The VAT number you have is not the one the rule wants

Rule BR-CO-09 says the seller and buyer VAT identifiers must carry a prefix matching the ISO 3166-1 alpha-2 code of the issuing country. So DE123456789, not 123456789. Plenty of ERPs store the digits in one column and the country somewhere else entirely, sometimes derived from the postal address, which is a different country more often than you would like. Rule BR-IC-02 then makes the buyer VAT identifier hard-mandatory on intra-community supplies, which is precisely the scope the EU-wide reporting requirement covers from 2030.

Format is the easy half. The hard half is currency, and this is where VIES gets oversold. VIES will tell you a number is recorded as valid today. It will not tell you whether that number was valid on the eleventh of March, when you issued the invoice an auditor is now asking about. There is no reverse lookup from a company name. Several Member States return no name or address at all, for data protection reasons, so a blank result means nothing either way. And a perfectly valid number proves the number exists, not that it belongs to the entity you are trading with.

So the useful output of VIES is not the answer. It is the record of the answer. Store the outcome and the date you got it on the counterparty as governed attributes, and you can show what you knew and when you knew it. Run the lookup, nod at the green tick, and throw it away, and you have evidence of nothing at all. I would treat any process that calls VIES at transmission time and keeps no result as a control that exists only on the slide.

Data your customer owns and you have to store

Then there is the buyer reference, BT-10. Peppol requires either a buyer reference or a purchase order reference on every invoice. Germany's national profile goes further and requires the buyer reference unconditionally, where it carries the routing code the recipient uses to get the document to the right internal unit.

The value is defined inside your customer's organisation. You cannot derive it, validate it against a public register, or infer it from anything you already hold. Someone has to ask each customer, write the answer down, and keep it current when they reorganise. This is plain stewardship, on a field with a legal deadline, across every customer you invoice in a mandated country. Teams that find this in the test window have already lost, because the bottleneck was never the typing. It is the response time of a few hundred customers who have their own deadlines.

The deadlines, roughly

These move, and the detail differs by country and by turnover band, so check the current position for the jurisdictions you actually invoice into. The shape of it is what matters here.

Spain has its own regime coming and the clock has not formally started at the time of writing. Romania and several others are already live. The direction is one way, and the 2030 EU requirement pulls every domestic scheme onto the same standard in the end. That part works in your favour: the counterparty fields you clean up for one mandate are the fields the next one asks for.

Where to put the work

The instinct is to solve it in the middleware, because the middleware is where the error message appeared. Map a little, enrich on the way out. It works for a quarter. Then the same customer needs the same patch in a second interface, the two drift apart, and now the invoice and the payment file disagree about who the customer is.

The compliance fields belong on the governed counterparty record, upstream of everything that consumes it. Four things make the difference, and none of them are exotic:

Give the electronic address and its scheme code real, typed attributes, with the scheme constrained to the published list. Validate VAT identifiers for the country prefix and format on entry, rather than at transmission. Capture the buyer reference per customer and start asking now, because that queue is measured in customer response time. And record every validation outcome with its date, so the audit question has a stored answer.

Put an approval step in front of changes to those fields and you get the last piece for free. A tax identifier or a routing address that changes without review is the same failure mode as a bank detail that changes without review, and the audit trail that records who changed the VAT number and when is the same trail the tax authority will eventually want to see.

None of this is new advice, and I am aware it is not exciting. It is the customer and supplier master data hygiene that has sat on the backlog for years, unfunded because nobody could put a date on the consequence. The mandates put a date on it. Of everything the regulators have done here, that is the part I would actually thank them for.

Common questions