There is a sentence that appears in almost every post-mortem of an e-invoicing programme, in slightly different words: the technology worked, and the data did not.
It is worth taking seriously rather than treating as a platitude, because it points at a specific and predictable failure. A structured invoice makes load-bearing a set of fields that were, until the mandate arrived, decorative. Nobody validated them because nothing depended on them. Now everything does, and the state they are in is the state that fifteen years of nobody looking produces.
The fields that changed status
The point is not that master data got worse. It is that its role changed.
A customer's legal name on a PDF was a label. A human at the other end knew who you were regardless of whether the account was set up as "Acme Ltd", "ACME Limited" or "Acme (formerly Beta Systems)". A unit of measure was a word in a column. A tax registration was a string somebody typed once during onboarding, from an email, without checking it.
None of that survives structured invoicing. The name is compared, the unit of measure has to be a code list value, the registration determines the tax treatment, and there is no human at the receiving end to interpret around any of it.
What breaks, per object
| Object | The field that now matters | What correct actually means | What a wrong value produces |
|---|---|---|---|
| Customer | Tax registration | Well-formed for the jurisdiction and verified against the source, not transcribed | Wrong VAT treatment on every transaction with that customer |
| Customer | Legal name | The registered name, matching what the counterparty's own records say | Rejection on receiver-side rules; or acceptance and a matching failure at their end |
| Customer | Electronic address | A scheme identifier and a value together | Delivery to nowhere, or to a portal nobody monitors; silent, not an error |
| Customer | Country and address components | The fields the applicable profile requires, in separate fields | Whole-batch rejection on a mandatory element |
| Supplier | The same set, inbound | Collected in a form you can actually use, not free text | Inability to receive at all, which arrives before the obligation to issue |
| Item | Unit of measure | A maintained code list value | Line-level rejection on documents that are otherwise correct |
| Item | Tax classification | Mapped to a category a validator recognises | Systematic wrong rate across an entire product family |
| Own entity | Every registration you hold | Current, per country, with effective dates | Correct transactions expressed as invalid documents |
The final row is the finding that matters. Master data errors are not random and they do not average out. A record that is wrong is wrong in the same way every time it is used, which means the defect count scales with transaction volume rather than with the number of bad records.
Present, populated, and correct are three different things
This is where completeness reporting misleads.
A field can be populated with something that is not a valid value — a tax registration with the country prefix repeated, a unit of measure spelled out as a word, an address with the town in the street line. It can be populated with a valid value that is not this customer's. It can hold a value that was correct at onboarding and has since been deregistered, renamed or acquired.
Only the first of those is detectable by a format check. The second and third require comparison with something outside your systems, and the third requires it periodically rather than once, which makes this a permanent obligation rather than a project.
An electronic address is the clearest illustration, because it is the field most often half-collected. It is a scheme and a value: the scheme says which identification system the value belongs to, and the value alone is ambiguous. A data set holding only values looks ninety per cent complete and is not usable, and the reason is explained properly in how a participant identifier becomes a delivery. Which schemes exist and what belongs in them is the subject of code lists and identifiers.
Where a determination input is missing, systems do not stop; they fall back — to the domestic standard rate, to a generic unit of measure, to whatever the previous transaction used. None of those produce an error message, which is precisely why they are dangerous. The invoice is issued, accepted and posted, and the defect is discovered by a reconciliation or by an assessment. This is the mechanism behind most of determination going wrong, and it is a data problem wearing a tax problem's clothes.
Measuring the gap
Remediation cannot be planned from an impression, and the measurement is not hard. Extract each master, run one test per field per record, and count failures.
The output is a table of counts by test — not a percentage, and not a red-amber-green. Counts convert directly into effort, because effort in this work is a function of how many records need touching and how many of those need somebody outside the company to answer a question.
That distinction is the one that sets the timetable. Records fixable from internal sources — a mapping table, a rules-based correction, a bulk update — go quickly and predictably. Records requiring a customer or supplier to supply something go at the speed of other people's inboxes, and no amount of project resourcing changes that. Splitting the gap along that line at the assessment stage is what makes the plan credible.
Fixing it once is not the deliverable
Here is the part that separates programmes that hold from programmes that regress.
Data quality degrades from the moment remediation stops, because the processes that created the bad data are still running. A new customer is onboarded by somebody in a hurry with a registration nobody verified. A new product is added by copying an existing one and inheriting its tax classification. An acquisition brings in a master that was never subject to your standards.
So the durable deliverable is not clean data. It is three things that keep it clean: validation at the point of entry, so a record cannot be created without the fields the mandate needs; verification against an external source where one exists, rather than transcription; and a periodic re-check, because facts about counterparties change without anybody telling you.
Of those, entry validation is the cheapest and the most resisted, because it makes onboarding slower for the people whose job is to onboard quickly. That argument is won by pointing at the cost of the alternative, which is why the counts from the gap measurement are worth keeping after remediation finishes.
Where the supplier side is different
Everything above is written from the issuing side. The receiving side has the same problem with the arrow reversed, and one additional difficulty: the data you need is held by somebody else.
You cannot verify a supplier's electronic address by looking harder at your own system. You have to ask, or look it up on a network directory, and you have to do it across a supplier base that is typically larger and more fragmented than the customer base. That is a communication exercise rather than a data exercise, and it is treated in onboarding suppliers at scale.
The connection worth making is that the two sides share a data model. A supplier record and a customer record need the same fields, verified the same way. Organisations that run them as separate projects with separate standards end up with two definitions of a correct tax registration, which is one more than anybody needs.
What good looks like
Nothing impressive. A defined set of fields per object with a stated test for each. A measured count of records failing those tests, refreshed periodically rather than at project milestones. Entry validation that prevents new failures. A named owner per master who is not the project manager. And a mapping table — internal categories to code list values — that is documented with its reasoning rather than existing only in configuration.
The organisations that find a mandate straightforward are not the ones with the best platform. They are the ones that could already say, before the project started, where each of those fields came from and who checked it.
