Accounting Data Integrity and Migration Readiness

Is the entity planning, executing, or within roughly twelve months past an accounting system change - a new general ledger, ERP, or replacement of a key subledger such as billing, payables, inventory, or fixed assets?

A migration is any event that moves accounting balances between systems of record, including re-implementations of the same product and ledger consolidations after an acquisition. Version upgrades and report-writer changes that convert no data carry far less data-integrity risk. The common trap is treating a subledger replacement as a purely operational project when its output feeds the general ledger.

With no migration in scope, treat data quality as a standing control discipline under COSO 2013 Principle 13 rather than as a project.

Official guidance: GAO Standards for Internal Control

Which phase best describes the project today?

The phase determines which disciplines can still be built cheaply: master data cleanup and the reconciliation baseline are planning-phase work, exit criteria and control mapping must be settled before cutover, and after go-live the question shifts to proving that converted balances and controls actually operate. Be honest about the phase - projects at cutover often still carry planning-phase gaps, and this check will surface them.

Use the interactive tool above to see how this applies to your situation.

Official guidance: GAO Standards for Internal Control

Does each master data domain - customers, vendors, items, and the chart of accounts - have a named business owner accountable for its accuracy, with cleanup decisions (duplicate merges, deactivation of dormant records, account rationalization) documented before conversion mapping is finalized?

Quality information depends on reliable master data, and reliability requires a named accountable owner for each domain - not a shared project mailbox. Cleanup deferred to after go-live rarely happens, and duplicate vendors or an unrationalized chart of accounts get much harder to fix once transactions post against them. The classic trap is copying the legacy chart of accounts into the new system to save mapping effort.

Converting unowned, uncleaned master data embeds today's errors permanently in the new system; establish ownership and execute cleanup first (Green Book Principle 13).

Official guidance: GAO Standards for Internal Control

Are all key balance-sheet accounts - bank, receivables, payables, inventory, fixed assets, payroll liabilities, and intercompany - reconciled to item-level supporting detail as of a defined baseline date, with differences resolved rather than carried forward?

The baseline reconciliation is what every post-conversion check will be measured against; without it there is no way to prove that the conversion was complete and accurate. Differences must be resolved before cutover because the legacy audit trail needed to explain them degrades quickly once the old system is retired. Watch for reconciliations that tie in total while concealing offsetting item-level errors.

Unreconciled balances converted into a new system become permanent unexplained differences; establish the reconciliation baseline before any balance moves (Green Book Principle 13).

Official guidance: GAO Standards for Internal Control

What is the decided strategy for historical accounting data in the new system?

There is no single right strategy - the discipline is that the choice is documented, retention of non-converted history satisfies record-keeping obligations such as IRC Section 6001, and every converted element has a mapping specification and a validation owner. Full history multiplies mapping and reconciliation effort; summary balances shift the burden to preserving reliable legacy access. The trap is deciding by default at the moment the conversion programs are written.

A cutover date without a documented data strategy is a design gap; define what converts and where history lives before scheduling conversion (Green Book Principle 11).

Official guidance: GAO Standards for Internal Control

Does the cutover plan include a defined verification exercise - a parallel run or at least one full mock conversion - with documented exit criteria, tolerance thresholds, and a named approver who has real authority to delay go-live?

Exit criteria turn go-live from a judgment call under deadline pressure into a controlled decision: defined comparisons, quantified tolerances, and a person with authority to say no. A full mock conversion on a complete data copy finds mapping and truncation errors while they are still cheap to fix. The trap is a parallel run that produces differences nobody is assigned to resolve, which are then waived wholesale at the deadline.

Without a verification run gated by documented exit criteria, the go-live decision is a judgment call made under schedule pressure; design the gate before setting the date (Green Book Principle 11).

Official guidance: GAO Standards for Internal Control

Has each key control in the current financial processes - approvals and delegations, segregation of duties, system access, interface and suspense reconciliations, and report logic - been mapped to its replacement in the new system, with open gaps assigned to owners?

A system change silently retires controls that were embedded in the old system's configuration - tolerance checks, matching rules, posting restrictions - unless each one is deliberately mapped to a replacement. Access and segregation-of-duties design is part of this mapping and is far harder to retrofit after users hold broad rights. The trap is assuming the implementation partner's default roles reflect your control requirements; they reflect an average customer's.

The 2013 framework's control activities principles (10, 11, and 12) frame how controls, including technology general controls, are designed and deployed in a new system.

Official guidance: GAO Standards for Internal Control

• COSO Internal Control - Integrated Framework

Since go-live, have converted balances been proven in the new system - the opening trial balance reconciled back to the legacy baseline, the first period-end close fully reconciled without plug entries, and interface and suspense accounts monitored and cleared?

Go-live is not the end of the migration - the migration ends when every converted balance is proven against the legacy baseline and the first close reconciles cleanly. Suspense and interface account aging is the most honest indicator: accumulating balances mean conversion or mapping errors are compounding under the surface. The window matters because the legacy audit trail and the people who can explain differences both fade quickly.

Going live did not finish the migration; unproven converted balances and accumulating suspense call for a dated stabilization program now (Green Book Principles 13 and 16).

Official guidance: GAO Standards for Internal Control

Is a post-go-live reconciliation plan documented - naming who reconciles converted balances immediately after conversion, how the first close will be proven against expectations, how long legacy read-only access is retained, and what defines the end of stabilization?

Monitoring is a component of internal control, and for a migration it must be designed in advance: the first days after conversion are when reconciliation effort is highest and when errors are cheapest to correct. The plan should state who reconciles what, against which baseline, by when, and what evidence closes stabilization. The trap is assuming the project team will still be available after go-live - budgets and implementation partners typically roll off at exactly that point.

The core disciplines are designed; execute the plan as written and preserve the conversion evidence (Green Book Principles 11 and 13). A migration plan that ends at go-live is incomplete; write the post-go-live reconciliation and stabilization plan before confirming the cutover date (Green Book Principle 16).

Official guidance: GAO Standards for Internal Control

Are the mapped controls actually operating in the new system - access provisioned on least privilege with segregation-of-duties conflicts resolved, approvals routing as designed, and key reports validated against known results?

Designing controls is not the same as deploying them: COSO 2013 Principle 12 requires that control activities operate through policies and procedures in practice. Temporary implementation access and workflow bypasses granted to survive go-live have a way of becoming permanent unless they are actively withdrawn. Validate key reports against known legacy results now, while side-by-side comparison is still possible.

Converted balances are proven and mapped controls are operating; shift to steady-state monitoring and archive the conversion evidence (Green Book Principle 16). Balances may be proven but the control environment is not; remediate access, approvals, and report validation through a dated stabilization program (COSO 2013 Principle 12).

Official guidance: GAO Standards for Internal Control