Opening Balances & Data Migration
Nobody starts accounting from zero. When Meridian Properties adopted REDA Financials, it arrived with a trial balance, tenants who owed rent, vendors waiting on payment, a bank account with money in it, and buildings already half-depreciated. Migration is the art of teleporting that state into the new system so that day one's books equal day zero's — no more, no less. This article is the map: what to bring, in what form, in what order.
First decision: the cutover date
Pick the date the old system stops being the truth and REDA Financials starts — ideally a period boundary (Meridian chose 1 January). Everything divides around it:
- Balances as of the cutover come in as opening entries.
- Open items at the cutover (unpaid invoices, undepreciated assets) come in as living documents.
- Transactions after the cutover are entered in REDA Financials only, from day one.
- Deep history before it stays in the old system's archive — migrating years of settled paper multiplies effort and adds nothing to your books.
The migration sequence
Order matters — each layer depends on the one before:
Foundations before any numbers
Entities, chart of accounts, accounting periods, document sequences, banks, tax setup, customers, vendors, products. This is ordinary setup, not migration — follow Your Setup Roadmap. Nothing below works until the master data stands.
The opening balance journal
Take the old system's closing trial balance at the cutover and post it as one journal entry dated the cutover: every account's balance as a debit or credit line, netting to zero (a trial balance always does — if yours doesn't, stop and reconcile before migrating). The JE form's CSV line upload is built for exactly this: export the trial balance, shape it to the template, upload, post. Meridian's opening entry (MJE001001) put $750,000 of capital and cash on the books this way.
One refinement: post the AR and AP control account balances through this journal only if you are NOT loading open invoices as documents (next step). Loading both double-counts — the open documents rebuild those balances themselves.
Open receivables and payables, as real documents
Each unpaid customer invoice and vendor bill at the cutover becomes a posted document in REDA Financials — original date, original number in the Reference field, original amount. This is more work than one lump balance, and worth every minute: aging is real, payments apply to real invoices, statements make sense, and disputes have paper. Keep migrated documents lean — the open balance is what matters, so a summary line per invoice is fine. Post them in bulk with Bulk Posting.
Fixed assets, mid-life
REDA Financials has first-class support for assets that lived a prior life: check Is Migrated on the asset and provide the Migration Date, Acquisition Cost, and Opening Accumulated Depreciation (all three are required — the form insists). The system then includes the prior depreciation in net book value and calculates new depreciation from the migration date forward — no re-running of the past, no double depreciation.
Bank alignment
The opening journal put the ledger cash balance in place; confirm each bank account's first statement in REDA Financials starts from that same figure, so the first reconciliation opens clean instead of chasing pre-cutover items.
Prove it, then lock the door
Run the trial balance in REDA Financials as of the cutover and lay it beside the old system's — they must match line by line. Check AR and AP aging against the old system's open-item lists, and each asset's net book value. When it all ties, set the entity's closure dates (GL / AR / AP Closed Through) to the cutover date — migration can no longer be disturbed by a stray backdated posting, and live operation begins.
The toolbox
| Task | Tool |
|---|---|
| Opening trial balance | One journal entry; CSV line upload for the lines |
| Open AR / AP items | Documents (created or data-loaded by your admin/implementation partner), then Bulk Posting |
| Mid-life assets | Fixed Asset records with Is Migrated + the three migration fields |
| Master data at volume | Standard Salesforce import tools, in your administrator's hands |
| Verification | Trial Balance, AR/AP aging, asset registers — new vs old, side by side |
Where to go next
- Your Setup Roadmap — the foundations that come first.
- Creating a Journal Entry — the opening-balance vehicle.
- Fixed Assets — the asset model migrated assets join.
- Closing the Books — locking the migrated period.
Frequently asked questions
Almost never. Your legal books for prior years live in the old system's archive and your filed statements. Migrating settled history costs weeks, risks reconciliation drift, and buys you nothing the archive doesn't already provide. Balances at cutover + open items = complete continuity.
Reconcile in the OLD system before migrating anything. Migration faithfully copies whatever state you give it — including broken state. The golden rule: never use a migration to "fix" numbers; fix, then move.
A short verification overlap (one period, read-only comparisons) is healthy. True double-entry of live transactions in two systems is not — it doubles work and guarantees drift. Cut over cleanly on the date; keep the old system readable.
Posting runs the normal engines, so bring migrated documents in at their final historical amounts and check the first few carefully — the goal is that each document's total equals what the old system said, to the penny. Your implementation partner will typically pilot one batch before loading the rest.
Was this article helpful?