Most failed e-invoicing projects did not fail during implementation. They failed at the point where somebody decided what was in scope, got it wrong, and nobody revisited it until the build was half done.
That makes the assessment the highest-leverage work in the whole programme, and it is routinely treated as a preliminary — a fortnight of workshops before the real work starts. It is not preliminary. It is the piece that determines what the real work is.
What follows is the assessment itself, in the order the answers bind. Each stage produces a finding that the next stage needs. Running them in parallel, which is what a compressed timetable encourages, produces answers that contradict each other.
Stage one: which entities, which jurisdictions, which dates
Start here and do not move on until it is written down and signed by somebody who will still be there.
The question is not "does the mandate apply to us". It is: for each legal entity in the group, in each Member State, does that entity meet the mandate's own test for being caught, and from when. Those tests differ. Establishment for one mandate is not establishment for another, and a VAT registration without a fixed establishment produces different answers in different jurisdictions.
- Which legal entities exist, including the ones nobody thinks about because they invoice rarely
- Where each is established, and separately, where each is merely registered for VAT
- Which national mandates catch that entity, on that mandate's own definition rather than on a general one
- Which transaction types each mandate covers: domestic business-to-business, public sector, cross-border, business-to-consumer
- Which stage of the rollout applies to that entity, and on what evidence
- Whether an obligation to receive arrives before the obligation to issue, which it usually does
- What the source is for each answer, so it can be rechecked when the calendar moves
The staging in that picture is the reason the assessment should be keyed to stages rather than to dates. National calendars in this field have been amended more than once, and a plan built on a specific date has to be rebuilt when it moves. A plan built on "we must be able to receive before we must be able to issue, and large entities go first" survives the amendment. The detail of which mandate is at which stage belongs in the national mandates and their dates, read from the primary sources rather than from a summary.
Stage two: which of your documents are invoices
This stage reliably produces surprises, and it takes a day.
List every document type your systems emit that carries a value and goes to a customer. Then classify each one: is it an invoice in the legal sense, a credit note, a request for payment that is not an invoice, a pro-forma, a self-billed document, a statement, or an internal artefact that somebody has been sending to customers for years because it was convenient.
The reason this matters is that a mandate applies to invoices. Documents that are not invoices are out of scope, which sounds like good news and is usually the opposite: they are out of scope of the mandate and still have to reach the customer somehow, so the project now has two channels to design instead of one. And documents that people assumed were not invoices frequently are.
Self-billing deserves specific attention because it inverts who has the obligation, and pro-forma documents deserve it because a pro-forma that is treated as an invoice by the recipient's accounts payable is a problem regardless of what you called it.
Stage three: measure the data, do not estimate it
This is the stage that decides the cost, and the only stage where an opinion is worthless.
Extract the customer master, the supplier master and the item master. Then count. Not "is the field populated" — count how many records have a value that would survive validation.
| What to measure | What actually counts as present | Why it matters | What the gap causes |
|---|---|---|---|
| Customer tax registration | Well-formed for the country, and verified rather than typed | Determination depends on it | Domestic VAT charged where liability should have shifted |
| Customer legal name | As registered, not as the account was named | Validation and matching | Rejections on receiver-side rules that check the name |
| Electronic address | A scheme and a value together, not a value alone | Delivery | Documents that route nowhere useful and fail silently |
| Postal address completeness | Country, and the fields the profile requires | Determination and validation | Whole-batch rejections on a mandatory field |
| Item unit of measure | A code list value, not a free-text word | Line-level validation | Rejection at line level on otherwise correct documents |
| Item tax classification | Maps to a category a validator recognises | Determination | Systematic wrong rate on a product family |
| Your own registrations | Every country you are registered in, current | The document has to state them | Invalid documents from a correct transaction |
Insist on the last row. A completeness percentage is the number people bring to a steering committee and it hides the problem: two per cent of a customer master is a small percentage and several thousand records, each of which will produce a defective document on every transaction until somebody fixes it.
The remediation itself, and why it does not stay fixed, is the subject of master data for e-invoicing. What the assessment owes the project is the number.
Stage four: what the source systems can already emit
Now, and only now, look at the technology.
The question is narrow: what can the current system produce today without a project — which fields, in which structure, with which identifiers attached. Everything the mandate requires that is not on that list is either a configuration change, a development, or a job for something downstream.
That inventory is what makes the in-house or provider question answerable. Asked before it, the question is a preference. Asked after it, it is a comparison between two costed options, and the answer is frequently a split — determination and content upstream, country profiles and transport downstream — rather than either pure position.
Stage five: the receiving side, which is not optional
The obligation to receive normally arrives first and gets a fraction of the attention, because issuing is what the business notices.
Establish what happens today when a structured invoice arrives, which is usually nothing, because nothing has ever arrived. Then establish what accounts payable does with an invoice at all: how it is captured, matched, approved and posted, and which of those steps exists only because the document used to arrive as an image. The redesign that follows is genuinely different work from the issuing project, set out in redesigning accounts payable, and it has its own timetable driven by the earlier deadline.
The supplier population is part of this stage rather than a later one, because its shape determines the effort. Count suppliers by capability, not by spend: how many are already reachable on a network, how many have software that could be configured, how many will need a route that costs them nothing. That segmentation drives onboarding at scale, and it is cheap to do now and expensive to discover later.
Stage six: volumes, exceptions and what the operation will look like
Two numbers and one estimate.
Document volume per month, by entity and by country, because it converts a per-document penalty exposure and a per-document price into figures. Expected rejection rate, which nobody knows in advance — but the assessment can state the assumption explicitly and identify what it would take to measure it after go-live.
From those comes the estimate that matters more than either: how many exceptions per week, and therefore whether the exception queue is somebody's afternoon or somebody's job. That question is answered honestly at assessment or dishonestly in week three, and the difference between those two is the whole operating model.
Stage seven: what will be tested against
The last stage is short and it prevents the most common late failure.
Establish which validation rules will actually be applied to your documents: the semantic rules of the European standard, the national or sectoral profile that applies, and — the one that gets missed — the receiver's own unpublished rules.
A project that plans to test against a public validator has planned to test three of the four gates. The fourth is where production rejections come from, and obtaining real samples from real receivers is a task with a lead time, which is why it belongs in the assessment rather than in the test phase. What that testing involves is worked through in testing against the validation stack.
The option nobody costs
One discipline that improves an assessment more than any amount of extra analysis: cost the option of doing the minimum, and put it in the comparison.
The minimum is not "do nothing", which is not available where a mandate applies. It is the narrowest arrangement that meets the obligation — often a portal or a basic provider connection for the entities actually in scope, with no source system change and no process redesign — carried until the next deadline forces more.
That option is usually rejected, and it should be rejected on its merits rather than skipped. Setting it out does two things. It establishes a floor, so the difference between it and the recommended approach is the amount actually being spent on benefit rather than on compliance. And it produces a fallback that exists on paper if the main programme slips, which is a materially better position than improvising one in the final month.
What the assessment hands over
Four artefacts, and a project that receives anything less has not had an assessment.
A scope statement: entities, jurisdictions, transaction types, stages, with the source for each. A data gap: counts by test and by master, not percentages. An approach shortlist: two or three options, each costed against the same scope, with the trade-off stated rather than a recommendation asserted. And a cost range built from those, in the structure set out in what a mandate actually costs, with recurring costs separated from one-off ones.
The cost range is the deliverable that gets read, and its credibility rests entirely on the three before it. A range derived from a measured data gap can be defended line by line to a finance director who asks where the number came from. A range derived from a vendor's proposal can be defended only by the vendor.
The reason this is worth doing properly
An assessment done well does not make the project cheaper. It makes it knowable, which is a different and more valuable thing — because the failure mode in this field is not overspending. It is discovering in month four that a category of entity was never in scope, or that the item master has no unit of measure, and having to rescope a programme that has already committed a date to a tax administration.
Everything after the assessment is execution against a known target. Everything before it is guessing, and guessing is cheapest to correct now.
