Surviving an FTA Audit With the ERP You Already Have
· 12 min read · Faceela
The letter arrives and the first thing that happens is not panic. It is a meeting.
In that meeting somebody says the system has everything, and somebody else — usually the person who actually closes the month — goes quiet. That silence is the whole subject of this article. The finance manager knows something the meeting does not: that a meaningful share of the numbers in the last four VAT returns were arrived at by a process the system did not record.
Not fraudulently. Almost never fraudulently. A reclassification done in a spreadsheet because the ledger would not accept it. A monthly adjustment carried forward because someone worked it out once and everyone has repeated it since. A credit note issued against a customer rather than an invoice. An import entry keyed from a broker's PDF. Each one defensible on its own. Collectively, a version of the truth that lives in the space between the ERP and the people operating it.
An audit is the event that closes that space.
This is about which of the questions you will be asked your system can answer on its own, and which ones it cannot — quietly, without ever telling you.
An audit is a reconciliation, not an inspection
The mental model most people carry is that an auditor arrives to look for something wrong. That is not what the process feels like from the inside.
What happens is a chain of reconciliations, each one tying a summary figure to the thing beneath it, until either the chain holds or it breaks somewhere. Roughly:
The declared figures on the return tie to the ledger accounts. The ledger accounts tie to the transaction listing. The transaction listing ties to individual documents. The individual documents tie to the underlying commercial reality — the delivery, the contract, the payment, the customs entry.
Every step in that chain either holds or it does not. And the ones that break are almost never the top of the chain, because the top is where all the attention goes. They break three or four links down, at the point where a summary was produced by a person rather than by the system.
The four questions underneath everything
Strip away the format and the paperwork and an audit is asking four things.
Is your output tax complete? Did every supply you made get invoiced, at the right treatment, in the right period? Note the word complete — this is a question about what is missing, and missing things are structurally harder to evidence than wrong ones.
Is your input tax entitled? Every recovery you claimed has to be supported by a valid tax invoice addressed to you, for a supply used in your taxable activity, in the period you claimed it.
Are your treatments right? Zero-rated, exempt, out of scope, reverse charge, standard-rated. Not by convention but by rule, and defensible per transaction rather than per customer.
Does the period line up? Was the tax point where you put it, particularly at the boundaries — the invoice raised in one month for a delivery in another, the advance payment, the retention released two years after the work.
Every specific request you receive is one of those four wearing different clothes.
What your ERP can genuinely produce
Give a properly configured system its due. The following ought to come out of the database with no human intervention at all, and if any of them requires an analyst and an afternoon, that is a finding about your configuration rather than about the auditor.
A transaction-level listing of every sales and purchase document in a period, with tax code, net, tax and gross per line. A trial balance that ties to it. Document-level drill-down from any total to the entries beneath it. A tax code summary reconciling to each box of the return. Sequential document numbering with no gaps. The full text of any specific invoice you are asked for, including the ones cancelled or credited. Counterparty details, including registration numbers, as they were at the time. An export in whatever prescribed audit file format is required, produced by pressing a button rather than by assembling it.
If your system does that, the mechanical part of the audit is roughly a day of work. Most of the pain in most audits is not here.
What it silently cannot
This is the list that matters, because in every one of these cases the system produces something. It produces a number, or a report, or a document. It just is not the thing you needed, and nothing anywhere warns you.
The adjustment that never entered the ledger
Somewhere between your ERP's tax report and the figure typed into the return, there is usually a spreadsheet. It corrects a known misclassification. It backs out an intercompany elimination. It handles a category the tax codes never covered properly.
The ERP cannot show you this, because from the ERP's point of view it did not happen. Ask your finance team for the working file used to prepare the last four returns. If it exists, and it almost certainly does, then the reconciliation between your system and your declaration is a document held by one person, and the audit will ask for it. Better that you read it first.
The fix is not to hide the spreadsheet. It is to move each recurring adjustment into the ledger as a real, coded, repeatable entry so that next year's return comes out of the system whole.
The tax point that the system inferred
Your ERP stamps a document date and it uses that date to place the transaction in a period. In the great majority of cases this is right. The exceptions are where audits live: advance payments, continuous supplies, retention, milestone billing, goods delivered before invoicing, services performed across a period boundary.
The system will happily place all of these on the invoice date, because that is the only date it was given. It will not tell you that the delivery happened six weeks earlier. Producing the evidence that the tax point is where you said it is means tying the invoice to a delivery note, a certificate or an acceptance — and if that link is a reference typed into a description field, it is not a link, it is a hope.
Reverse charge and imports
Reverse charge produces an output and an input in the same period. Because the two usually net to nothing, nobody looks at them, and errors here can persist for years with no visible symptom.
The failure modes are consistent. Imports keyed from a broker statement into a journal, with the customs entry stored in the broker's email and not against the transaction. Services from overseas suppliers that were never identified as reverse charge at all because the person entering the invoice treated it as an ordinary cost. Goods entering a designated zone and later leaving it, where the treatment depends on a movement the ERP never modelled.
Your system can only apply reverse charge to transactions it knows are reverse charge. That decision happens at supplier or product level, made by a human, once, possibly years ago. Nothing revisits it. Manufacturers and importers carry the largest exposure here, because the volume of cross-border movement is high and the goods flow is where the accounting actually happens rather than in the finance module.
The credit note that references a customer, not an invoice
Ask your system to list every credit note issued last year alongside the specific invoice it corrects. Many ERPs, as configured in the field, cannot do it. The credit was raised against the account. The invoice number, if it is anywhere, is in the narration.
An auditor examining a large credit is asking a simple question: which supply was reversed, and was the reversal legitimate and in the right period? If the answer requires someone to remember, you have a problem that scales with the number of credit notes you issue. Under structured e-invoicing this stops being merely awkward, because a credit note has to reference its original in a field before it can be transmitted at all.
Documents stored somewhere other than the transaction
You will be asked for specific invoices, purchase invoices in particular, and the request will be selective: give me these eleven. If your supplier invoices are in a shared drive organised by month, in an email archive, or in a filing cabinet, the retrieval is a person-week and it looks exactly like disorganisation from the outside.
The test is simple. Pick a purchase transaction at random from three years ago and try to open the supporting document from within the transaction, in under a minute. Then do it for one from a company you acquired, or from before your last system migration. That second one is where most businesses discover that their history did not travel with them, which is one more reason data migration is where ERP projects go to die rather than a technicality to be handled at the end.
The entity boundary
If you run more than one legal entity — and if you have both a free zone company and a mainland company, you do — the audit is of one registered person, not of your group. Your management reporting almost certainly consolidates. Your VAT position must not.
The specific failure is a transaction booked in the wrong entity, or a shared cost allocated by a spreadsheet rule that produces the right group total and the wrong entity-level tax position. The ERP will report exactly what it was told. Getting this right is a configuration decision taken at the beginning, and the differences between free zone and mainland treatment run deeper into the chart of accounts than most implementations allow for.
Who changed what
The last one is the quietest. An auditor may ask whether a posted document can be modified, and by whom.
In a large number of UAE installations the honest answer is that several people can, because the permission was granted to solve a problem in a hurry and never withdrawn. If posted documents are editable and there is no audit trail of the edits, the integrity of every reconciliation above rests on trust rather than on evidence. Check who holds that right in your system this week. It is a ten-minute task and it is frequently the most alarming thing anyone finds.
The two-column table worth building
Before an audit is announced, not after, build this for your own business. One row per question you expect. Two columns.
| Question | Where the answer comes from |
|---|---|
| Return box tied to ledger | System report, or a spreadsheet held by one person? |
| Ledger tied to transaction listing | System, or a manual journal nobody can source? |
| Tax treatment per transaction | A configured rule, or a convention in someone's head? |
| Tax point at period boundaries | Linked to a delivery or certificate, or inferred from the invoice date? |
| Reverse charge population | Flagged by rule, or by whoever keyed the supplier invoice? |
| Credit note to original invoice | A field, or a sentence in a description? |
| Supporting document retrieval | From the transaction, or from a drive? |
| Entity attribution | Enforced by the system, or corrected in consolidation? |
Fill in the right-hand column honestly. Anything on the right that names a person rather than a mechanism is your exposure, and it is exposure of a particular kind: it is invisible in every report the system produces, which is why it survives so long. It is the same illusion that makes a green dashboard misleading rather than merely wrong — the number is present, so nobody asks how it got there.
Rehearse it, on a period you have already closed
The single most useful preparation available costs about two days and requires nobody's permission.
Time it. Write down every place where the answer required a human being. That list, in priority order, is your remediation plan, and it will be shorter and more specific than any generic compliance checklist you could buy.
Do it again after any material change to the system, and certainly after go-live on e-invoicing.
What e-invoicing changes about all this
It tightens the loop considerably, and mostly in your favour.
Under the phased mandate published by the Ministry of Finance — appointment of a provider by 30 October 2026 and go-live on 1 January 2027 for businesses at AED 50 million or more, appointment by 31 March 2027 and go-live on 1 July 2027 below that, with a penalty of AED 5,000 per month for non-compliance — a large part of your output-side data reaches the authority in structured form, per document, as it is issued.
That has two consequences worth thinking about now.
The first is that output completeness largely stops being an argument. The data is already there, in a form nobody has retyped.
The second is less comfortable. Once transmission is per-document and structured, the difference between what your ledger says and what the network received becomes a visible, computable number. If you have been living with a reconciliation gap that the periodic return absorbed, it will not be absorbed any more. That is the case for closing the gap deliberately in the next few months rather than having it surfaced for you, and it is one of the things to raise with your provider during selection — what an ASP will and will not do for you has a direct bearing on what evidence you can produce later.
None of this replaces the input side, the treatments, or the tax point. Those remain exactly as manual as you have left them.
The short version
An audit does not test whether your ERP is modern. It tests whether the chain from your declaration down to a delivery note holds without a person in the middle of it.
Most systems in this market hold for the first two links and are carried by human memory for the rest.
Find out which link breaks in your business before somebody else does. If the answer turns out to be that the chain was never built — that the system records outcomes rather than the reasoning behind them — that is a scoping conversation about the ERP implementation itself, and it is a better one to have in a quiet quarter than in an audit response window.