Trial balance does not match after migration: how to find the cause

Zoho Books is a double entry system. If the opening balances you enter do not balance, it posts the difference to an account named Opening Balance Adjustments so that the books can stay in balance. Zoho's help says this account should be cleared by correcting the entries, or by moving the balance out with a manual journal once you know its nature.

A non-zero balance here means debits and credits at the migration date differ. Typical causes: a ledger left out of the opening entry, a bank or credit card balance entered with the wrong sign, a party balance imported with the opposite Dr/Cr, or receivable and payable totals that do not equal the control totals in Tally.

Fix this first. Everything else rides on it.

Transactions dated on or before the migration date are treated as opening-balance activity. In Zoho's migration process, they need to be synced from the Opening Balances page before the trial balance is accurate. If you imported invoices, bills or journals dated before the migration date and did not sync, the trial balance will look wrong.

Zoho's help also notes that the Balance Sheet may show a different adjustment figure from the Opening Balances page, since the report also includes these dated transactions. If the difference moves when you change a transaction date, this is your cause. Move such transactions to a date after the migration date, or sync them as per Zoho's instructions.

Avoid creating fresh transactions on the migration date itself. They can disturb the opening balance.

Compare at the level of main groups: capital, reserves, loans, current liabilities, fixed assets, stock, debtors, creditors, cash and bank, income, expenses. The group with a difference narrows the search. Within that group, compare ledger by ledger.

Patterns that help:

For businesses with stock, a large share of differences sits here. Zoho's migration guide says the inventory start date must be the same as your opening balance date, and opening stock is entered with a rate per unit for each item. If the start date is earlier or later, quantities and values will not tally.

Check quantity first, then rate. A correct quantity with a different rate points to valuation. Tally lets you choose methods such as average cost or FIFO for stock valuation, and the stock summary shows what Tally computes. If Zoho Books computes cost differently, the closing value will differ even when quantities are identical. Agree with your CA which basis the books follow, and compare on that basis.

Stock journals, manufacturing journals and physical stock vouchers in Tally have no one-to-one counterpart. If you brought history, see how those entries were represented, since they change quantity without a sale or purchase.

Tally often uses separate ledgers for each tax and rate, such as input CGST 9%, output IGST 18%. Zoho Books handles taxes through tax rates and system accounts. If you map several Tally tax ledgers to one account, the sum should match even if the detail looks different. Compare totals for input tax, output tax and the RCM and reverse ledgers, and compare against the GSTR-3B you filed.

Look at the sign of credit balances. GST input credit carried forward is an asset in the books. Check that it was not loaded as a liability, or the other way round.

TDS payable and receivable ledgers behave the same way. Compare them against the challans paid and Form 26AS.

Tally has voucher types that do not affect the books: memorandum vouchers, optional vouchers, post-dated vouchers and reversing journals. They appear in the Day Book and in exports but have no accounting effect until converted. If one of these was imported into Zoho Books as a real transaction, you will see a difference. If it was left out and later converted in Tally, you will see the opposite.

Also check for deleted or altered vouchers in Tally after you took the export. A late edit in Tally is a classic source of a small mismatch that appears out of nowhere. Freeze Tally, or note the time of the export and ask the team not to post backdated entries.

When you find the cause, fix it in the right place. If the fault is in the source data, fix it in Tally and reload, or correct the import file. If it is a mapping error, correct the mapping. A manual journal posted just to make the figures agree is a last resort, and must be explained in writing to the CA.

Keep a one-page note of every difference: the cause, the amount, the fix, and who approved it. At the end the note becomes part of the reconciliation your CA signs. It is also what you hand an auditor who asks why the opening entry looks the way it does.

If a mismatch persists after all this, the trace is usually quicker with two people: one reading Tally ledgers, one reading Zoho Books. We do this for clients every week.

• Clean the Tally masters before exporting. See the migration guide.
• Export the right reports, ledger-wise. See exporting from TallyPrime.
• Do a practice load in a test organisation and compare the trial balance before the real load.
• Compare at each year end if you bring multiple years, not only at the end.
• Keep a change log of anything corrected in the source after the export.

In the distributor migration we matched every ledger at each year end because mismatches were found and fixed in the practice load, not after go-live.