Opening Balance Migration Guide

If you are moving a company’s books into BigLedger from another system, this guide is the order to bring the five kinds of opening balance across in — stock, customers, suppliers, cashbooks and the general ledger — what each import does with your file, and the six-number check that tells you the migration is complete.

Step-by-step migration process

The five areas are on three pages, in the order The migration sequence below explains. Load them in that order, then run the success check on this page before anyone posts a live document.

1. Stock balance upload, before go-live.
2. Customer outstanding (AR) balance upload.
3. Supplier outstanding (AP) balance upload.
4. Cashbook balance entry.
5. General ledger balance entry, last.

Opening balances: what the process is for

The opening balance process brings forward closing balances from your legacy accounting and inventory records into BigLedger. This ensures the new system reflects accurate stock levels, customer receivables, supplier payables, bank cash balances, and general ledger accounts from the exact day you transition into the new environment.

Opening balance areas: an overview

Opening balance setup involves transferring existing data for the following five key areas:

The migration sequence

To maintain data integrity and prevent reconciliation discrepancies, you must perform opening balance imports in the following sequential order:

[1. Stock Balance] ──> [2. AR Outstanding] ──> [3. AP Outstanding] ──> [4. Cashbook Balance] ──> [5. GL Balance]

Why this sequence is mandatory (data dependencies)

1. Stock Balance First: Sets up physical inventory quantities and unit costs. This establishes your stock ledger valuation, which is a prerequisite for reconciling the inventory control account in the General Ledger.
2. AR and AP Outstanding Second and Third: Creates historical customer and supplier invoice records. These documents are needed so that post-go-live payments and receipts can be matched and knocked-off against actual outstanding balances.
3. Cashbook Balance Fourth: Establishes cash drawer and bank account starting balances. Reconciles the bank sub-ledger before consolidating into the General Ledger.
4. General Ledger Balance Last: Posts every account the earlier steps did not. Stock, customer and supplier documents, vouchers and cash transfers each post their own accounts, with the other side in one opening-balance suspense code (a stock adjustment uses the stock adjustment account instead); the journal keys the rest of the legacy trial balance and clears both.

Before you fill in a template: how the file import reads your file

Steps 1, 2 and 3 all work the same way — you fill in a spreadsheet, upload it in the applet, and BigLedger turns each row into a document. Ten minutes here saves the afternoon most migrations lose to a file that comes back rejected five times for five different reasons.

The file is read by column name, not by position. Every value is looked up by its heading, so you can delete any column you are not using and leave the rest in any order. The templates ship with between 60 and 135 columns; an opening balance needs about ten of them, and deleting the other hundred changes nothing.

A heading BigLedger does not recognise fails the whole file before a single row is read. The upload checks the first row twice — once for headings that must be there, once for headings that should not exist — and reports ===> Wrong Columns: [...] and ===> Mandatory Columns Missing: [...]. No documents are created.

The cause is almost never a typo in the data: it is a spare column your team used for working notes, a heading someone rewrote into something friendlier, or the empty column Excel leaves to the right of a pasted range. Headings are matched exactly as printed, in capitals, so Branch_Code is both a wrong column and a missing mandatory one and you get both messages at once.

Which headings must be present depends on the document type, and the differences are not obvious from the templates:

ENTITY_CODE is on none of those lists, and that is the trap worth knowing about. A customer or supplier file whose entity column was renamed, or lost in a copy-paste, passes the header check and imports. The step that attaches customers and suppliers to the imported documents skips every row with no entity code, so you end up with outstanding documents that nobody owes — and unlike the other four failures, this one looks like success. Check the entity column is named ENTITY_CODE before you upload, not after.

Choose the right delimiter, and check the file you were given

The upload asks you which separator the file uses — comma, pipe, semicolon or tab — and it does not guess. Several templates ship in more than one flavour, and at least one is pipe-separated despite a name ending in .csv: MasterData_Upload_InternalPurchaseDebitNoteData.csv is the Purchase Debit Note template used in Step 3. Open it in a text editor before you start work on it. Upload a pipe file as a comma file and the entire heading row is read as one column, so every mandatory heading is reported missing and the whole row comes back as a wrong column — an alarming error message with a one-click cause.

AMOUNT_INCL_TAX beats UNIT_PRICE_INCL_TAX × QTY, silently

When a line carries both an amount and a unit price, the amount wins and the unit price is ignored. That is why neither column is mandatory on the two invoice imports — either route produces a line value — and why AMOUNT_INCL_TAX is mandatory on notes and vouchers, which have no quantity to multiply.

