Every business case for an e-invoicing programme contains a table of per-document prices, because that is the number the proposals contain and it is comparable across them. It is also, in most implementations, somewhere between the third and the fifth largest cost.
The costs that dominate are effort inside your own business, which is exactly why they are absent from every proposal you will receive. Nobody is quoting for your master data.
What follows is a structure rather than a set of figures. The figures have to be yours — anything else is somebody else's item master presented as a benchmark.
The categories, in the order they are incurred
| Category | One-off or recurring | What drives it | Who actually holds the figure |
|---|---|---|---|
| Assessment and scoping | One-off | Number of entities and jurisdictions | Finance, with tax |
| Master data remediation | One-off, with a recurring tail | Count of records failing each test, and how many need a third party to resolve | Whoever owns each master |
| Source system change | One-off | Gap between what the system emits today and what is required | The application team |
| Platform or network subscription | Recurring | Countries covered, entities registered | Procurement, from the proposal |
| Per-document charges | Recurring | Document volume, by direction | Procurement, from the proposal |
| Receiving-side process change | One-off | Size of the accounts payable function and its current process | The accounts payable owner |
| Supplier onboarding | One-off, front-loaded | Supplier count by segment | Procurement |
| Testing | One-off, then recurring | Number of profiles and receivers in scope | The project, then whoever inherits it |
| Exception handling capacity | Recurring | Volume multiplied by rejection rate multiplied by handling time | Operations, if anybody |
| Profile maintenance | Recurring | Number of jurisdictions, and their rate of change | Nobody, usually |
| Archive operation | Recurring, over the retention period | Volume, retention period, access requirements | Nobody, usually |
The two rows marked "nobody, usually" are the ones that decide whether a business case turns out to have been accurate. Profile maintenance and archive operation are permanent obligations with no natural owner at the point the case is written, so they get omitted, and they run for as long as the arrangement does.
Working an example structure
Here is the shape of the calculation for the line most often left out entirely. Every input is yours; the structure is the contribution.
The recurring exception handling cost
Every input comes from your own systems. Nothing here is a benchmark.
- Documents issued and received per monthyour figure
- (times) proportion that raise an exceptionyour figure
- Exceptions per monththe product of the two
- (times) average minutes to diagnose and resolve oneyour figure
- Minutes per monththe product
- (divided by) working minutes in a monthyour figure
Full-time equivalent capacity requiredthe recurring cost nobody budgeted
Measure the rejection rate after go-live rather than assuming it, and measure the handling time rather than guessing — it is consistently higher than people expect. Run the model twice, once on the assumed rate and once on the measured one: the gap between them is the honest uncertainty in the business case, and stating it is better than hiding it in a contingency.
The point of setting it out this way is not the arithmetic. It is that the model makes the assumption visible. A case that says "exception handling: 0.4 FTE" invites the question "based on what?", and having an answer is what separates a defensible number from a placeholder. The operational reality behind the inputs is described in exception handling in week three.
Remediation is a count, not a duration
The second commonly wrong line is master data, and it is wrong because it is estimated in weeks rather than derived from records.
The right form is: how many records fail each test, split by whether they can be fixed internally or require asking somebody outside the company. The internal half scales with tooling. The external half scales with other people's response rates and cannot be compressed by adding project resource, which is why it sets the timetable.
That split has to come out of the readiness assessment as counts. Anything softer produces a plan that slips for reasons that were knowable at the start. The nature of the work, and why it recurs after the project ends, is set out in master data for e-invoicing.
Where the savings actually are
A business case should be honest about which side of the transaction produces the benefit, because the two are not comparable.
On the issuing side, savings are modest. Printing and postage disappear where they still existed, and some collections effort improves because disputes surface earlier. The document was already produced by a system; producing it in a different format saves little.
On the receiving side, real work disappears. Capture, keying and a proportion of the manual validation stop existing, and that is measurable in hours today. It is the only place a substantial saving can honestly be claimed, and it is offset by the fact that the work which remains is harder — exceptions and judgement, rather than volume.
A case claiming large savings on the issuing side is usually counting a benefit that accrues to the recipient, or to the tax administration.
Multi-country, without double counting
Two symmetrical errors.
Multiplying the whole model by the number of countries overstates badly, because assessment, source system change and the core data work are largely shared. Treating the second country as marginal understates by more, because country-specific profile work, registrations, testing against a new set of receivers and a new set of national rules are all genuinely new.
The workable structure separates shared cost from per-country cost and applies each to the right base. It also makes the sequencing decision visible: whether to solve one country and repeat, or to build for several at once, is a question about how much of the cost is shared, and the model is what answers it rather than a preference.
The transport and coverage element of that is a separate procurement question, and the durable criteria for it — exit terms, coverage roadmap, who absorbs profile changes — are set out in choosing an access point. Where the integration itself should live, and what the hybrid arrangement really costs, is the subject of in the ERP or at the provider.
What the horizon has to include
Run the model long enough to contain the things that only happen occasionally.
At least one profile revision requiring rework, because national rules change and the change arrives as unplanned work. At least one archive event — a migration, a provider change, a retention expiry process. And the full retention period for the archive line itself, because storing documents for a decade is a recurring cost that outlives the project, the platform and usually the people who chose them.
A three-year model omits all three, which is why three-year models make the outsourced option look better than it is and the in-house option look worse.
The output worth producing
Not a number. A range, with the drivers named, and the two or three assumptions the range is most sensitive to stated on the same page.
In practice those are almost always the same three: the rejection rate, the count of master data records requiring external resolution, and the number of jurisdictions in scope within the horizon. If those three are stated as assumptions with their sources, the case can be revised in an afternoon when reality arrives. If they are buried, the case has to be rebuilt from nothing, usually by somebody who was not there when it was written.
