Migrating from Tally to Odoo in the UAE: Data, VAT and the Cut-Over Plan
Tally has run the books of half the SMEs in the UAE for a decade, and most of them have outgrown it. The move to Odoo is not hard, but it is unforgiving on two points: the chart of accounts you choose and the day you cut over.
Tally is the default accounting package for a large share of UAE SMEs, especially in trading, contracting and distribution, and it has done its job. The books are kept, the VAT return is filed, the auditor is familiar with it. The problems start when the business grows: a second branch, a sales team that needs a pipeline, a warehouse that needs barcodes, projects that need costing, a payroll that needs WPS files, an owner who wants one report across two entities.
This guide is the plan we use when moving a UAE business from Tally to Odoo. It covers what to migrate, how to map ledgers to a proper chart of accounts, how to handle VAT history and open items, and how to run the cut-over.
Key takeaways
- Migrate balances and open items, not history. Keep Tally read-only for the past and meet FTA record-keeping by retention, not re-entry.
- Design the Odoo chart of accounts for the business you are becoming, then map Tally ledgers to it. Do not copy Tally's ledger list into Odoo.
- Bring open receivables and payables across invoice by invoice, with VAT already accounted, so collections and the ageing work from day one.
- Cut over at the start of a VAT period, ideally the financial year, outside the busiest month, and after two reconciled test migrations.
- Run the first month with a tight reconciliation to the Tally closing position, then switch Tally off for entry.
What Tally holds, and what Odoo needs
Tally organises data as masters, such as ledgers, groups, stock items, units and godowns, and vouchers, which are the transactions. Odoo organises it as a chart of accounts, partners, products, locations and journal entries, with sales, purchase and stock documents sitting above the accounting. The two models overlap in the ledger but differ above it, which is why a straight export and import produces a mess. The table sets out the mapping we use.
| Tally object | Odoo equivalent | Migration approach |
|---|---|---|
| Groups and ledgers (chart) | Chart of accounts with account types | Design the Odoo chart first, then map each Tally ledger to an account; consolidate duplicates |
| Sundry debtor and creditor ledgers | Partners (customers and suppliers) with receivable and payable control accounts | Export as partner master with TRN, address and credit terms; one partner per legal entity, not per ledger |
| Stock items, units, godowns | Products, units of measure, warehouses and locations | Clean the item list, set product categories and valuation, load opening stock by location at cost |
| Outstanding bills (receivable and payable) | Open customer invoices and vendor bills | Load each open invoice with its date, due date, amount and VAT already accounted, against a migration journal |
| Trial balance at cut-over | Opening balance journal entry | Post the closing trial balance as the opening entry, with receivables, payables and stock replaced by their open-item and stock loads |
| VAT ledgers and classifications | Tax codes and tax grids in the UAE localisation | Map Tally VAT classifications to Odoo taxes; do not migrate VAT transactions, start fresh at a return boundary |
| Fixed assets register | Odoo asset models and assets | Load each asset with cost, accumulated depreciation and remaining life |
| Cost centres | Analytic accounts and plans | Map to analytic plans for branch, project or department |
| Historical vouchers | Not migrated | Retain Tally in read-only form; export key reports to PDF for the archive |
Design the chart of accounts, do not copy it
The most expensive mistake in a Tally migration is importing Tally's ledger list as the Odoo chart of accounts. Tally users create ledgers freely, so a ten-year-old company often has several hundred, including one per customer, one per bank charge type and a dozen variants of "Office Expenses". Odoo expects a compact chart with account types driving the balance sheet, the profit and loss and the tax reports, and with partners, products and analytics carrying the detail that Tally users put in ledger names.
Start from the Odoo UAE chart, add what your business and your auditor need, agree it with the finance team, then map every Tally ledger to one account. Customers and suppliers become partners against two control accounts. Cost centres become analytic accounts. Expense variants collapse to one account with the detail in the description or the analytic tag.
VAT history and the first return from Odoo
Do not migrate VAT transactions. Choose a cut-over date at the start of a VAT return period, file the last return from Tally for the period ending the day before, and file the next from Odoo. The opening balance entry carries the VAT payable or receivable position as a single balance, which is cleared when that last Tally return is settled.
The work is in the mapping. Tally's VAT classifications, which many UAE users customised over the years, need to map cleanly to Odoo tax codes: standard-rated sales and purchases, zero-rated exports and international services, exempt, out of scope, reverse charge on imports with input and output, and designated zone treatment if relevant. Have your tax adviser review the mapping before go-live, then run the first Odoo tax report against a parallel calculation for the first period. Odoo's UAE localisation produces the FTA return format from the tax grids, and from 2027 the same invoice data will feed the e-invoicing mandate through an Accredited Service Provider, which is far easier on a clean chart than on a migrated ledger list.
Open items: the part that must be right on day one
Receivables and payables cannot come across as balances, or the collections team loses the ability to see which invoices are open and the ageing becomes meaningless. Export every open invoice and bill from Tally with its number, date, due date, original amount, outstanding amount and partner, and load each as an open document in Odoo against a migration journal, with no VAT, since the VAT was accounted in Tally. The total must tie to the control account balances in the opening entry to the fils, and the ageing report in Odoo on day one should match the Tally ageing on the last day.
Stock follows the same logic: a count by location at cost, loaded as opening stock, with the total agreeing to the inventory balance in the trial balance. If Tally's stock value has drifted from physical reality, which is common, this is the moment to correct it and book the difference before cut-over, not after.
The cut-over plan
- Choose the date. Start of a VAT period, preferably the financial year, outside peak trading. For a December year-end that often means 1 January, with the VAT period aligned.
- Freeze the masters. Two weeks before, stop creating new ledgers, items and partners in Tally; anything new is created in Odoo after cut-over.
- Two test migrations. Load a full copy of masters, open items, stock and the trial balance into a test Odoo at least twice, reconcile every control total to Tally, and have the finance team process real transactions in the test system for a week.
- Close Tally. Post the last entries, reconcile banks, run and save the closing trial balance, ageing, stock valuation and VAT report as PDFs.
- Final load. Migrate masters, open items, stock and the opening entry from the closing position. Reconcile again.
- Go live. Odoo for all entry from the cut-over date; Tally read-only.
- First month reconciliation. At the first month-end, prove that the opening entry plus the month's Odoo activity explains every balance, and that the tax report reconciles to the ledger.
Some businesses prefer a month's parallel run in both systems. It is safer for the books and exhausting for the team; two reconciled test migrations usually give the same confidence at a fraction of the effort. Our data migration checklist covers the general discipline in more depth.
Record-keeping after the move
The FTA requires VAT records to be retained for a number of years after the relevant period, and the auditor will want prior-year detail. Keep the Tally data and application available in read-only form, export the key reports for each closed year to PDF, and store both somewhere the finance team and the auditor can reach.
How Kaido approaches it
We begin with a review of the Tally data, not with Odoo. A day with the exports shows the ledger sprawl, the duplicate partners, the stock items with no movement for years and the VAT classifications that drifted. From that we agree with the finance team what to migrate, what to merge and what to archive, and we design the chart of accounts around the business's next five years.
The migration itself is scripted and repeatable, which is what makes two test runs practical, and every control total is reconciled to Tally in a signed-off schedule before go-live. If you are still deciding whether the move is worth it, our guide to the signs you have outgrown an accounting package applies as much to Tally as to QuickBooks, and our Odoo cost guide sets out what a project of this shape typically involves.
Outgrown Tally and planning the move?
Talk to a senior consultant before you export anything. We will review your Tally data, agree what to migrate and what to archive, and give you a cut-over plan aligned to your VAT period and your busiest month.
Book a discovery call →