Trial balance

The trial balance is the arithmetic check on double-entry bookkeeping. For each account it sets out the opening balance, the period's debit and credit movement totals and the closing balance, and the two columns at the foot must agree. It is usually the first report opened during a close, because in one view it shows which accounts are unexpectedly large, which saw no movement at all and which are carrying the wrong sign. A general trial balance works at account level; a customer or supplier trial balance works at counterparty level, and that is the one reconciliation work normally starts from. Two features of the Turkish setting matter to a reader coming from elsewhere. Companies here work from a uniform chart of accounts, so an account code carries the same meaning from one company to the next; a local trial balance can therefore be read, and mapped into a group consolidation pack, without first learning a bespoke account structure. And the counterparty trial balance, cari mizan, is the nearest local equivalent of an AR and AP aging summary, with one difference that catches people out: it is cut by account and period movement rather than by days outstanding, so it tells you what each counterparty owes but not how old the debt is.

In reconciliation the trial balance is the entrance, not the answer. The gap between the balance your counterparty reports on their statement and the balance on your own ledger gives you the total difference to be explained. Where that difference comes from is invisible here, because the report carries totals rather than transactions. A debit total of 1,250,000 could be one invoice or a hundred; a credit total of 1,180,000 could be a single receipt or forty. So the step after spotting a gap is always to drop into the subsidiary ledger and the open item list. That is the level iFinances operates at: ledger records, bank statement lines and e-invoice data are matched line by line in one table, with everything that fails to match listed alongside a written reason.

The common mistake is treating a balanced trial balance as a correct one. It only proves that both sides of each entry were written. It does not prove the entry hit the right account, the right counterparty, the right amount or the right period. A receipt posted to the wrong customer leaves the trial balance perfectly in balance. Two offsetting errors leave it in balance too. The same trap applies at counterparty level: your balance agreeing with the balance your customer reports does not mean the lines underneath agree, because two unrelated errors of similar size can cancel each other out in the total while the detail stays wrong.