The decision gets put to a steering committee as build or buy, and it is answered in the language of cost per document and time to market. Both of those are real and neither is the actual question.
The actual question is where knowledge should sit. Every e-invoicing arrangement contains a body of specialised understanding — what each country requires, how your data maps onto it, why a particular receiver rejects a particular document — and that understanding has to live somewhere. It can live inside your organisation, where it is expensive to build and cheap to consult, or outside it, where it arrives fully formed and is reachable only through a support process.
Everything else in the comparison follows from that.
What each side genuinely offers
The case for the source system is that determination and content depend on facts only your systems hold. What was supplied, to whom, where, on what terms. When the logic sits next to that data, the people maintaining it can see why a document came out the way it did, and a question about an invoice is answered by looking rather than by asking.
The case for the provider is coverage and pace. National profiles change, networks change their requirements, new countries arrive. A provider absorbs that as a product roadmap. Doing the same work in-house means resourcing a small standing capability to track regulatory change in jurisdictions where you may issue a hundred invoices a year, which is difficult to justify and difficult to staff.
Both cases are sound. They are also not symmetrical, and the asymmetry is where the decision lives: the provider's advantage is in the part that changes often and matters uniformly, and the source system's advantage is in the part that changes rarely and matters specifically to you.
The axes that actually decide it
| Axis | Source system | Provider | The question to put to a provider |
|---|---|---|---|
| Country coverage | Each new country is a project you resource | Arrives as a service, on their timetable | Which countries are live today, and what is the process when a new mandate is announced? |
| Mapping ownership | Yours, visible, changeable this afternoon | Theirs, opaque, changeable on their release cycle | If a profile change breaks our invoices, whose deadline governs the fix? |
| Diagnosing a failure | Look at the data | Raise a ticket | What does a rejection reason look like in your portal, and can we see the transformed document? |
| Determination | Next to the facts it depends on | Working from what you sent them | What do you do when a required determination input is missing from our feed? |
| Archive and evidence | You hold it | They hold it, under contract | What exactly comes back on exit, and does it include the receipts and metadata? |
| Exit | Not applicable | A migration and a re-registration | What is the notice period, the export format, and who tells the network we have moved? |
That last column is deliberately questions rather than conclusions, because the right answer varies by organisation and the wrong answer is always the one arrived at without asking.
The hybrid, and its honest cost
Most large businesses converge on the same arrangement without setting out to. Determination and document content stay in the source system, because that is where the facts are. Transport, network membership and country-specific profile handling go to a provider, because that is what changes.
It is a sensible division and it is not free. It creates an interface between two systems that both believe they own the document, and interfaces of that kind fail in a characteristic way: the source system emits something it considers complete, the provider transforms it, and the document that arrives at the receiver is not quite either. When it is rejected, the first question — which of the two produced the offending value — takes longer to answer than the fix.
So the hybrid has a deliverable that neither pure option needs: a written interface contract stating exactly what the source system is responsible for emitting, what the provider is permitted to change, and what neither may silently default. Teams that write that document down argue about it once. Teams that do not argue about it every time something fails.
The single most useful thing to establish before signing is whether you can retrieve the exact document as transmitted, after the provider's transformation. If the answer is no, then every dispute about content becomes a conversation about what their platform did, conducted without evidence. It also has an archiving consequence, because what has to be preserved is the document as issued, and if you never see it you are relying entirely on them to keep it.
Where determination has to sit, and it is not balanced
On most axes the comparison is genuinely two-sided. On one it is not.
A provider can apply country rules to what it has been told and check the result for internal consistency. It cannot know that the delivery address on this order is a temporary site rather than an establishment, that this customer's registration was cancelled last month, or that this product changed classification. Those are facts about your business, held upstream, and a platform that determines VAT is determining it from a subset of the evidence.
That is not an argument against providers. It is an argument that determination belongs where the facts are whichever side of the line the transport sits on, and that a proposal offering to take determination off your hands is offering to take a decision without the inputs to make it.
The transport question is separate and smaller
There is a tendency to fold the network question into this one. They are different decisions and they have different lifespans.
Which access point carries your documents is a procurement decision with its own criteria, and it can be changed with less disruption than moving the mapping logic. The durable questions there — coverage roadmap, exit terms, what the contract says about failures caused by your data rather than their platform — are worked through in choosing an access point, and they are worth answering independently of where the integration lives.
Keeping them separate has a practical benefit: it prevents a good transport provider from being chosen because their mapping product was convincing, or the reverse.
What the comparison usually omits
Three recurring costs, none of which appear in either proposal.
The exception queue. Whoever holds the mapping, somebody in your business works the rejections, because a rejection is usually about your data. That capacity is real and it is the same in both options, which means it should be removed from the comparison rather than assumed away in one of them. What it actually looks like is set out in exception handling in week three.
Profile maintenance. National rules change. In-house that is a resourced activity; at a provider it is included in the subscription until the change is large enough to be a project. Either way it recurs, and a comparison over one year misses it entirely.
Testing. Every change to either side has to be validated against the receivers who will actually reject it, and that capability has to exist regardless of architecture. It is covered in testing against the validation stack.
All three belong in the recurring column of the cost model, and putting them there is what turns a build-or-buy slide into a comparison worth making.
The position worth defending
If the decision has to be reduced to a sentence: keep what depends on your own facts, outsource what depends on everybody else's, and write down the boundary.
That produces the hybrid most organisations reach anyway, but reached deliberately rather than by accretion — which matters, because the accreted version has no interface document, no agreed ownership of the mapping, and no exit clause anybody read. The architecture is the same. What differs is whether anyone can explain it when it breaks.
