Stop Treating E-Invoicing Like an IT Project

Who should own e-invoicing — finance or IT?

<div class="post-intro"> Almost every e-invoicing mandate arrives looking like an integration problem, so it gets handed to IT. Months later the finance team discovers that decisions about tax categories, exemption codes and correction handling were made by people who had no basis for making them. The connection was never the hard part. Deciding what your invoices must contain is, and only finance can do it. </div>

Why it gets handed to IT in the first place

The framing is understandable. A mandate says invoices must be transmitted in a structured format to a network, and that sounds like plumbing. There is an API, there are credentials, there is a certificate. Someone forwards the specification to the team that owns integrations and the project begins.

The plumbing is real, and it is genuinely the easy part. Connecting to a Peppol Access Point is usually measured in days. What takes months is discovering that the data your system has been emitting for years does not contain everything the rules now require — and that nobody in the room is authorised to decide what it should contain instead.

The decisions IT cannot make

Here is where these projects actually stall. Every one of the following is a tax judgement, not a technical one, and each has a wrong answer:

Which transactions are in scope. Domestic only, or exports too? Intercompany billing? Credit notes and debit notes? Self-billing arrangements, where your customer raises the document on your behalf? Each answer changes what gets built.

What tax category every line carries. Standard-rated is easy. The trouble is everything else. A zero-rated or exempt line usually cannot simply carry a zero — it needs a reason. In Oman, a zero-rated line must carry a code from the VATZR-OM list and an exempt line from VATEX-OM, and the invoice is rejected without one. No integration engineer can tell you which code applies to a particular product. Your tax adviser can.

How corrections work. When an invoice is wrong, do you cancel and reissue, or raise a credit note? Does the correction reference the original document, and by which identifier? Get this wrong and your ledger and the authority's records diverge in a way that is painful to unwind at audit.

How long documents are kept, and where. Retention periods are a legal question, and increasingly so is location — several jurisdictions now expect records to remain in-country. That is a procurement and compliance decision with an infrastructure consequence, not the reverse.

Who is accountable when a document is rejected. Validation will reject some proportion of real invoices in the first weeks. Somebody has to own the queue, and it cannot be a person who does not know whether the invoice was right.

The pattern when nobody owns the tax side

It plays out the same way often enough to be predictable.

The integration is built against whatever the ERP emits today, because that is the only specification available. It passes testing, because testing uses the handful of clean invoices someone exported for the purpose. Then it meets the real ledger — the customer with no tax number, the historic exemption nobody can explain, the product group that was never assigned a tax category because it never mattered before.

Validation rejects them. The fixes are master-data and configuration changes in the ERP, owned by finance, and were never in the project plan. The programme that was tracking green for four months slips at the point where slipping is most expensive.

The tell is that none of this is an integration defect. The integration works. It is faithfully transmitting invoices that were never complete enough to be transmitted.

What good ownership looks like

A single accountable owner in finance or tax. Not a committee. Someone who can decide that a product group is zero-rated under a specific code, and be answerable for it. This is the single highest-leverage decision in the whole programme.

IT owns delivery, and that is a real job. The connection, credentials, certificate lifecycle, monitoring, retries, and the alerting that tells someone a document did not arrive. Necessary, well-defined, and much smaller than the scope IT is usually handed.

Master data cleaned before the integration, not after. Customer tax registrations, country codes, product tax categories. This work is unglamorous, it is nobody's favourite quarter, and it determines the go-live date more than any technical decision.

A dry run against real invoices, not sample ones. Validate a month of actual history before go-live. The rejection report is the true project plan — it tells you exactly which decisions are still outstanding, while there is time to make them.

Someone owns the exception queue from day one. Named, with time allocated.

The awkward question worth asking early

Ask whoever is running the programme: which tax category and reason code will appear on our zero-rated lines, and who decided that?

If the answer is a name in finance, the project is in good shape. If it is "we'll pick that up during integration testing", the go-live date is optimistic, and it is better to know now than in the week before.

Where the deadline pressure actually sits

Mandates arrive in waves, and the wave you are in determines how much of this you can sequence calmly. Oman's first milestone in August 2026 covered the first 100 large VAT-registered companies. February 2027 brings in all large companies, and August 2027 brings in everyone else — which is where most businesses sit.

That is more time than it sounds like for the technical work and less than it sounds like for the data work. Organisations that spend the intervening months cleaning master data and settling tax questions tend to find the integration anticlimactic. That is the goal.

If you want the specifics for a particular regime, we have written separately on Oman's Fawtara model, the five-corner architecture that separates the invoice from the tax report, and a Peppol onboarding checklist for finance teams. For the underlying network rules, OpenPeppol publishes the specifications, and the OECD's work on VAT digital reporting is a reasonable primer on why so many authorities are converging on the same model.

Frequently asked questions