How to Prepare for an E-Invoicing Mandate Nobody Has Published
Six data conditions that every fiscal regime we have built against depends on, none of which require knowing what your regulator will eventually publish — and all of which are cheap while nothing is urgent.
"Get ready for e-invoicing" is one of the least useful instructions in enterprise software, because in most markets it is issued years before there is anything to be ready for, and the people issuing it are selling the readiness.
But there is a real version of the advice underneath the sales version, and it is worth separating them. Fiscal regimes differ enormously in architecture — clearance, reporting, four-corner networks, direct authority integrations — and almost not at all in what they assume about your records. That gap is the whole opportunity.
This is written from having built and maintained one real fiscal integration — Kenya's eTIMS — and from reading the published specifications of several others. It is not tax advice for any jurisdiction, and your own obligations are your revenue authority's to define.
Why the architecture varies and the assumptions do not
Consider three live models. Saudi Arabia clears a standard invoice synchronously: the document goes to the authority, is stamped, comes back, and only then may be issued. Oman uses a decentralised network in which invoices travel between accredited access points and both parties report separately. Kenya runs a direct integration to the authority. Architecturally these have almost nothing in common.
Now consider what each of them needs from your data. All three need to know who the counterparty is, in a form that can be validated. All three need the document to have an identity that is unique and unbroken. All three need the tax on each line, not just the total. All three need to be able to link a credit note to what it credits.
You cannot prepare for the architecture. You can prepare for the assumptions, and the assumptions are remarkably stable.
The six conditions
One. An unbroken invoice sequence
Sequential document numbering without gaps is close to universal, and it is the condition most often quietly violated. The violations are rarely deliberate: somebody issued a manual invoice from a template during a system outage, a second numbering series was created for a branch, a cancelled document left a hole nobody recorded.
Cheap now: let the system own the series, never issue outside it, and record cancellations as cancellations rather than deletions. Expensive later: a history full of gaps and parallel books is a reconciliation exercise you have to complete before the integration project can even begin, and it is nobody's favourite fortnight.
Two. A tax field on every line, populated even at nil
This is the one that sounds pointless in a market with no sales tax, and it is the one with the worst retrofit. The instinct in a nil-rate market is to omit the field entirely, because why carry a column that is always zero.
Cheap now: a tax code on every sales and purchase line, populated, even when the rate is nil. Expensive later: if the field does not exist, introducing one means revisiting the item master, the price lists, the customer-specific pricing and every open order — simultaneously, under a deadline, with the same three people who are also doing the integration.
Three. Counterparty identifiers as structured fields
Every regime validates who you are trading with. Commercial registration numbers and tax identifiers therefore need to be fields on the customer and supplier record — their own fields, with their own validation.
Cheap now: two extra fields on a form. Expensive later: extracting identifiers from the second line of an address across several thousand records, deduplicating the suppliers you discover you have entered three times, and doing it against a deadline. This is the single most common cause of a fiscal integration slipping, in our experience, and it has nothing to do with the integration.
Four. Net, tax and gross stored at capture
There is a meaningful difference between storing three values and storing one value plus a rule for deriving the others. Derived tax is fine right up until a rate changes mid-period, or a credit note is raised against a document issued under an older rate, or somebody needs to know the number that was actually charged rather than the number today's settings would produce.
Cheap now: store what was charged. Expensive later: explaining to a reviewer why last year's numbers changed when you updated a setting.
Five. Documents attached to the transaction they justify
This one is not about e-invoicing at all and it is on the list because it is the condition operators most consistently wish they had started earlier. The delivery note, the customs entry, the supplier's registration certificate, the signed variation — attached to the record they belong to rather than filed by date in a shared drive.
Cheap now: attach as you go, which costs seconds. Expensive later: the difference between a tax review that is a retrieval exercise and one that is an archaeology exercise, conducted by people who were not there.
Six. Attribution applied at capture, not afterwards
Project, cost centre, department, entity — carried on the transaction as it is created rather than allocated afterwards by a spreadsheet. This matters for fiscal readiness because several regimes now ask for positions that can only be built from attributed data, and it matters far more for the ordinary reason that a retrospective allocation is a judgement rather than a fact.
Cheap now: a required field with a sensible default. Expensive later: reconstructing a year of unallocated cost, and then defending the reconstruction.
The test for whether you have actually done this
Pick a single invoice from eleven months ago. Without asking anyone, produce: the sequential position of that document in its series, the tax charged per line, the counterparty's registration identifier as a discrete value, the delivery evidence behind it, and the project or cost centre the revenue was attributed to. If that takes more than two minutes, the conditions are not in place — and none of that difficulty has anything to do with a mandate.
What is not on the list, and why
Worth being explicit about the things commonly sold as readiness that we would not spend money on before a specification exists.
- Buying an integration in advance. There is nothing to integrate with. A pre-purchased connector for an unpublished specification is a deposit on a guess.
- Choosing a vendor primarily on a readiness claim. In the absence of a specification, "ready" resolves to a configurable tax field, which is table stakes rather than a differentiator.
- Restructuring your chart of accounts on speculation. Most regimes care about documents rather than ledgers. Wait and see what is actually asked for.
- Appointing a service provider early. In network models the provider market usually consolidates and prices improve after the specification lands. Early is not an advantage here.
What good preparation actually predicts
Here is the part that makes this worth an afternoon rather than a meeting. When a mandate does land, the cost of complying splits into two very unequal halves.
The build
- Document format, transmission, signing, failure handling, archive.
- Well-specified, well-understood, and increasingly commoditised.
- Delivered by a vendor or a service provider on a known timeline.
- Priced competitively, because several people can do it.
- Rarely the reason a project is late.
The data remediation
- Sequences, identifiers, tax fields, deduplication, history.
- Unspecified, unbounded, and discovered as you go.
- Delivered by your own people, who have other jobs.
- Unpriced, because nobody knew how bad it was.
- Almost always the reason a project is late.
Everything in the six conditions is remediation you can do at a time of your choosing, in small pieces, without a deadline. That is the entire argument.
What AWRA OpsHub does today
- System-owned document sequences
- Tax fields on every sales and purchase line, split net, tax and gross at capture
- Structured registration and tax identifier fields on customers and suppliers
- Documents attached to transactions, checksummed and access-logged
- Project, cost-centre and department attribution carried at capture
- One real, maintained fiscal integration — Kenya's eTIMS
What it does not do
- Any fiscal integration outside Kenya
- A Peppol access point or service provider accreditation, anywhere
- Parsing or generation of PINT, UBL or other structured invoice formats
- Readiness claims for any unpublished specification
What is not built for Qatar today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do in Qatar. Kenya's eTIMS integration and its maintained payroll engine exist because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If a tax pipeline once there is one to build to, an Arabic interface, a bank or mobile money feed, a statutory return format or a link to a system you already run is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
Built when Qatar publishes a specification, not before
Whatever the General Tax Authority eventually publishes — a VAT return, an electronic invoicing interface, or both — built against the actual specification rather than against a rumour of one. We are deliberately not naming a rate or a date, because Qatar has not, and a vendor pretending otherwise is telling you something about how they will handle the rest of the project. What we would do in the meantime is the readiness work that makes the build small: tax codes carried on every line at whatever rate applies today, one invoice numbering series, and a document trail that survives a change of regime.
Arabic interface, banks and acquirers
Arabic interface text with right-to-left layout and bilingual document templates, plus bank statement feeds, card acquirer settlements and payment files wired into the Payments Register so collections match invoices without anyone re-keying a statement.
Payroll and statutory returns
A Qatari payroll engine producing wage files in the layout the Wage Protection System expects, with end-of-service gratuity accrued on live employee records rather than estimated once a year, and the Qatarisation position visible before a deadline.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integratedThat last line is a policy rather than a gap. We will not put a readiness badge on a market where the regulator has not published, because the badge would be doing work that an honest scope list should be doing.
Our take
You cannot prepare for an architecture nobody has published, and you should be suspicious of anyone selling you the ability to. You can prepare for the assumptions, which barely vary between regimes, and which are just good records under another name. Do the six things while nothing is urgent. When the mandate lands you will discover that the expensive half of compliance is the half you already did.
Run the eleven-month test
Pick one invoice from last year and try to produce its sequence position, per-line tax, counterparty identifier, delivery evidence and cost attribution in two minutes. Whatever you find is worth knowing, and you do not need us to find it.
Talk to us about your recordsFrequently asked questions
Is this only relevant to markets without a mandate?
No — it is most useful there because you have time, but the six conditions apply everywhere. If a mandate has already been announced with a date, the same list is what your project plan should open with, and the honest sequencing is remediation first and integration second. Teams that do it the other way round discover the data problems during testing, which is the most expensive moment available.
How long does this take?
Five of the six are configuration decisions made once, at setup, and cost effectively nothing if you make them at the start. The exception is counterparty identifiers, which is a data-cleaning exercise proportional to how many customers and suppliers you have and how long you have been going. For a business with a few hundred trading partners it is a week of somebody's attention. For one with several thousand and a decade of duplicates, it is a project — which is precisely the argument for starting before there is a deadline.
We are on spreadsheets. Does any of this apply?
The conditions apply; the mechanism does not. You cannot enforce an unbroken sequence or a required attribution field in a spreadsheet, which is one of the more concrete arguments for leaving them that we know of. If you are staying on spreadsheets for now, the two worth doing anyway are attaching documents to transactions in a consistent place, and capturing counterparty registration identifiers as their own column rather than inside an address block.
Does AWRA sell a readiness product?
No, and we would rather not. The six conditions are properties of good record-keeping and any competent system can meet them — ask your existing vendor to show you, before you assume you need a new one. What we would say is that meeting them accidentally is rare, so it is worth checking rather than assuming.
Which fiscal integrations have you actually built?
One, properly: Kenya's eTIMS, which is live and maintained. That is a deliberately unimpressive answer and it is the honest one. It matters here only because having built one means we can describe the work concretely — document format, transmission, retries, failure queues, reconciliation, archive — rather than abstractly, and the difference between concrete and abstract is the most useful signal you have when assessing a vendor's claims about a future build.
