Producing the VAT Return From the System Instead of From a Spreadsheet
Almost every UAE company has an ERP that could produce the return and files from a spreadsheet anyway. The spreadsheet exists because of a handful of specific transactions the system was never told how to treat — and each of those is a two-hour fix that nobody has two hours for.
· 8 min read · Written by Faceela Research & Editorial Team
The accountant runs the VAT report out of the ERP, exports it to Excel, and then spends most of a day adjusting it. Two entries reclassified. A reverse-charge line added by hand. Some imports moved between boxes. A credit note that fell into the wrong period taken out and put back. Then the final figures are typed into EmaraTax, and the workbook is saved into a folder named for the period.
Everything about that is normal, and everything about it is a problem. The return is correct — probably — and the company cannot demonstrate why. The evidence for a filed position is a spreadsheet with manual adjustments and no audit trail, prepared by one person, on a laptop. If the return is ever questioned, the reconstruction starts from a workbook rather than from the ledger, which is exactly the position an FTA audit is uncomfortable to be in.
The interesting question is not why the spreadsheet exists. It is which specific transactions force it, because the list is short and every item on it is fixable — and it belongs on the same map as everything else the system has to be able to evidence, rather than being treated as a monthly inconvenience owned by one person.
What is settled, and what to read from your own account
The UAE VAT return is the VAT 201, filed through the Federal Tax Authority's EmaraTax portal. Filing deadlines are published by the Authority and the tax period that applies to a given registration is stated on that registration.
Do not take period lengths, deadline arithmetic or box definitions from an article, including this one. They are stated in your own EmaraTax account and in the Authority's own guidance, and they are the sort of detail that a secondary summary gets subtly wrong. Checked against the Federal Tax Authority's VAT returns page on 9 September 2026, which publishes filing deadlines and directs filers to EmaraTax.
Nothing below depends on those specifics. The systems work is the same whatever your period is, which is why it is worth doing now rather than after the next deadline.
The transactions that force the spreadsheet
In practice, the manual adjustments cluster into six categories. If you fix these, the report comes out right and the workbook disappears.
Imports and the reverse charge. Goods imported into the UAE and services bought from abroad have to appear on both sides of the return. Most systems can do this with the right tax code and most implementations did not configure it, because the person setting up the tax codes was working from a chart of accounts rather than from a return. This is the single most common source of manual entries, and it is a configuration task rather than a process one.
Customs and the difference between duty, import VAT and the declaration. Import VAT recorded against the wrong document, at the wrong value, or in the wrong period is the second most common. The value the Authority expects and the value on the supplier invoice are not always the same figure, and the mechanics of that are set out in how duty and import VAT actually land.
Free zone and re-export movements. Goods that never entered the local market, transfers between zones, re-exports. Whether a movement is in scope, out of scope, or zero-rated is a question about the movement rather than about the customer, and most item and customer configurations answer it by defaulting to whatever the salesperson chose.
Recharges and disbursements. The costs you pass on to a client. Treated one way they carry VAT and treated the other they do not, the distinction is a legal one about who contracted with the supplier, and a system will follow whatever rule you gave it. If nobody gave it one, the accountant is applying the rule by hand every month — the exact situation described in how recharges and disbursements differ.
Advances, retentions and anything where the tax point is not the invoice date. Payments received before supply, amounts held back for a period, staged billing on long contracts. The date on which VAT becomes due is not always the date the document was raised, and systems configured on a simple invoice-date assumption will report the wrong period. On construction and contracting this is not an edge case, it is the normal state, and it is worked through in VAT on retention and advance payments.
Credit notes and corrections across a period boundary. A credit note issued in one period against an invoice in another. Whether it belongs in the current return or as an adjustment depends on rules nobody encoded, so it gets moved by hand.
Six categories. In most companies, three of them account for nearly all the manual work, and identifying which three takes one afternoon with last quarter's workbook.
The diagnostic that finds your three
Take the last filed return and the workbook behind it. For every manual adjustment, write one line: what it was, why it was needed, and how many minutes it took. Then group them.
The result is almost always concentrated. One company finds that every adjustment is an import. Another finds that the whole day is credit notes and period boundaries. A third finds it is one customer whose contract terms nobody encoded.
This is a one-afternoon exercise and it converts a vague complaint — the VAT report does not work — into a list of three configuration items with an owner and a date. That conversion is the entire trick, and it is the reason this problem persists: unexamined, it looks like an intractable feature gap, and examined, it is three tax codes and a rule.
What a defensible return actually requires
Four properties. A return that has all four can be defended without the person who prepared it.
Every figure traces to postings. Each box on the return must be reproducible as a query against the ledger — these documents, this tax code, this period, this sum. Not "the report gave this number". If somebody asks where a figure came from, the answer is a list of documents.
Adjustments are postings, not edits. Where an adjustment is genuinely needed, it belongs in the system as a journal with a narration and an author, not as a changed cell. This single discipline is what converts a spreadsheet-based process into an auditable one, and it usually costs nothing.
The same report, run again in six months, gives the same answer. This sounds trivial and it frequently fails, because reports built on live master data change when master data changes. A return report must be date-bounded and must not depend on a customer's current tax classification to reproduce a past period.
The reconciliation is stored with the return. Output tax on the return against revenue in the ledger. Input tax against purchases. The differences explained, in the system, at the time — not reconstructed later from memory, which is the general failure of any number whose lineage nobody kept.
The order of work
Do the diagnostic first. One afternoon, last quarter's workbook, three categories identified.
Fix the tax codes before anything else. Most of what looks like a reporting problem is a tax code that does not exist or is not applied by default on the right products, customers and suppliers. Defaults matter more than rules here, because a default is applied by the system and a rule is applied by a person who is busy.
Encode the decisions nobody wrote down. Which customers are zero-rated and on what evidence. Which recharges carry VAT. What happens with a credit note across a boundary. These are short written decisions, agreed once with your tax adviser, and then configured. Without the written version, the configuration is one person's interpretation.
Build the reconciliation as a report, not as a workbook. Output tax against revenue, input tax against purchases, run at any time, tied to postings.
Then run the two processes side by side for one period. System-produced return against the spreadsheet. Where they differ, one of them is wrong and you learn something either way. This is the only test that matters and it takes one period.
Keep the deadline in a calendar with an owner. Filing dates arrive whether the report is ready or not, and they belong on the same list as everything else the year requires on a cycle.
What not to do
Do not buy a tax reporting product to sit on top of an ERP whose tax codes are wrong. It will faithfully report the same wrong classification with a better interface, and it adds a licence and an integration to a problem that was three configuration items.
Do not attempt to eliminate every manual adjustment before filing anything. Some genuinely exceptional items will always be adjusted, and that is fine provided they are postings with narrations. The goal is not zero adjustments; it is zero adjustments that live outside the system.
And do not treat this as a finance-department problem. Most of the six categories are decided at the point of sale, purchase or import by somebody who is not in finance — which means the fix is a default in the system rather than a request for more care.
The short version
The spreadsheet exists because of six categories of transaction: imports and the reverse charge, customs valuation, free zone movements, recharges and disbursements, tax points that are not the invoice date, and credit notes across period boundaries. In your company, three of them account for nearly all of it.
Find your three by writing one line per manual adjustment on the last return. Then fix the tax codes and their defaults, write down the decisions nobody wrote down, and build the reconciliation as a report rather than a workbook.
A defensible return has four properties: every figure traces to postings, adjustments are journals rather than edits, the report reproduces a past period identically, and the reconciliation is stored with the return. Get those and the workbook is unnecessary rather than merely discouraged.
Read your actual periods and deadlines from EmaraTax and from the Authority's own guidance rather than from any summary. If the diagnostic turns out to be less obvious than an afternoon — which happens in groups, in free zones, and anywhere the contracts are complicated — that mapping is ordinary configuration work on the system rather than arithmetic on the return, and it is part of how we scope an ERP implementation.