Bookkeeping lessons · Accounting glossary

How do opening balances and cutover work?

A cutover brings reviewed balances into a new ledger at an agreed date while retaining the evidence that explains those balances.

Key takeaways: agree one cutoff; map the chart deliberately; reconcile unpaid detail to control totals; preview before confirmation; and keep old balances separate from genuinely new activity.

What is the difference between an opening balance and a cutover?

An opening balance is a starting amount. A cutover is the reviewed process that establishes where that amount came from and how new activity begins.

An account report can calculate its opening balance from earlier postings before a selected date. That calculation is not the same as installing a new ledger with verified historical balances. A cutover needs a source record, mapping decisions, supporting schedules and a defined boundary between old and new activity.

Without that boundary, the first month can mix closing balances from one system with transactions already included in them. The numbers may still balance while income, expenses or control accounts are duplicated. Decide the dates and populations before importing anything.

Which records should you prepare?

Prepare the reviewed trial balance and the detail needed to explain cash, control accounts and other material balances.

• The source trial balance and its exact cutoff date.
• The old account list and proposed mapping to the new chart.
• Bank balances and outstanding reconciliation items.
• Remaining unpaid customer and supplier documents supporting controls.
• Relevant asset, loan, capital and other supporting schedules.
• Known differences, unresolved evidence and reviewer decisions.

Do not silently guess a missing amount from the difference needed to balance. Record the gap and obtain the supporting information. A suspense treatment, if appropriate, needs a deliberate review and resolution plan; it is not a shortcut for making an importer show green.

How do you avoid counting unpaid invoices twice?

The unpaid schedule explains an opening control balance; it does not automatically instruct the new system to recognise the old transaction again.

If the opening trial balance already includes the receivable, posting the old invoice again as a new sale would add another receivable and another income amount. The schedule’s reference, party and remaining unpaid amount are essential evidence, but they must enter the new system using the correct opening mechanism.

Use the remaining amount at the cutoff, not necessarily the original invoice total. If an old document was partly paid, its outstanding amount is what supports the opening control. Retain the earlier payment history outside the new runtime where needed, rather than inventing it or posting it again without a reviewed migration design.

How should the cutoff date be applied?

State whether the opening represents the beginning or close of a date, then apply that rule consistently to all subsequent activity.

PHP Ledger’s current cutover stores balances at the close of its accounting start date, and ordinary later entries must use a later date. That is a product-specific boundary, not a universal convention. Read the installation and opening workflow for the release you use. A source balance taken at the start of a day cannot be combined casually with a close-of-day assumption.

Before confirmation, test a transaction at the boundary and one immediately after it in a fictional setup. Establish where each belongs. This simple check can expose a whole day of duplicated or omitted activity before real records are imported.

What does a good preview show?

The preview should expose mappings, errors, totals and unresolved items before it makes a ledger change.

1. Select the correct company, book and cutoff.
2. Map every source account to an intentional destination.
3. Review debit and credit totals and supported amount precision.
4. Reconcile each unpaid schedule to its control account separately.
5. Investigate rejected rows and missing fields.
6. Confirm the exact reviewed preview, then inspect the resulting journal.

Do not treat a preview as an invitation to repair the original source invisibly. If you correct a source mapping or amount, retain the reason and regenerate the preview. The final confirmation should refer to the reviewed content, so a changed file or draft cannot silently substitute different accounting.

What if the opening is genuinely zero?

A new business with no opening amounts can have an explicit reviewed zero opening rather than fabricated zero journal lines.

Zero is a statement about the business’s starting record, not a missing-data default. Confirm that there are no existing cash, debts, owner contributions or other balances to bring forward. The confirmation should remain traceable even when there is no nonzero journal to post. This avoids confusing an intentionally empty start with an unfinished setup.

The original 1,000.00 service and 125.00 expense exercise assumes exactly such a zero starting position. Its 875.00 closing cash is correct only under that assumption and the absence of other activity. Changing the opening cash changes the closing balance without changing the period’s service income.

How should an incorrect opening be corrected?

Use the opening workflow’s controlled correction path while its conditions still allow it; do not rewrite the source history directly.

In PHP Ledger, restarting a cutover is restricted to an owner, an open period and the absence of subsequent ordinary business activity. The original preview and register remain historical, with a linked reversal where required. Once later activity exists, a reviewed accounting correction is needed rather than pretending the original cutover never occurred.

These restrictions protect the records that now depend on the starting point. A later bank statement, document draft or posting can make a simple restart unsafe. Preserve the source and ask the reviewer how to resolve the discrepancy before importing another opening set.

What must be reviewed when converting opening debts?

Later detailed modules must reconcile to the retained controls without creating a second outstanding balance or recognising old income again.

The starter adds a reviewed conversion for existing domestic opening evidence, requiring explicit party mapping and exact agreement with the existing control-account basis. Ambiguous or already-used bases are rejected. Existing opening control balances need a separately reviewed transition; the foundation does not guess party identities from historical free text. That boundary is deliberate. A historical opening register and a current operational subledger serve different roles and cannot be merged safely by matching similar names.

Keep the source schedule available and resolve ambiguous identities explicitly. A successful trial-balance import does not finish the later customer or supplier migration.