Months of configuration, data cleanup, and testing culminate in a single moment: turning on your new financial system. But your first test is reconciling opening balances after go-live to confirm that your financial history transferred accurately from your legacy system. If not, every dashboard, report, and decision is on a shaky foundation.
Decide What to Carry Forward into the New System
Before you reconcile anything, decide what history belongs in the new system. That choice sets the scope of time commitment, the resources needed, and how much evidence you must retain for audit purposes.
Key questions to consider:
- Are you bringing one year or multiple years of history?
- Do you want summary balances, period-by-period activity, or full transaction-level detail?
- Do you need the data to support current operations, budget prep, or ACFR reporting?
There’s no universal “right” answer because your answer comes down to operational needs.
Whatever is carried forward must be tested to ensure it ties to your legacy system, proving that the data you loaded agrees and is reliable. Starting with the aggregate to find hot spots is acceptable but eventually the details that feed your reports must be confirmed. Note:
- If you’re loading period balances, reconcile by period.
- If you’re loading year-end balances, tie out to the final audited trial balance.
Be mindful that the more history you bring, the more likely you’ll encounter accounts or funds that no longer have a home in the new chart if you revised the chart of accounts. Plan for where those balances will live in the new structure. Otherwise, you’ll have mismatches that persist long after cutover.
Pro-tip: If you do bring multiple years, you can start proving closed years as soon as a test environment is available. Use that window to rehearse the legacy load, reconcile trial balances, and get comfortable with how account totals are shown in the new structure.
Map Once, Check Often
Revisions to the chart of accounts are common with new system implementations. Sometimes because the new system treats dimensions differently, and sometimes because it is an opportunity to remove and add accounts to meet needs. Although common, it does introduce conversion risk because one-to-many and many-to-one relationships between the old and new systems may be created.
To prevent issues, create and maintain a crosswalk of where every legacy account is in the new chart of accounts structure. Your implementation partner may help draft an initial version. However, ownership and version control must be kept with the team member that owns the chart of account because it’s a critical tool that shows where accounts should land with the initial load and consequently how to balance in the new and legacy systems.
Example: A single legacy “Permit Revenue” account is being split into several new revenue accounts for better reporting and information in the new system. Conversely, multiple legacy administrative departments are consolidated into a single “Administration” department to match the current organizational chart. Your crosswalk should show how the old permit revenue is dissected into the new accounts (or note where that is infeasible and how the reconciliation will still tie in total) and show how several accounts roll into the new consolidated account while preserving agreement to legacy totals.
Expect Movement After Go-Live—and Control It
The most typical scenario is conversion at the start of a fiscal year because it’s organically a divide between the old and new – old and new system and old and new fiscal year. Unfortunately, it’s also one of the busiest times of year: invoices continue to arrive and must be paid, year-end adjustments need to be posted, and accruals are identified after the initial balances are loaded into the new system.
Operationally,
- the new system is now the system of record;
- but historically, the legacy system still needs to be updated.
Here’s how to control the overlap:
- Assign ownership for preparing and approving post-cutover adjustments in the legacy system, and when possible, restrict access to that small and controlled group to minimize posting errors.
- Define how these entries are posted in the legacy system to create a connection to the new system. For instance, batch them so they can be mirrored one-for-one in the new system and use reference descriptions.
- Set a cadence for how often to check the numbers between the legacy and new system. Weekly might be ideal early on, but at a minimum monthly – the answer is dependent on the amount of activity and reporting needs.
Example: Your first July accounts payable check run includes invoices that need to be accrued at year-end. Post an accrual back to June 30 in the new system using your transaction journal source, then prepare a matching journal entry in the legacy system to maintain a matching history in the new system. Include a reference description and ID of the journal entry in case you need to investigate later if something is off.
The overlap typically ends with the audit. At that point, a complete final comparison can be done, the legacy system can be locked down and close any open fiscal periods in the new system.
In Summary
- Keep the crosswalk under version control and assign an appropriate team member to be accountable.
- At cutover, decide who can post to the legacy system and create a cadence for comparing balances.
- Use references to quickly identify and analyze variances.
- Close the overlapping window as quickly as possible because more time than necessary introduces more opportunities for issues and resources that need to dedicated to comparing the systems.
Reconciliation after go-live is critical because it’s the bridge between the legacy and new system. Otherwise, your team will spend more time chasing variances than spending it using the system you paid for.
Have questions? Contact us today!
