
Jay Sen Lon
October 2, 2026

Here's what usually happens with Emirates NBD, FAB, and ADCB statements at a UAE firm: three different habits, three different bookkeepers, and no single process anyone agreed on. One person retypes rows, another dumps the PDF into a converter and still codes everything by hand, and a third just powers through. If that sounds like your firm's actual workflow instead of the tidy process on paper, you're not alone, and there's a reason a real fix has been slower to land here than in other markets.
TLDR:
Emirates NBD, FAB, and ADCB dominate UAE client portfolios, yet each exports PDFs built for reading, not for import into Xero, QuickBooks, or Zoho Books. Emirates NBD's column layout changes between business and personal banking portals, breaking any template built for the other. FAB splits into conventional and Islamic account formats with different transaction descriptions and date conventions. ADCB often bundles multiple currencies or sub-accounts onto one PDF, forcing manual sorting before the numbers mean anything to the ledger. With no shared UAE export standard, bookkeepers repeat the same download, copy, and matching routine every closing cycle, for every account.
Pull up a real Emirates NBD statement next to a FAB and an ADCB one, and the differences show up before you even reach the transaction rows. Emirates NBD exports typically use transaction date, value date, narration, debit, credit, and running balance columns, but the column order and header labels shift depending on whether the export came from the business banking portal or the personal banking one. FAB's conventional account statements list transactions with English narrative descriptions and standard date formatting, while its Islamic account statements use profit terminology instead of interest and carry different reference codes in the description field. ADCB statements often stack several currency sub-accounts, AED, USD, and sometimes EUR, inside a single PDF, each with its own opening balance, transaction list, and closing balance before the next sub-account starts on the same or a following page. None of the three banks label these section breaks consistently, so a bookkeeper scanning for where one account ends and another begins has to read the fine print on every page, including the header.

Most UAE firms don't run one bank statement process. They run a handful of habits stacked on top of each other, depending on which bookkeeper touched the file and how much patience remained by month-end.
At one end sits manual entry: opening the Emirates NBD PDF and typing each date, description, and amount into Xero. Copy-paste feels faster but breaks formatting, so someone retypes half the rows anyway. Generic PDF-to-Excel converters dump raw text without knowing an ADCB fee line from a supplier payment. Bank statement extraction tools produce a clean CSV, but that CSV still needs manual coding to the chart of accounts. Full extraction and posting skips all five steps: transactions land coded, inside the accounting software, already.
Every UAE bookkeeper eventually asks this: can any of these banks just feed transactions straight into Xero, skipping statement processing altogether?
The answer depends on the bank and the account type. ADCB has a direct feed connection with Xero, so transactions flow into the ledger without a PDF ever entering the picture, as confirmed in the UAE banks with live Xero feeds. Emirates NBD and FAB are not on that list, so their statements still need to be downloaded and brought into the accounting software by hand, with bank statement extraction software handling that download-and-import step.
That gap is why bank statement processing exists as its own workflow step. Even at a firm with ADCB clients on live feeds, its Emirates NBD and FAB clients still need multi-page PDF bank statements converted into transaction-level data before coding and posting.
General VAT records must be kept for five years, corporate tax records for seven, and real estate records for fifteen, per the UAE tax record-keeping requirements matrix. That clock runs from the end of the tax period, not the audit date, so a three-year-old bank statement can still be the document an FTA reviewer asks for tomorrow.
This changes what "done" means. A matched ledger balance confirms today's books, but firms need every Emirates NBD, FAB, or ADCB statement stored, coded, and retrievable years later, not summarized into a monthly total. Manual re-entry adds compliance risk too: each hand-typed transaction is a place the digital record can drift from the source document, and drift is exactly what an FTA audit catches.
A single Emirates NBD or ADCB statement rarely tells the whole story. UAE holding structures and free zone setups mean one client group might run three or four legal entities, each with its own account, sometimes across all three banks at once, a challenge covered in depth for multi-entity accounting software options. Add international trade and the currency mix widens further: AED sits alongside USD, EUR, or GCC currencies on the same statement, each needing separate FX handling, the same challenge tackled by multi-currency invoice processing software, before anything reaches the chart of accounts.
Ten entities across Emirates NBD, FAB, and ADCB means ten formats, ten reconciliation cycles, and ten currency conversions to track every month, not one problem repeated ten times but ten separate problems layered on top of each other. A process built for one currency or one entity at a time won't hold up against that load.

