Trial balance to financial statements

The ledger is the only source

Every financial statement a business produces is a rearrangement of the same underlying data: a list of postings to accounts. Nothing else is in there. If a number on a balance sheet looks wrong, the cause is always one of three things - a posting that should not have been made, a posting that was never made, or a posting that landed in the wrong account. Understanding the route from posting to statement is mostly a matter of following that chain backwards.

Double-entry means each transaction touches at least two accounts, and the debits equal the credits. The convention is arbitrary but consistent: debits increase assets and expenses, credits increase liabilities, equity and income. This holds the accounting equation in place - assets equal liabilities plus equity - because any entry that changes one side changes the other side or cancels itself within the same side. A cash sale debits cash and credits revenue; revenue closes into equity at period end, so both sides move together.

The trial balance is the list of every account with its net debit or credit balance. It balances because of how entries are recorded, not because the books are right. This distinction gets lost more often than it should.

A balanced trial balance proves very little

The trial balance detects one narrow class of error: an entry where the two sides do not agree in amount. Modern systems make that error nearly impossible, which means a balanced trial balance in an ERP carries almost no information. It is a structural property of the software, not evidence about the accounts.

Errors that survive a balanced trial balance are the ones that matter. A transaction posted to the wrong account of the correct type - a repair charged to an asset account rather than an expense - leaves the totals untouched and misstates both profit and the balance sheet. A transaction never entered at all leaves nothing to detect. Compensating errors, where an overstatement in one place offsets an understatement in another, are rarer but do happen, particularly around manual reclassifications made near the end of a period. Reversed entries, where debit and credit are swapped, also balance perfectly.

• Wrong account, correct amount and correct side - balances, misstates
• Omitted transaction entirely - balances, understates
• Debit and credit reversed - balances, doubles the error
• Two independent errors that happen to offset - balances, hides both

Chart of accounts and where trails are lost

The chart of accounts is the list of buckets. It usually carries a numbering scheme by type - assets, liabilities, equity, income, expenses - with sub-ranges for classes within each. The structure matters less than the discipline: an account should mean one thing, and that meaning should not drift.

Audit trails are rarely lost in the ledger. They are lost in the mapping layer - the rules that decide which account a sale, a purchase, a stock movement or a payroll run posts to. When that mapping lives in configuration that can be changed without a record, two transactions of the same kind can land in different accounts months apart and nothing in the ledger explains why. The fix is unglamorous: version the mapping, record who changed it and when, and make the account on the posted entry a stored fact rather than something recalculated at report time.

Subledgers and control accounts

The ledger carries a single line for receivables. The detail - which customer, which invoice, how old - lives in a subledger. The same pattern applies to payables, inventory, fixed assets and payroll. Each subledger must reconcile to its control account in the general ledger, and if it does not, one of them is wrong.

Reconciliation breaks in predictable ways. Someone posts a manual journal directly to the receivables control account, bypassing the subledger. Inventory is valued on one basis in the stock module and another in the ledger. A fixed asset is disposed of in the register but the ledger keeps depreciating it. Payroll accruals are posted gross in one place and net in another. In Skyline Nexus, the receivables, payables, inventory and fixed-asset subledgers post to their control accounts through the same entry path, and manual journals to a control account are flagged rather than silently accepted - the entry is still possible, because sometimes it is genuinely needed, but it is visible.

Period close

Between the raw postings and the statements sits the close. Accruals recognise expenses incurred but not yet invoiced; prepayments push already-paid costs into the periods they belong to. Depreciation allocates asset cost across useful life. Foreign-currency balances are revalued at the closing rate, with the difference taken to profit or loss depending on the item and the standard being applied.

Cut-off is the quiet one. A goods receipt dated in one period and invoiced in the next, a sale shipped on the last day and recorded on the first day of the following month - these do not break any balance, they just move profit between periods. Getting cut-off right depends on document dates being the real dates and on periods being lockable, so that once a period is closed, entries stop arriving in it.

From trial balance to the statements

Sorting the trial balance by account type produces the statements almost mechanically. Income and expense accounts sum to the profit or loss for the period. Asset, liability and equity accounts form the balance sheet. The two are joined by retained earnings: at period end, the net of income and expenses is closed into retained earnings, which sits in equity on the balance sheet. That is the bridge, and it is the reason the balance sheet balances after the profit and loss account is drawn.

A practical consequence: if the balance sheet does not balance after close, the fault is almost always in the closing entry or in an account whose type is misclassified, not in the arithmetic. An account flagged as an expense when it should be a liability will appear in the wrong statement and leave a gap of exactly its balance.

What audit-grade honestly means

The phrase is used loosely. Concretely, it means a posted entry cannot be altered - a correction is a new, dated, reversing entry that references the original, and both remain visible. It means document numbers are issued in an unbroken sequence per series, so a missing number is a question that has to be answered. It means the system records who created, approved and reversed each entry, and when, and that this history cannot be edited from the application. It means closed periods reject new postings.

Skyline Nexus posts journals immutably, keeps sequential numbering per document series, and records the change history on entries and on the account mapping. We will state the limit plainly: no software makes books correct. It can make wrong entries visible and traceable, and it can prevent quiet edits. Judgement about what should have been posted remains with the people doing the accounting.

Multi-currency and multi-branch

Transactions in a foreign currency are recorded in both the transaction currency and the functional currency, at the rate on the transaction date. Monetary balances are retranslated at the closing rate; non-monetary items generally stay at historical rate. Keeping the original amount alongside the converted one is what makes a foreign-currency balance auditable later - without it, the conversion cannot be re-checked.

Consolidation across branches or legal entities is the same trial balance logic applied to several ledgers. Balances are translated to the presentation currency, then intercompany balances and transactions are eliminated so that a sale from one branch to another does not appear as group revenue. Branch-level reporting and consolidated reporting need the same postings tagged consistently; retrofitting a branch dimension after the fact is far harder than carrying it from the start.