Last month I argued that e-invoicing is a systems project rather than an accounting one, and named the four places it usually breaks. That post argued the shape. This one is the field list, and it answers the question I now get asked in the room: what exactly does the file have to contain, and which of those fields does our stack not hold?
One paragraph on the obligation, because it is the constraint and not the subject. The model is five-corner: you send to your accredited provider, they validate and convert and pass to the buyer’s provider, and the tax authority receives the reporting leg. The first wave appoints a provider by 30 October 2026 and goes live on 1 January 2027, under the May 2026 amendment. Those dates have moved once. Everything below survives them moving again.
1. Identifiers your customer record has never held
An invoice that travels over a network needs an address to travel to: not a postal address and not an email, but a routing identifier a machine resolves. It is built from the tax identification number under a fixed scheme code, and applies to you and to every business you invoice. Beyond it, the Ministry’s mandatory field list asks for three things a tidy customer master will still be missing:
- A legal registration identifier and a code saying which kind it is — trade licence, Emirates ID, passport, cabinet decision. Not a free-text reference: a value and a type.
- The counterparty’s electronic address. The buyer’s routing identifier, not only your own. Your CRM has no column for it, and it has to be obtained per customer.
- Each tax-group member’s own identification number, not the group representative’s. A single number held at group level is the wrong shape and will validate for the wrong entity.
A record can be perfectly clean and still lack all three: nothing before now asked for them.
2. Eight questions about a transaction, expressed as one field
Every invoice has to carry a transaction type: a short sequence of flags describing the kind of supply. The scenarios covered are free zone transactions, deemed supplies, margin scheme sales, summary invoices, continuous supplies, disclosed agent billing, e-commerce, and exports.
Read that as a systems problem rather than a tax one. Today the answers live in one person’s head at the moment the invoice is raised, as judgement rather than data. Tomorrow they are a field, set at the point the transaction is created, by someone in sales or operations with no reason to know what a deemed supply is.
A dropdown at the invoicing screen does not solve it, because by then the person who knew the answer has left the process. The flags have to be derived — from the customer record, the item, the destination, the contract type — so the upstream data has to be good enough to derive them from. That is a design job, and it belongs at order entry.
Two of the eight catch companies who believe they are simple. Continuous supply covers any retainer, subscription or maintenance contract, which most service businesses have and have never classified as anything. Disclosed agent billing applies whenever you invoice on behalf of someone else, and almost no system can set it.
3. The line has to carry more than a price
Each line needs its own identifier, a quantity, a unit of measure expressed as a code, an item name and description, a net price, a gross price before discount, the quantity that price applies to, the line total, and its own tax amount in dirhams. Three of those are routinely missing.
- Tax per line, in dirhams. Many systems compute tax on the document total and apportion it back for display. That works on paper and fails validation: the arithmetic has to hold at line level, in dirhams, even when the invoice is in another currency.
- Unit of measure as a code. Your item master says “box”, “pcs”, “each” and “carton” as free text. Those become codes from a controlled list, and it cannot be done by find-and-replace, because the same word means different quantities to different departments.
- Gross price and price base quantity. A system storing one discounted price and nothing else cannot express “1,200 dirhams per 100 units, less 10 per cent” as structured data. That is a schema change, not a configuration one.
The PINT specification the UAE profile is built on is a contract, and a contract is worth what its least reliable field is worth.
4. Several document types, not one object with a note
The framework recognises distinct document types: tax invoices and their credit notes, commercial invoices for exempt or out-of-scope supplies, and self-billed invoices and credit notes where the buyer raises the document. Plenty is out of scope too — sales to consumers, exempt financial services, international passenger transport, sovereign activities — and intra-group transactions have a grace period.
The consequence is expensive. If your ERP has one object called an invoice, distinguished by a note or a naming convention in the reference field, the classification lives in your finance team’s heads rather than the database. Making it explicit is a data model change, and those are not made in the week before a deadline.
Self-billing surprises people. Where a large customer already raises the document on your behalf, your system has to receive and reconcile rather than issue — a different integration from the one you were planning.
5. What an accredited provider does not do
There are now dozens of accredited service providers, with more in final assessment, and the Ministry publishes the list. Picking one is the part everybody starts with and the part that matters least.
A provider validates, converts and transmits. It will tell you a file was rejected. It will not tell you a customer has been trading under a name that does not match its trade licence since 2019, and it cannot invent a unit code for an item that never had one. Providers move data. They do not fix it.
The questions worth asking one are narrow, and none is about compliance: which fields you map and which must arrive correct, what a rejection message tells us, whether we can run in parallel on live data before cutover, and what happens to the archive if we leave.
Choosing the provider first feels like progress because it produces a contract and a plan. What it does is set a date against work nobody has scoped — the pattern behind the technology decisions companies pay for twice.
6. How to score what you already issue
The earlier post said to pull a month of real invoices, including the awkward ones. This is what to score them against once you have them.
Mark each invoice against the four groups above, honestly:
- Identity. Could it be addressed with no human looking anything up? Failed if the buyer’s electronic address or registration type is unknown.
- Transaction type. Could the eight flags be set from data already in the system when the order was taken? Failed if a person had to decide.
- Line detail. Does every line carry a unit code, a gross price, a base quantity and its own tax in dirhams? Failed if any line is short.
- Document type. Is this a tax invoice, a commercial invoice, or a self-billed document, and does the system say so in a field?
The output is four percentages rather than an opinion, and they behave differently. Identity and line detail are grind: slow, cheap per record, done once. Transaction type is design work and usually the long pole. Document type is a schema change, scheduled around a month end.
Two weeks of this tells you whether the rest is a quarter of work or a year, and I would not let anyone quote without it — the same argument as establishing what is true about a system before committing to a price.
7. Why this is worth doing even if the dates move again
Strike every sentence about the mandate from this article and something useful still stands: a company that can describe its own transactions precisely enough for other software to act on them with no human in the middle.
Automated reconciliation needs it, so does reliable management reporting, and so does any attempt to put a model near your operational data — a system that cannot say unambiguously what a transaction was will not answer questions about it reliably either, the failure behind the four questions to ask before connecting a model to a live system.
The mandate is a deadline attached to overdue work. Turning it into a field-level plan somebody can execute is most of what I do as a fractional CTO, and the Ministry’s programme pages are worth reading directly rather than through a vendor summary.
If scoring what you already issue shows the gap is extraction rather than data entry — the identifiers and line detail sitting inside documents nobody reads by machine — that is its own build, separate from the accounting change: document intelligence, which my company Tothiq does.
Frequently asked questions
Who in the company can actually answer the eight transaction questions?
Usually one person, and usually not the person raising invoices: a senior accountant who has applied the treatment by habit for years and has never written the rules down. The exercise that works is sitting with them and a hundred real invoices, converting each judgement into a rule expressed in fields that already exist. Anything that cannot be expressed that way is a data gap upstream, and that list is the specification for the project.
Our units of measure are free text. How much work is that really?
More than it looks, because the mapping is not one to one. “Box” means twelve to the warehouse and twenty-four to a different product line, and both entered the same word. The exercise is not translating words into codes, it is establishing what quantity each item is actually sold in and coding that. Budget on the item count, and start with whatever covers the top eighty per cent of invoice lines.
Does this mean replacing our ERP?
Rarely, and it is worth resisting a supplier who says otherwise. Most of what is missing is fields and classification rather than capability. The genuine cases for replacing are a system that cannot hold tax at line level at all, and one whose vendor has no roadmap and no version you can upgrade to. Both are real, both rarer than the sales conversation suggests, and both visible from the scoring exercise rather than from a demo.
What if our invoices are in a currency other than dirhams?
The document can be in your accounting currency, but tax amounts have to be expressed in dirhams, including at line level. Your system needs a defensible exchange rate held against the document rather than applied at reporting time, and the arithmetic has to reconcile in both currencies. Systems that convert only in the reporting layer pass on screen and fail in the file.
How long does the field work take?
For a mid-sized company with one accounting system and clean records, three to four months, of which the integration is a few weeks. With two or three systems, records nobody has audited, and transactions needing human classification, it is a year — and the first honest estimate only exists after the scoring exercise. Anyone quoting a duration before seeing your data is quoting for a different company.