Sage 300 Migration Reconciliation — Multi-Company, Intercompany, Auditable

Sage 300 migration reconciliation is the framework — the governance, control points, evidence requirements and sign-off cadence — within which sage 300 data validation operates. Data validation is the technical activity (compare source to target, report variance, resolve). Migration reconciliation is the structure that says what gets reconciled, by whom, at what cadence, against what tolerance, with what evidence, with what sign-off — and how reconciliation failures roll back the migration if they can't be resolved. For a multi-company Sage 300 estate with intercompany consolidation, the reconciliation framework is what keeps the migration auditable and the cutover defensible. It's typically owned by the finance lead with internal audit oversight, supported by the migration delivery team.

Multi-company Sage 300 estates carry a particular reconciliation complexity: intercompany transactions create linked entries across two or more separate Sage 300 company databases, and those linked entries have to reconcile to zero in aggregate (intercompany equilibrium) while also reconciling individually per counterparty pair. Sage 300 migration reconciliation tracks IC equilibrium at three levels — per IC document (sum of all linked entries must be zero), per counterparty pair per period (sum of A→B transactions must equal sum of B→A reciprocal), and per consolidation elimination (Sage 300 elimination journals vs Fusion ICA or EPM Consolidation eliminations). For customers running 5+ companies with active intercompany, this is the single most diagnostic-heavy reconciliation domain.

For trial balance, AP/AR aging, inventory valuation and intercompany — the bar is zero variance, per company per period per natural-account class. Variance is investigated until it's resolved, not accepted as a rounding error. The two scenarios where small tolerances are accepted: (a) historical multicurrency revaluation where Sage 300 used a different revaluation algorithm than Fusion (rare; affects 2nd-decimal cents on long-running revaluation chains) — accepted with sign-off documenting the algorithm difference; (b) historical inventory costing where Sage 300 used a costing layer convention Fusion can't reproduce exactly (e.g. very old FIFO layers truncated by Sage 300 retention policy) — accepted with sign-off documenting the cutoff. Every accepted tolerance is documented in the reconciliation pack.

Sage 300 migration reconciliation is jointly owned. Finance lead owns the framework — what gets reconciled, against what tolerance, with what evidence. Internal audit owns oversight — does the reconciliation evidence satisfy SOX, GoBD, jurisdictional requirements. Migration delivery team owns execution — running the validation, producing the reconciliation reports, resolving variance. Sign-off at parallel-run completion and at final cutover comes from finance leadership (CFO/Controller), operations leadership (COO or VP Ops where inventory/order data is in scope), IT leadership (CIO/IT Director), and internal audit. External auditor is briefed but doesn't sign off — the migration reconciliation pack becomes part of the workpapers for the next external audit.

Sage 300 Project & Job Costing (PJC, originally Norming Software, later acquired by Sage) carries its own reconciliation complexity. Each project has hierarchical phase/task structure, transaction-level cost capture, billing rules, WIP accounting and revenue recognition. The reconciliation framework reconciles: project master count and hierarchy depth, transaction-level cost per project per phase per cost class (labour, materials, equipment, sub-contractor, overhead), WIP balance per project per period, billing balance per project per customer, revenue recognition per project per period, and project-to-GL roll-up (the sum of PJC transactions for a period must reconcile to the GL postings PJC generated for that period). For customers running 100+ active projects, this is a multi-week reconciliation in its own right.

The reconciliation pack contains: trial balance per company per period (Sage 300 vs Fusion to the cent, variance reported per natural-account class); AP aging per supplier per bucket; AR aging per customer per bucket; inventory valuation per item per location per costing layer; multicurrency revaluation per currency per account per period; intercompany equilibrium per counterparty pair per period; project WIP and billing per project per period (if PJC in scope); fixed asset register per asset class per location (if FA in scope); payroll register per period per company (if Sage 300 Payroll in scope); FBDI load summary per payload per company; load-error disposition for every error; mapping artifact version reference; and executive sign-off pages.

SOX requires that material changes to financial systems carry documented control evidence — and a Sage 300 to Fusion migration is the most material change finance will see in a decade. The reconciliation pack is that control evidence. It demonstrates (a) source data was extracted completely and correctly (hash-signed manifests), (b) source data was transformed correctly per a governed, audit-signed mapping artifact, (c) target data matches source to the cent per company per period per ledger, (d) intercompany equilibrium is preserved, (e) audit drill-back chain is functional end-to-end, (f) any tolerances accepted are documented with sign-off rationale. For GoBD specifically, the pack adds the German requirement of 'ordered, complete, correct' bookkeeping with immutability evidence — satisfied by the hash-signed manifests and the immutable cloud archive.

Yes — the reconciliation framework explicitly defines roll-back triggers. If parallel-run reconciliation fails to resolve to the variance tolerance within the parallel-run window, the migration delivery team escalates to the steering committee. Steering committee options are (a) extend parallel-run by one fiscal period to resolve variance, (b) accept variance with documented sign-off (rare; only for the narrow tolerance cases above), or (c) roll back cutover and address root cause. The roll-back is what makes the migration defensible: it forces variance to be resolved rather than absorbed. In practice, well-run sage 300 migration reconciliation programmes catch variance early enough that roll-back is never invoked — but the option being on the table is what disciplines the resolution work.