Why financial-data migration needs validation, not just import

Import tools report success when the destination system accepted the records presented to it. That is a genuine milestone, and it is worth having. It is not, however, the same as knowing that the financial position now shown in the new system is complete, understood and ready for someone to approve.

Validation is the separate, deliberate step of demonstrating that what arrived represents what left — and of documenting, on purpose, every place where the two legitimately differ.

What a successful import actually proves

A load that completes without rejections proves the file was structurally acceptable: required fields were present, formats were valid, references resolved. It does not prove that every record intended for migration was included, that values landed against the right accounts, that dates and allocations survived, or that the way the new system represents a transaction produces the same reported outcome.

Those are different questions, and each needs to be answered independently rather than inferred from the absence of an error message.

Record counts: necessary, and not sufficient

Comparing counts of customers, suppliers, accounts, invoices, bills and journals between source and destination is quick and catches wholesale omissions immediately — a file that stopped part-way, a batch that was skipped, a filter that excluded more than intended.

Counts are the floor. They can match perfectly while values, dates, tax codes or allocations do not. Treat a count comparison as the first check rather than the reassuring one.

Balance comparison, and agreeing what is being compared

Balance comparison is where trust is actually built: a trial balance at the changeover date, control accounts agreeing to their sub-ledgers, receivables and payables agreeing in both total and ageing profile, bank balances agreeing to the reconciliation position.

The step that is most often skipped is agreeing what is being compared before the comparison is run. A trial balance as at a date is only meaningful if both sides use the same date, the same treatment of transactions posted after the cut-off, the same rounding, and the same view of what is in scope. Where those definitions differ, people spend days investigating a difference that was created by the question, not by the migration.

• Trial balance at the agreed cut-off date, source versus destination
• Receivables and payables control totals, plus the ageing profile behind them
• Bank account balances against the reconciled position, not the raw ledger balance
• Tax control accounts, including how rounding differences are treated
• Inventory valuation and payroll balances where those are in scope

Mapping and transformation decisions are part of the result

Almost every migration transforms something. Accounts are merged or split. Tax codes are mapped to the destination's equivalents. Years of detail are summarised into opening balances. A document type that exists in one system is represented differently in the other. Each of those is a decision, and each one legitimately changes what the destination reports.

A worked example

Consider a fictional wholesale business with three separate freight expense accounts in its source file: one created for interstate deliveries, one for courier charges and one that appears to have been created by accident and used briefly. In the destination system, the business has decided to consolidate all freight into a single expense account with a reporting category behind it.

After migration, the destination trial balance shows one freight account where the source showed three. A line-by-line comparison flags a difference on every one of them. Nothing has gone wrong — this is exactly what was agreed. But if that mapping decision was made verbally during a call in week two, the reviewer in week eight has no way to tell an intended consolidation from an error, and the only path forward is to reconstruct the reasoning from memory.

Recorded as a decision, with the accounts involved and the reason for the change, the same difference takes seconds to accept. Unrecorded transformation is indistinguishable from error later on, which is the practical argument for documenting mapping as it is decided rather than after it is questioned.

Expected change versus unexplained difference

The most useful distinction in migration validation is between a difference you can explain and one you cannot. An expected change has a documented cause: a mapping decision, a scope boundary, a rounding rule, a deliberate exclusion. An unexplained difference has none, and is the only category that should hold up sign-off.

Validation output that lists differences without separating these two categories tends to be ignored, because the volume is high and the signal is buried. Output that classifies them gives a reviewer somewhere sensible to focus.

Exceptions need a lifecycle, not a log file

Every migration produces exceptions: records that could not be mapped, values that failed a rule, items that need a human decision, contacts that were duplicated in the source and must be resolved before they are duplicated again.

What matters is not that exceptions exist — they always will — but that each one is visible, assigned to someone, investigated, and closed with the resolution attached to it. An exception list that is exported to a spreadsheet and worked through privately produces the same outcome with none of the evidence.

• Raised: the rule or comparison that produced it, with the records involved
• Assigned: a named owner, whether that is the business, the practice or the migration team
• Investigated: what was found, in language a reviewer will understand later
• Resolved: corrected, accepted as an expected change, or explicitly moved out of scope

Where human judgement is indispensable

Rules can compare, count and flag. They cannot decide whether a difference is acceptable in the context of a particular business. Judgement is required in exactly the places where migrations are most sensitive.

• Opening balances, and whether the position they establish is the one the business intends to report from
• Payroll figures, leave balances and reporting continuity, where timing rules apply
• GST and tax treatment on transactions that were coded inconsistently in the source
• Unusual or one-off records — historical adjustments, related-party balances, legacy provisions
• Business-specific reporting where the destination's structure changes how a result is presented

Evidence is what makes sign-off possible

At the end of a migration, someone has to state that the new system can be relied upon. That approval is far easier to give, and far more defensible when questioned months later, if it rests on comparison summaries, documented mapping decisions and closed exceptions rather than on the absence of complaints in the first week.

Evidence collected as the work happens costs very little. Evidence reconstructed afterwards costs a great deal, and is usually incomplete.

How validation supports a more confident cutover

Cutover is a commitment: from a defined moment, the new system is the record and the old one is reference. The confidence to make that commitment on schedule comes from having already answered the questions that would otherwise surface during the changeover window.

When balances have been compared, differences classified and exceptions closed, cutover becomes a short, planned sequence rather than an open-ended investigation conducted under time pressure.

Ledrix is designed around a structured approach to readiness, workflow visibility, validation and controlled cutover — gathering the evidence while the work happens so approval is a review rather than a reconstruction. The stage sequence is set out in how it works; the business and practice perspectives are covered on for businesses and for practices.