It also produces one of the harder opening-balance discrepancies to spot. On the Step 1 stock upload you fill in QTY and UNIT_PRICE_INCL_TAX. If the template you are editing still has an AMOUNT_INCL_TAX column carrying a figure from the legacy export, the stock value booked is that amount, not quantity × unit cost — the quantity on hand is right, the valuation is not, and nothing warns you. Delete the amount column from the stock file.

POSTING_STATUS is read once per document, from its first line, and must be exactly FINAL

Every one of the six imports accepts a POSTING_STATUS column, and what it does is worth understanding before Step 1 rather than after Step 3:

• Blank means DRAFT. The documents are created and nothing is posted; you finalise them by hand in the applet, one at a time.
• FINAL runs the real finalise, the same path as clicking FINAL on the screen — so stock moves, journals post, receivables appear. For a 22-branch stock load this is the difference between an afternoon and a week, and the Step 1 procedure (import as draft, then click FINAL) is the manual alternative, not the only route.
• The value is taken from the first line of each document only. On a multi-line invoice, a POSTING_STATUS on line 2 or 3 does nothing at all.
• The comparison is case-sensitive. Final or final is stored as written and never posts, and no error is raised anywhere — the documents simply sit unposted looking like a draft you forgot.

Where your legacy document number goes

The number you put in HDR_REF_NO becomes the imported document’s Reference, not its document number. BigLedger allocates its own running number to every document it creates, so an invoice you migrated as INV-2024-8891 will be listed under a BigLedger number with INV-2024-8891 in the reference field. When somebody asks after go-live “where has my invoice gone?”, the answer is to search the reference, not the document number. It is also why HDR_REF_NO is mandatory on all six imports: without it there is nothing tying the new document back to the record your customer is looking at.

What success looks like

Six numbers, and they either agree or they do not. Do this before anyone posts a live document.

1. Open the Opening Balance tab on the primary ledger (Chart of Account → Companies → your company → Ledgers) and look at its trial balance view. Total debits equal total credits. If they do not, nothing below is worth checking yet.
2. Open the Debtor Report applet, run the Outstanding Document Report as at the cutoff date, and compare its grand total with your legacy ageing total and with the receivables control account in the general ledger (GadgetSphere: DEBTOR-TRADE-RETAIL), not on the Opening Balance tab: that view shows the opening journal only, which leaves the control accounts out. Open the control code’s sub-ledger in Ledger and Journal › Sub Ledger and read its Journal Lines to the cutoff date; if some customers are non-trade or merchants, add those control accounts too. They must match to the cent. Exactly double means the control account was keyed into the opening journal as well.
3. Do the same with the Creditor Report applet against the payables control account (LIAB-SUPPLIER-TRADE).
4. Open the Cashbook applet, Cash Level. Set From to a date before the opening-balance cash transfers and To to the cutoff date: the screen starts at today → today, and lists only cashbooks with a transaction in the range. Confirm every row’s Closing is the reconciled bank balance — not zero — and that the number of rows matches the active cashbooks on the Cashbook listing. Read any missing cashbook in Query Cashbook Transaction (why Cash Level can leave one out).
5. Read the opening-balance suspense code’s sub-ledger the same way. It is zero at the cutoff date. Zero proves the journal cleared it, not that every document reached it: the journal check on one document of each type in Steps 2 and 3 proves that.
6. After the cut-off month’s Month End Processing, the stock account equals Historical Stock Balance at the cutoff date, once (why it waits for the close).

All six agreeing means the sub-ledgers and the general ledger tell the same story, which is the only thing this migration had to achieve.

If AR or AP is out, the difference is almost always a document that was imported but left in draft — filter the outstanding report by status before you go looking for a bad number.

If the control account is double the report, take it out of the opening journal (why). If the suspense is not zero, the journal did not clear what it held, or a document posted its other side elsewhere, usually to sales or purchases. If a cashbook shows zero, the bank balance went into the general ledger journal instead of a cash transfer, and Bank Reconciliation will carry that difference as a permanent variance until you fix it. If debits and credits do not balance, an account is missing from the opening journal rather than wrong in it; compare the account list against the legacy trial balance line by line.

Common mistakes

Each area’s common mistakes are on its own page, beside the steps they spoil: stock, customers and suppliers and cashbooks and the ledger. The one they share is a document left in draft, which is in no receivable or payable figure: after every import, filter the applet list for DRAFT (the POSTING_STATUS section says why).

Related documentation

• Financial Accounting Module Overview
• Ledger and Journal Applet
• Purchase Invoice (Internal) Applet — the import that books opening stock
• Bank Reconciliation Applet
• Chart of Account Applet
• Cashbook Applet
• Chart of Accounts Setup Guide