Will the new accounting system change your historical reports?

Save the old report with its entity, period, accounting basis, currency, filters, and version. Recreate those conditions in the new system before treating a difference as an accounting error. A report with the same title may use a different definition.

Check whether the migration changed account grouping, dimensions, customer hierarchy, treatment of inactive records, or report defaults. Ask the provider to identify expected differences in advance. That lets the company distinguish a deliberate design decision from a missing or misclassified record.

Intuit's Desktop-to-Online guidance explicitly notes report differences and warns that cash-basis reports may not match. That product-specific limitation is a reason to test the reports you use, even when the migration's headline balance check succeeds.

Choose reports used for actual decisions or commitments. Include the financial statements, an important operational schedule, and a report that relies on dimensions such as customer, project, location, or department. Cover periods that exercise relevant complexity rather than only the quietest month.

For each report, define the expected result and the way differences will be investigated. Microsoft describes test cases in terms of prerequisites, actions, and expected outcomes. Apply that structure to the report comparison so another person can repeat it.

A test should identify the source extract and target version. If someone changes the mapping or posts an adjustment midway through the comparison, record it and rerun the affected report. Otherwise two valid screenshots may represent different underlying data.

Start with the old amount and identify the adjustments that explain the new amount. Classify each difference as missing or duplicated activity, timing, basis, mapping, calculation, or presentation. Keep the evidence and decision owner alongside the bridge.

For a hypothetical example, an old report shows revenue of $100,000, cost of sales of $40,000, and operating expenses of $30,000, producing $30,000 profit. If a reviewed mapping moves $5,000 of costs from operating expenses to cost of sales, the new report shows $45,000 cost of sales and $25,000 operating expenses. Profit remains $30,000, but gross profit falls from $60,000 to $55,000.

The arithmetic shows why a matching bottom-line total does not establish comparable margins. Management needs the classification explanation before interpreting the change as worse operating performance. The mapping itself should be approved under the company's reporting policy.

Check unassigned dimensions, inactive customers, combined accounts, credit balances, and unusual transaction types that matter to the selected reports. An offsetting pair of errors can leave the overall total unchanged while altering the customer, department, or period.

Test a known transaction through the new report. Can the user locate it, understand its classification, and connect it to supporting evidence? A report that reconciles numerically but loses necessary drill-down may not satisfy the company's intended use.

Review currency and date settings where relevant. A different reporting currency, exchange-rate convention, or as-of filter can produce a valid but incomparable output. Ask the accountant to identify the appropriate common basis rather than forcing the figures to agree with an unexplained entry.

If the new reporting structure is intentionally different, decide whether historical periods will be remapped, shown through a bridge, or retained in the old presentation with a clear explanation. Consider what the users need and the work required to produce a reliable comparison.

Do not rewrite history informally to make a trend look smoother. A change that affects issued financial statements, filings, or externally agreed measures may need professional assessment beyond the migration project. Identify that requirement before replacing previously distributed information.

Record the approved reporting definitions and the treatment of legacy data. The next person preparing the management pack should not have to infer why a historical category changed or which comparative column is appropriate.

Keep the old and new report versions, comparison conditions, bridges, resolved defects, and accepted limitations. Ask the responsible report users and accounting reviewer to confirm that the outputs support their intended purpose.

Recheck affected reports after a material mapping or configuration correction. Focus on the concrete risk the change introduces; there is no value in repeatedly rerunning unrelated tests once the relevant comparison is resolved.

Use the first live reporting cycle to confirm that the accepted definitions are still in place. A successful migration should leave the company able to explain both its current numbers and the relationship to the historical reports it previously used.