How AI-based document processing extracts and categorizes bank statement data
Basic OCR reads a bank statement and returns text: rows of characters roughly where the columns sat, with no understanding of what any of it means. It cannot tell an ADCB fee line from a supplier payment, or a debit column from a credit column when spacing changes mid-page.
AI-based document processing reads structure, not merely characters. It identifies each transaction as a record: date, description, amount, and running balance, the same fields covered when you convert a bank statement to Excel, then classifies debit or credit based on context, not column position. It also matches the payee against a chart of accounts, applies UAE VAT invoice automation treatment where relevant, and assigns an account code, the same coding a bookkeeper would apply by hand.
This matters most on multi-currency, multi-account statements, where fields split across sub-accounts or one PDF holds several currencies. Structure-aware processing keeps transactions grouped correctly by account and currency instead of flattening everything into one list.
For a firm sorting through Emirates NBD, FAB, and ADCB statements every month, the choice comes down to volume and how many currencies or entities sit on top of it.
| Method | What it does | Key limitation | |
|---|---|---|---|
| Manual entry | Bookkeeper types each line from the PDF into the ledger | Slowest option, highest error risk, doesn't scale past a handful of accounts | |
| Generic PDF-to-Excel converters | Dumps statement text into spreadsheet rows | No transaction understanding, still needs manual coding to chart of accounts | |
| Dedicated bank statement converters | Produces a clean, structured CSV of transactions | Stops at the CSV, requires manual import and coding into the accounting software | |
| AI document processing | Extracts, classifies, codes, and posts transactions directly | Requires review of low-confidence transactions before publishing |
Once statements stack across multiple entities and currencies, coding becomes the bottleneck, not extraction, which is where converters that stop at a CSV still leave the real work undone, a gap also visible in Zoho Books invoice automation for UAE firms.
Skip the clean sample statement when testing a tool. Start with the messiest Emirates NBD or ADCB PDF on file: the longest one, the one with mixed currencies, the one with a sub account buried on page nine. If a tool handles that, it handles the rest.
A few checks before rolling out firm-wide:
Skipping these steps is how firms end up trusting a tool that quietly drops transactions from account three of a ten-entity statement.
Tofu is one way to run the workflow described above. Upload an Emirates NBD, FAB, or ADCB statement in PDF or image format, any length, and Tofu extracts every transaction line, predicts the account code, tax treatment, and tags, then publishes to Xero, QuickBooks Online, or Zoho Books, all widely used among UAE accounting firms.
Tofu extracts and codes; matching transactions against the ledger still happens inside the accounting software. For firms with related entities across all three banks, Tofu builds separate coding logic per client, so one entity's rules never bleed into another's, as shown in the case of a Dubai firm scaling to 4,800 extractions.
Try Tofu on the longest, messiest statement in the queue and compare the output against a manual pass.
Every bank you work with adds its own quirks, and stacking entities and currencies on top only makes the gaps more obvious. The fix isn't one more manual habit, it's giving extraction and coding a process that scales with your client list. Curious what that looks like on your own files? Book a Tofu demo and bring the statement that's given you the most trouble.
Each bank exports PDFs in a different format. Emirates NBD's column layout moves between business and personal portals, FAB separates conventional and Islamic account formats, and ADCB bundles multiple currencies into a single PDF, so no single template handles all three. Without a shared UAE export standard, every tool that relies on template matching breaks on at least one of the three, which is why firms end up with three different habits instead of one process.
A dedicated converter produces a clean CSV of transactions but stops there. You still manually code each line to the chart of accounts before anything reaches Xero or Zoho Books. AI document processing like Tofu extracts transaction lines, predicts account codes, tax treatment, and tags, then publishes directly to the accounting software, so the manual coding step is gone instead of just moved.
See the FTA record-keeping section above for the full breakdown by record type. The short version is that a coded, retrievable statement matters more than a matched balance.
You can upload the full PDF without splitting. Tofu's structure-aware extraction keeps transactions grouped by sub-account and currency instead of flattening everything into one list, so each currency section is processed independently and published with correct FX handling to Xero, QuickBooks Online, or Zoho Books.
Start with the most difficult statement in the queue, whether that is the longest one, the one with mixed currencies, or the one with a sub-account buried on page nine, and never a clean sample. Confirm every transaction extracts across all pages, verify each currency is grouped correctly, and run one full month in parallel with your existing process before retiring manual entry. Tools that handle your messiest file will handle the rest; tools that drop account three of a ten-entity statement will do so quietly until month-end.