- Clearance and Peppol validation failures overwhelmingly trace to master data defects — stale registration numbers, mismatched vendor records, wrong tax codes — not to transaction logic.
- Rejections cluster into five recurring defect families: counterparty identifiers, tax codes, item and unit-of-measure data, addresses and jurisdiction, numbering and duplicates.
- Each rejection names the field, the record, and the rule. Aggregated, that is a prioritised remediation queue — weighted by your real invoice volumes.
- Fixing the master record once beats patching invoices forever. The lasting fix is ownership: a named data owner per domain.
When the first e-invoice rejections arrive, the instinct in every finance team is the same: treat each one as an incident. Fix the invoice, resubmit, move on. It works, in the sense that the invoice eventually clears. It also guarantees the same rejection next month, because the defect was never in the invoice. It was in the master record the invoice was built from.
This is the most consistent pattern we see across implementations, in clearance regimes and Peppol exchanges alike. Validation failures look like transaction problems and are, overwhelmingly, master data problems. A malformed or lapsed tax registration number on a customer master. A vendor record that no longer matches the registry entry behind it. A unit of measure that exists in your item master but not in the permitted code list. A line item carrying a tax code that was correct under last year's configuration.
None of these defects was created by the invoice. The invoice merely inherited them — and the validation engine, unlike every human who handled that record for the past five years, refused to look the other way.
The five defect families
Rejection logs feel chaotic at first contact: hundreds of entries, cryptic rule identifiers, no apparent order. In practice they sort into five families, and the sorting is the first hour of useful work.
1. Counterparty identifiers. Tax registration numbers that fail format checks, belong to a deregistered entity, or simply do not match the name on the registry. These usually dominate the early weeks. A typical pattern looks like a customer master last verified at onboarding — eight years ago — colliding with a validation rule that checks it today.
2. Tax codes. Line items carrying codes that are invalid for the supply type, the jurisdiction, or the current rate configuration. These defects often trace to one shared item template or one copied sales order, which is good news: one fix, many invoices.
3. Item and unit-of-measure data. Internal item codes and units ("DRUM", "PALLET", a legacy "EA" variant) that have no mapping to the standard code lists the schema demands. Tedious rather than difficult — but only fixable in the item master, not on the invoice.
4. Addresses and jurisdiction. Missing country codes, free-text address lines where structured fields are required, branch addresses that imply the wrong tax jurisdiction. These matter more than they look, because jurisdiction drives tax treatment.
5. Numbering and duplicates. Sequence violations, reused invoice numbers across systems, duplicate submissions after timeout-and-retry. The only family that is genuinely a process and integration defect rather than a master data one — and worth isolating precisely so it does not muddy the other four.
Every rejection names the field, the record, and the rule that failed. Consultancies charge serious money for diagnostics less precise than this.
From log to remediation queue
The transformation is mechanical, which is why it is so often skipped. Take the rejection log. Strip it to four columns: rule violated, field affected, master record implicated, count of occurrences. Group by master record. Sort by count.
What you now have is a remediation queue ordered by real-world impact: the customer master defect that blocks two hundred invoices a month sits above the one that blocks two. No data-profiling tool can produce that prioritisation, because no tool knows your invoice volumes the way your own rejection log does. The authority's validation engine has, in effect, audited your masters against the rules that legally matter, weighted the findings by your actual trading activity, and handed you the report. The only fee is the embarrassment.
Two practical notes from implementation work. First, distinguish defects in the master record from defects in the mapping — a correct VAT number truncated by your integration layer looks identical in the log until you check the source. Fixing masters that were never broken is a morale-destroying way to spend a quarter. Second, close the loop: after each batch of master fixes, the next month's log should show the family shrinking. If it does not, the defect is being re-introduced — usually by whichever upstream process created it in the first place.
Fix the master once, or patch invoices forever
The economics are not subtle. Patching a rejected invoice costs minutes each time, forever, plus the operational drag of delayed clearance — and in a clearance regime a rejected invoice is not legally issued, which makes this a cash-collection problem, not an IT one. Fixing the master record costs more once: verify the registration, correct the record, find out why it was wrong, stop it going wrong again. Then the cost goes to zero.
That last clause — find out why it was wrong — is where this stops being a clean-up and becomes governance. A defective record is a symptom; the cause is that nobody owned it. Records created by whoever onboarded the counterparty, edited by whoever noticed a problem, verified by no one on any schedule.
Give every domain an owner
The durable fix is the one the data management discipline has recommended for decades, DAMA-style: a named owner per master data domain. One accountable person for customer masters, one for vendor masters, one for items and units, with defined quality rules and the authority to enforce them at the point of entry. Not a committee, not a "data quality initiative" — a name against a domain.
E-invoicing mandates have a way of making this argument better than any internal memo ever did, because the cost of unowned data now arrives weekly, itemised, from the tax authority. Our suggestion is to use the moment. The rejection log has already told you which domains are bleeding and which records matter most. Assign the owners, hand each one their slice of the queue, and let the mandate fund the data governance programme you could never get prioritised on its own merits.
You paid for the audit either way. You may as well act on it.