The E-Invoicing Work Nobody Quotes: Fixing Your Own Data

Export every active business customer from your system into a spreadsheet. Add a column that says whether the tax registration number is present, in the right field, and fifteen digits. Sort by that column.

Most UAE finance teams doing this for the first time find somewhere between a fifth and a half of their B2B customer records fail on the first pass. Then they look at the ones that passed and find TRNs belonging to a different entity in the same group, TRNs typed with spaces, and one memorable record where the field contains a trade licence number because somebody in 2019 decided the two things were interchangeable.

That spreadsheet is your e-invoicing project. Not the connector, not the provider contract, not the workshop about the five-corner model. This.

The mechanics of the mandate and the provider decision are covered elsewhere: what the model is and what it changes about a sales invoice, and how to choose an Accredited Service Provider without regretting it. This piece assumes you have read those, or already know them, and goes straight to the part that takes the longest and appears in nobody's proposal: making your own data capable of producing a document that survives validation.

Why the data work is the long pole

A structured invoice is not a rendering of your invoice. It is a set of assertions, each drawn from a field, each validated by machine before the document is allowed to move.

The Ministry of Finance publishes the UAE profile as a data dictionary — a Peppol-based specification adapted for UAE VAT rules — defining well over a hundred data elements across invoice details, seller details, buyer details, document totals, tax breakdown and line items. Some are always mandatory, some conditional on the nature of the transaction, some optional. Read the dictionary itself rather than a vendor's summary, because the conditional fields are where implementations fail and summaries flatten conditionality into a bullet.

The uncomfortable arithmetic is this. Your current invoice template renders perhaps twenty-five pieces of information, several of them free text and none of them validated. The specification wants a multiple of that, in coded form, with internal consistency between them. Every field it wants that you do not currently hold in a structured, correct, reliably populated place is a data project with a person's name on it — and the projects run in sequence, because you cannot test tax determination until the item master is classified, and you cannot classify it until somebody has decided which of your transactions are genuinely zero-rated exports rather than standard-rated supplies a salesperson has always described as exports.

The dates, and what they mean for sequencing

The voluntary window opened on 1 July 2026. Businesses at or above AED 50 million in annual revenue appoint a provider by 30 October 2026 and go live on 1 January 2027; below that, appointment by 31 March 2027 and go-live on 1 July 2027; government entities on 1 October 2027. Take these from the Ministry of Finance's own e-invoicing pages rather than from a slide, because the appointment deadline has already moved once and the go-live date did not move with it.

If you are in the first wave, the appointment deadline and the go-live date are roughly two months apart, and nothing below can be completed in two months in a company of any size. The provider decision and the data work are parallel tracks, and the data track started later than it should have in almost every business I have seen.

The plan, in the order it has to happen

#	Workstream	What "done" looks like	Who owns it
1	Counterparty identity	Every active B2B customer has a validated TRN, structured address, and legal name matching the registration	Finance, with sales chasing
2	Your own establishment data	Each issuing entity's legal name, TRN, address and branch identity are correct and separated	Finance
3	Item and service master	Every sellable item has a code, a stable description and a tax classification	Operations and finance jointly
4	Units of measure	Every item's UoM maps to a code from the standard list, with the conversion factors right	Operations
5	Tax determination	Category and reason code derived by rule, tested on real transactions	Finance
6	Amounts and rounding	Line, tax and document totals reconcile arithmetically under the schema's rules	Finance and IT
7	Document references	PO, delivery, contract and corrected-invoice references live in fields	Sales and finance
8	The posting boundary	Draft means provisional, posted means final, and permissions enforce it	IT, signed off by finance
9	The failure loop	A queue, a status, a named owner and a daily routine	Finance

Workstreams one to four are data cleaning and can start today without any decision from a provider. Five to seven are configuration, dependent on decisions your own finance function has to make. Eight and nine are process and permissions, and they get postponed because they make people's jobs harder.

Workstream 1: counterparty identity

