A phased general ledger modernization follows a fixed order: set design principles, redesign the chart of accounts, build and map, connect subledgers in waves, run at least one parallel close, cut over at a period start, then stabilise and retire the old ledger. Each phase ends with a sign-off.
This guide is for CFOs, controllers and finance transformation leads who need to replace or rebuild a general ledger without putting the close at risk. It covers sequencing, the chart of accounts, parallel runs, subledger integration, the effect on the close calendar and the controls to keep. It does not give accounting advice; treatment of specific balances and opening positions should be confirmed with your auditor. For the technology side of replacing an old platform, see our legacy software modernization service, and for the wider ERP context, our enterprise ERP development work.
Key takeaways
- Phase by risk, not by convenience. The ledger is the system of record, so design and reconciliation come before any cutover.
- Redesign the chart of accounts once, with dimensions for what used to be encoded in account numbers, and keep a versioned mapping from old to new.
- Connect subledgers in waves and prove each wave by reconciling control accounts, not by sampling.
- At least one parallel close, run on real data, is the strongest evidence that the new ledger produces the same answers.
- Plan the close calendar change explicitly. A new ledger changes who does what on which working day.
- Keep controls visible: journal approval, segregation of duties, access, reconciliations and change control.
How should a phased rollout of general ledger modernization be structured?
Structure it in seven phases: assess and set principles, design the chart of accounts, build and map, integrate subledgers in waves, run parallel closes, cut over, and stabilise. Each phase has an exit test, so finance can stop or adjust before the change reaches the live close.
| Phase | Purpose | Main outputs | Exit test |
|---|
| 0. Assess and set principles | Understand the current ledger, interfaces and pain points | Inventory, design principles, scope, owners | Scope signed by CFO and controller |
| 1. Chart of accounts and dimensions | Design the new structure | Account list, dimensions, mapping rules | Mapping covers every active old account |
| 2. Build and map | Configure the ledger, load opening balances, build reports | Configured ledger, opening trial balance, report set | Opening balances tie to the old ledger |
| 3. Subledger integration, in waves | Connect AP, AR, banking, assets, payroll, billing | Interfaces, posting rules, control account recon | Each wave reconciles to its control account |
| 4. Parallel run | Close a real period in both ledgers | Variance report, issue log, close timings | Differences explained or fixed |
| 5. Cutover | Switch to the new ledger at a period start | Cutover run-sheet, go or no-go decision | Go criteria met, rollback agreed |
| 6. Stabilise and retire | Support the first closes, archive the old ledger | Hypercare log, archive, decommission plan | First closes completed on schedule |
Durations are set from requirements and the number of entities, interfaces and legal reporting needs. We do not give standard timings here.
Which phasing pattern fits: by entity, by module or reporting first?
Choose by where the risk sits. Go by entity when the design is unproven or entities differ most, by module when process teams own the change, and reporting first when posting risk is high and visibility is the urgent need. The patterns can be combined.
| Pattern | How it works | Strength | Weakness |
|---|
| By entity | Pilot with one subsidiary, then roll out | Limits blast radius, proves the design | Group consolidation runs on two ledgers for a time |
| By module | New GL first, then AP, AR, assets in waves | Matches how teams own processes | Interfaces to the old subledgers must be built twice |
| Reporting first | Feed the old ledger into a new reporting layer, then replace posting | Fast visible value, low posting risk | Does not retire the old ledger by itself |
If the group has intercompany flows, the by-entity pattern needs a clear rule for how balances between a live and a not-yet-live entity are matched. Our guide on intercompany transactions and eliminations in ERP covers the matching step.
How do you redesign the chart of accounts?
Redesign the chart of accounts to separate the natural account (what the item is) from dimensions such as entity, department, project and location (where and why it arose). Legacy charts often encode several of these in one long account number, which causes hundreds of near-duplicate accounts.
A workable approach:
- List active accounts and balances, and flag dormant ones.
- Define the reporting needs first: statutory, management, tax and group reporting.
- Define the natural accounts, then the dimensions, and which dimensions are mandatory per account type.
- Build a mapping table from every old account to a new account plus dimension values, including one-to-many cases that need a rule.
- Version and lock the mapping, and give one person authority to change it.
- Keep the old account number as a reference attribute during the transition.
- Decide how opening balances and prior-period comparatives reach the new ledger. Opening balances are loaded at the cutover period start and tied to the old closing trial balance. Monthly account totals loaded at account level are usually enough for comparative reporting, and transaction detail stays in an archive. The scope decision is covered in what to migrate to a new ERP.
Local statutory reporting may need extra local accounts or reporting mappings. Define these with the local finance team and adviser, and treat them as mappings to the group structure.
What does a mapping and parallel-run reconciliation look like?
A parallel run closes the same real period in the old and new ledgers and compares the trial balances account group by account group. Each difference is explained, fixed in the design or accepted with sign-off, and the exercise repeats until none is unexplained.
The figures below are illustrative and show the format of the exercise, not expected results.
A company retires a ledger with 640 active accounts and moves to 220 natural accounts plus three dimensions. Opening balances are loaded at the start of a month. The parallel close for that month produces this trial balance comparison, in thousands:
| Account group | Old ledger | New ledger | Difference (new minus old) | Explanation |
|---|
| Trade receivables | 4,820 | 4,820 | 0 | Tied |
| Trade payables | (3,115) | (3,115) | 0 | Tied |
| Accrued expenses | (610) | (585) | 25 | New accrual rule excludes one vendor group; review |
| Fixed assets, net | 12,440 | 12,440 | 0 | Tied |
| Revenue | (9,300) | (9,282) | 18 | One billing interface posted in the next period |
| Payroll expense | 2,100 | 2,100 | 0 | Tied |
| Foreign exchange difference | 14 | 9 | (5) | Rate table difference; align rate source |
Out of seven groups, four tie, and three differences have an owner and a cause. The point of the parallel run is not that everything ties on the first attempt. It is that each difference is explained, fixed in the new design or accepted with sign-off, and that the same exercise is repeated until none remain unexplained. The next round starts from the corrected rules.
How should subledgers be integrated?
Connect subledgers in waves, and prove each wave by reconciling its control account in the new ledger to the subledger. A typical order is bank and cash first, then payables, receivables, fixed assets, payroll and billing, but the right order depends on volumes and interfaces.
For each interface, agree:
- What posts: summary or detail, and at what frequency.
- Posting rules: which accounts and dimensions, and who owns the rules.
- Error handling: what happens to a rejected posting, who sees it and how it is cleared.
- Reconciliation: the control account to subledger report that must tie.
- Cut-off: how items in transit at period end are treated.
Systems that sit outside the ledger, such as billing, payroll, portals or property and project systems, often need a custom interface. Our systems and API integration service covers that kind of work.
How does a new ledger change the close calendar?
It changes the close calendar because tasks move: automated postings replace manual journals, reconciliations can run earlier, and approvals follow new workflows. Plan the calendar change before go-live, and expect the first closes in the new ledger to run longer than the steady state.
A simple way to plan is to list each close task, its owner and working day in the current calendar, then re-plan it for the new system.
| Close task | Today (working day) | Planned in new ledger | Change |
|---|
| Subledger cut-off | WD1 | WD1 | Same |
| Bank reconciliation | WD3 | WD1 to WD2 | Automated matching, earlier |
| Accruals and prepayments | WD3 | WD2 | Templates in the ledger |
| Intercompany matching | WD4 | WD2 | Linked entries |
| Journal review and approval | WD4 to WD5 | WD3 | Workflow with approval limits |
| Management reporting | WD7 | WD4 | Reports read from the ledger |
These working days are illustrative. Set targets only after the parallel run shows what the new process does.
Which controls must carry over?
Controls must carry over by design, not by assumption. List the controls the current ledger relies on and decide how each is met in the new one. Do not call the result compliant with a named framework unless that is confirmed for your organisation; say that controls are designed to support your audit needs, confirmed with your auditor.
| Control area | What to confirm in the new ledger |
|---|
| Journal entry | Who can post, approval limits, no self-approval, support attached |
| Access and segregation of duties | Roles by entity and function, with conflicts reviewed |
| Period management | Who can open and close periods, and how late postings are handled |
| Reconciliations | Preparer and reviewer evidence retained |
| Master data | Chart of accounts changes approved and logged |
| Interfaces | Reconciliation and error monitoring |
| Audit trail | Changes to postings and settings recorded |
| Migration evidence | Opening balance tie-out and sign-off kept |
When should you replace desktop accounting software instead?
If the starting point is desktop accounting software with one or two entities, a full phased programme may be more than needed. The question then is whether the business has outgrown it; our guide on ERP versus accounting software sets out the signals. The phased approach in this guide is for ledgers with several entities, interfaces and reporting obligations.
When this is the wrong approach
A phased ledger programme is the wrong approach if the ledger works and the real problem is a slow process around it, such as late approvals or manual intercompany matching. Fix that first. It is also wrong if the chart of accounts is not redesigned because of fear of change; moving a poor structure to a new platform carries its problems with it. And it is the wrong approach if no one owns the mapping.
Glossary: general ledger (GL), the main record of accounting entries; chart of accounts, the structured list of accounts; dimension, an attribute such as department or project attached to a posting; parallel run, closing a period in both old and new systems to compare results; control account, a ledger account summarising a subledger.
How Timeline Digital approaches this work
For a ledger programme that depends on sign-offs, Timeline Digital uses the Plan step to fix scope, owners and exit tests before any build starts, and the schedule is set from those requirements. Timeline Digital is a custom software development company founded in 2013 and headquartered in Islamabad, Pakistan, delivering remotely. A free pilot of 2 to 3 key modules lets your team test the result before the final agreement, and code ownership passes on full payment.