The adoption imperative: Why eInvoicing is a change programme, not an integration

Most eInvoicing programmes begin with a question about compliance. What do we need to build to meet the requirement. It is the right question, in the wrong order.

The better starting point is a question about experience. What does the last day of the old way look like for a supplier, and what does the first day of the new way look like. Where in that transition does the person get confused, get nervous, or quietly decide it is not worth it.

You find these things by asking. Not through a survey, through conversation. Sit with a finance team and watch them process a batch. Talk to three small suppliers about what happens between sending an invoice and seeing the money. You will hear the same two anxieties nearly every time: will it get lost, and will I know it arrived. Those anxieties are your design brief. Everything you build, say and send should answer them.

Design from there, and the technical requirements slot into a story that makes sense to somebody outside the project. Design from the standard, and you end up asking people to care about interoperability, which they never will and never should.

There is a strong pull, in any mandated programme, towards going wide early. The requirement applies to everyone, so tell everyone. It feels equitable. It is also the fastest way to burn credibility across a whole supplier base at once.

The better pattern is to find the places where a win is cheap and visible. A smaller agency with a contained supplier list. A cohort of suppliers already on cloud accounting who barely have to change anything. A single category of spend where volumes are high and the process is uniform.

Run it properly there. Not as a pilot in name, as a real deployment with real invoices, real problems and a real measure of whether people came back and did it again. Then use what you learn, and use who you convinced. A supplier who tells another supplier it went fine will move more volume than any amount of guidance material.

Quick wins are not a soft option. They are how you buy the right to go wide.

We are asking small and medium businesses to change how they operate for a specific carrot: getting paid faster.

That is a good carrot. Cash flow is the thing that keeps small businesses awake, and shortening the gap between work done and money in is genuinely valuable to a two person operation in a way it never is to a large agency. It is the single most persuasive thing we have.

So it needs to be said plainly, repeatedly, and in their language. Not “improved processing efficiency”. Paid faster, with fewer disputes, and no more chasing to find out whether it landed.

And then it needs to be true. The fastest way to lose a supplier base is to promise faster payment and deliver the same wait, because the invoice now arrives cleanly in a system where it still sits in someone's approval queue for three weeks. If the promise is speed, the internal process has to be able to keep it. Adoption is built on the second invoice, not the first.

Communication in these programmes is usually treated as an output. Someone writes the guidance, someone builds the landing page, someone sends the notification. Then delivery moves on.

I would treat it as infrastructure, sitting alongside the integration and given the same rigour. Who hears what, when, from whom, and what do they do next. What does a supplier see the moment their invoice is received. What happens when something fails validation, and does the message that comes back make sense to a person who has never heard the word schema.

The transitions are where people fall out. The gap between being told and being ready. The gap between sending and knowing. Every one of those gaps is a place where somebody reverts to the old way, and reverting is very easy, because the old way still works.

Cover the gaps and you keep people. Leave them open and you will spend the next two years wondering why uptake stalled at a number nobody is happy with.

None of this replaces the technical work. It sits on top of it.

The baseline is non negotiable: the integrations work, the validation is reliable, the exceptions are handled, the thing does not fall over at month end. Get that wrong and no amount of experience design will save you, because you will be asking people to trust something that is actively failing them.

But once it works, the technology should become invisible. The measure of a good eInvoicing implementation is that suppliers stop thinking about it. It is not a platform they engage with, it is a step that got easier and then disappeared from view.

Programmes get this backwards more often than not. They spend the first year making the technology work and talking about the people, then spend the second year with working technology, talking about the technology, and wondering where the people went.