The TRN is not a text field

Put a validation rule on it. Length, numeric, no spaces. Then run the list past the FTA's TRN verification facility in batches, because format-valid and real are different things and the difference is a rejected document.

One legal entity, one record

The most common structural fault in a UAE customer master is a single record covering a group. "Al Something Trading" with a delivery address in Jebel Ali, invoiced sometimes through the mainland LLC and sometimes through the free zone entity, with whichever TRN the accounts team used most recently. Under a structured regime this record cannot be made correct, because it represents two taxable persons.

Splitting it is not a database exercise. It is a set of conversations with the customer's finance team about which entity is actually buying what, and it takes weeks of calendar time regardless of how fast anyone works. Start it first for that reason alone.

Addresses have to decompose

Your address field is one blob of text with line breaks in it. The schema wants components: street, city, emirate or country subdivision, country code. A machine cannot decompose "Office 402, Al Moosa Tower 2, SZR, Dubai" reliably and neither can a junior accountant at speed.

Structure your top counterparties by revenue by hand, structure the rest with a script and accept a rework rate, and make the structured fields mandatory on the customer creation form from a fixed date so the problem stops growing while you fix it. Your provider will also need a network identifier for each counterparty so it knows where to route the document; how that is discovered and stored is provider-specific, and worth pinning down in the contract rather than in testing.

Workstream 2: your own establishment data

This one is quick and is skipped constantly, because everyone assumes their own details are right. Check the legal name on the registration against the legal name in the system. Check that each issuing entity has its own TRN and that the system knows which entity issues which document — a group running mainland and free zone companies in a shared database has to get this right at document level, and it is one of several reasons free zone and mainland entities need genuinely separate configurations. Check branch handling under a single registration. Check that the address on your invoice template matches the address on the registration, because they diverge quietly when an office moves.

Workstream 3: the item and service master

Here is where the manufacturing and trading businesses lose their weekends.

A structured line item needs, at minimum, an identifier, a description, a quantity, a unit code, a unit price, a line net amount and a tax category. Look at your last hundred invoices and count how many lines have an item code at all. In most contracting and project businesses the answer is close to zero: the line is free text describing a milestone. In trading businesses it is high but inconsistent, because half the codes were created by import and half by hand.

Three problems to plan for.

The free-text line. Any process that produces an invoice line without an item behind it produces a line without a tax classification behind it. The document still goes — descriptions are text — but the tax category has to come from somewhere else, and "somewhere else" is a person choosing on the day. For project businesses this connects directly to whether the payment certificate is a real document inside the system or a spreadsheet that becomes an invoice by retyping.

The duplicate item. The same product under four codes because four people created it, each possibly carrying a different tax category. Deduplicate before you classify, or you will classify the same thing four times and get two different answers.

The description that is not a description. Item names like "AS PER ATTACHED" and "SUNDRY" pass no sensible review, and they land in your customer's system, where a machine will try to match them to a purchase order line.

Workstream 4: units of measure, the field everyone forgets

Your system has a unit of measure list. It contains "PCS", "Pcs", "pieces", "NOS", "No.", "EA" and "each", because seven years of people created what they needed on the day.

Peppol-based invoice profiles carry the unit as a code from a standard list — the UN/ECE Recommendation 20 list, in the general case. Confirm the exact list and any UAE-specific restrictions against the published data dictionary. Whatever it turns out to be, the work is the same: every unit you actually use maps to exactly one code, and every item points at the right unit.

Two traps sit behind this. The first is the item stocked in one unit and sold in another — cable stocked in drums and sold by the metre, sheet stocked in sheets and sold by square metre. The conversion factor has to be right, because quantity and unit code together assert something the price must be consistent with, and validation checks consistency.

The second is the unit that is not a unit: "LOT", "JOB", "SET", as used by contractors and fabricators. Each has to resolve to something on the code list, and the resolution is a business decision about how you describe what you sell, not a mapping exercise for whoever is doing the data load.

Workstream 5: tax determination by rule, not by convention

Most UAE ERPs I open have three tax codes and a convention held in one person's head. Under a validated regime the rule has to move into the system, distinguishing standard-rated supply, zero-rated export of goods, zero-rated by nature of the supply, exempt supply, out of scope, reverse charge and, where relevant, designated zone treatment. Categories other than standard-rated generally require a reason code.

Do not build this by writing rules from the legislation and applying them. Take a stratified sample of real invoices from the last twelve months — the odd ones, deliberately — and for each, write down what the system would derive and what the correct answer is. The gaps are your rule set.

The test that matters is negative: create a transaction that should be a zero-rated export and give it a delivery address inside the UAE. If the system happily issues it zero-rated because the customer record has always been treated as an export customer, determination is coming from the counterparty rather than from the supply, and it will be wrong on the day that customer buys something for local delivery.

Workstream 6: amounts, precision and rounding

This one surprises technical teams, because it looks like arithmetic and is therefore assumed to be fine.

The schema imposes internal consistency. Line net amount has to equal quantity times unit price, less line discount, within the rounding the specification allows. Tax subtotals by category have to sum to the document tax amount. The payable amount has to reconcile to the sum of the parts. Documents fail on this more often than anyone expects, for mundane reasons: a price held to five decimal places and displayed at two, a discount applied to the document rather than the line, a rounding adjustment posted as a plug on the total. Find your plugs before validation does — any process where a person adjusts a total by a few fils to match a customer's purchase order will generate rejections.

Foreign currency adds a second layer: the tax amount generally has to be stated in the local currency regardless of the invoice currency, at a defined rate. Check what your system does today when it issues a USD invoice carrying UAE VAT. In a surprising number, the answer is "nothing, because the VAT is calculated in USD and converted in the return".

Workstream 7: references, and the credit note chain

A structured credit note references the invoice it corrects, in a field. Not in a description line reading "as per inv 4471".

This means two things. Your credit notes have to be raised from the original document rather than created standalone, and the habit of cancelling and reissuing has to end. Once a document has been transmitted it exists outside your system, and the only way to correct it is forward.

The other references matter commercially rather than legally. Your customer's accounts payable system will match your document against their purchase order. If your PO reference lives in a free text remarks line because that is where the sales coordinator has always typed it, your invoice will arrive structurally valid and fail their matching, and you will spend the first quarter after go-live on the phone about it. Move it into the field that exists for it.

Workstream 8: the posting boundary

Somewhere in your permissions today is a right to edit or delete a posted invoice, granted years ago to solve a Thursday-afternoon problem. It has to come out, and the process that depended on it has to be replaced with something honest before go-live rather than during it.

Draft has to mean genuinely provisional and posted has to mean genuinely final, with the transmission attached to posting. That is a process change dressed as a configuration change, and it is one instance of a broader problem worth its own examination: who holds which permissions and why.

Workstream 9: the failure loop

Once documents are transmitted, some will fail. A rejection has to arrive back in your system, attach to the right document, appear in a queue, and be somebody's job before lunch. None of this exists in a standard ERP because none of it existed in your business. It is a screen, a filter, a daily routine and a named owner. Projects that treat e-invoicing as an export format ship without it and discover the accumulation at the first VAT return that will not reconcile.

How to know you are actually ready

Build the file before you need to send it. Take fifty real invoices from last month — including the ugly ones, the credit notes, the foreign currency ones, the ones with a manual rounding adjustment — and generate the structured document for each. Validate them against the published schema. Count the failures and read the error messages.

That exercise takes a week and tells you more than any readiness workshop. It converts an abstract compliance date into a specific list of records to fix, which is the only form in which this work ever actually gets done. It is the same discipline that separates the ERP projects that survive from the ones that die during data migration: profile the real data early, before anyone has committed to a date based on assumptions about it.

If you want a structured walk through the same ground before you commit resource to it, the e-invoicing readiness assessment asks these questions in order and tells you where the gaps are.