Oracle Fusion goes live on Monday. The core processes work, users can post journals and suppliers can be paid. Then finance runs the first serious reconciliation. The opening trial balance does not tie back to Unit4 Agresso, several control accounts are unexplained and the team cannot tell whether the difference sits in the extraction, the mapping or the load.
This is the gap that can remain even when the ERP implementation itself is well managed. The implementation partner is rightly focused on configuring Oracle Fusion Cloud ERP and reaching go-live. Finance still needs independent evidence that the migrated data is complete, correctly mapped and capable of supporting reporting through cutover.
My view is simple: data quality reporting should begin as soon as the target system is chosen, and ideally before detailed mapping starts. It should then run as a measured workstream, with its history retained, rather than as a collection of validation queries close to go-live.
Why migration data quality work starts too late
The pattern I see most often is that data quality is scheduled as a pre-migration gate. Extracts are prepared, mappings are agreed and test loads begin. A few weeks before cutover, someone runs checks for missing values, duplicate suppliers and balances that do not reconcile.
By that point, the programme plan is committed. Mapping decisions have already shaped interfaces, workflows and training. A newly discovered problem is therefore treated as a reason to delay go-live or as an exception to fix later. Neither response improves confidence.
Starting early changes the economics of the work. Source data can be corrected in Unit4 Agresso while its owners still understand the records and while there is time to test the effect. Decisions that genuinely require a mapping rule can be made before that rule is embedded in repeated test cycles. The right starting point is when Oracle Fusion is selected and the first migration scope is discussed, not when the final extract is due.
Where finance data goes wrong during migration
Chart of accounts and dimension mapping
A move to Oracle Fusion often includes a redesigned chart of accounts. Several Agresso accounts may roll into one target natural account, while an old account may need to split according to cost centre, project or transaction type. A mapping that looks complete in a spreadsheet can still send transactions to the wrong reporting line. For example, an account used differently by two entities may need two target rules rather than one global mapping.
Open items and part-paid transactions
Open receivables and payables need more than a total balance. Invoice references, due dates, tax treatment, payment status and remaining amounts must survive. A part-paid invoice can be loaded as fully open if the extraction carries the original value but misses the applied payment. The control account may appear correct at a high level while the subledger is wrong.
Historical periods and comparative reporting
Many programmes migrate only opening balances and selected open transactions. That may be sufficient for operational go-live, but finance still needs prior-year comparisons, audit support and drill-through to historical detail. If the reporting plan is postponed, users may discover that the new ERP contains the current position but cannot reproduce the management pack they used before cutover.
Supplier and customer master data
Duplicate suppliers can have slightly different names, addresses or bank details. Merging them requires a controlled decision, not a fuzzy match followed by deletion. Keeping every duplicate, however, carries poor data into the target and makes spend analysis less reliable. The same issue applies to customers, payment terms, tax registrations and inactive records that are still referenced by open items.
Currency and multiple entities
A group migration must preserve document currency, ledger currency, exchange rates and entity ownership. A transaction can be numerically correct in one currency and still produce the wrong consolidated result. Intercompany balances also need matched treatment on both sides. If one entity moves a balance to a new account and the counterparty does not, elimination reporting breaks even though each individual ledger appears balanced.
Measure data quality instead of only finding errors
A validation query answers a narrow question at one point in time. A data quality measure has a definition, an owner, a reporting date and a retained result. That distinction matters because a programme board needs to know whether remediation is working, not merely how many issues were found in the latest test.
| Measure | What it shows | Why finance should care |
|---|---|---|
| Duplicate master records | Potential duplicate suppliers or customers by agreed matching rules | Reduces payment risk and improves spend and income analysis |
| Unmapped dimension values | Source accounts, cost centres, projects or entities without an approved target | Shows which balances cannot yet be reported correctly in Fusion |
| Orphaned transactions | Transactions whose supplier, customer, project or other parent record is missing | Identifies records that may fail to load or lose their business context |
| Mandatory-field failures | Records missing values required by the target design | Separates source remediation from target configuration issues |
| Ageing of unresolved exceptions | How long each open data issue has remained unresolved | Exposes items that are repeatedly deferred between test cycles |
The measures should be small enough to understand and stable enough to compare. A longer catalogue can follow, but these initial measures reveal whether the foundations of the migration are improving.
Keep every snapshot because the history cannot be recreated
Each measure should be calculated on a schedule and stored with its snapshot date. The result is a trend line for duplicate suppliers, unmapped cost centres, orphaned transactions and aged exceptions. Finance can see whether the number is falling, remaining flat or becoming worse as new source data is created.
This changes programme reporting. Saying that the data is cleaner than last month is an assertion. Showing the measured history is evidence. It also helps the programme board distinguish real remediation from repeated closure and reopening of the same issues.
The history has value after cutover too. The final Agresso snapshots become the baseline for Oracle Fusion. If duplicate records or mandatory-field failures start to rise in the new system, the organisation can see the change against a known position. Once snapshots are discarded, that trend cannot be reconstructed reliably from the current state.
Run reconciliation reporting in parallel through cutover
During test cycles and cutover, the reporting layer should read both Unit4 Agresso and Oracle Fusion. Finance needs side-by-side balances at the level where differences can be explained: entity, period, account, cost centre, project, supplier, customer and currency where relevant.
A total trial balance comparison is necessary but insufficient. The totals can agree while transactions are assigned to the wrong dimensions. Reconciliation should therefore move from control totals into mapped reporting structures and then into selected transaction detail. Exceptions need an owner and a disposition: source correction, mapping change, accepted difference or target correction.
Finding divergence before go-live is cheaper because the migration team, source experts and test environment are still available. After go-live, the same problem competes with period-end activity, user support and operational fixes. Evidence gathered during parallel running gives finance a clearer basis for signing off the migrated data.
A practical Microsoft Fabric architecture
The technical shape does not need to be difficult for finance to follow. I use a Microsoft Fabric Lakehouse with a medallion pattern. Bronze holds dated extracts from Agresso and Oracle Fusion in the form received. Silver applies data types, common identifiers, mappings and conformed finance dimensions. Gold contains reconciliation models, data quality measures and reporting-ready balances. Power BI presents the trends and exceptions to finance and the programme board.
Oracle Fusion data can be extracted through BICC file extracts. Fabric data pipelines orchestrate ingestion and PySpark notebooks apply repeatable transformation and validation rules. Agresso extracts follow the same landing pattern, even if their source mechanism differs. Keeping the original extracts in Bronze means a reported exception can be traced back to the exact source file and reporting date.
Quality snapshots are stored as dated partitions rather than overwritten. That is the technical step that preserves the history. The solution is part of a wider data and reporting workstream, but its purpose is business assurance: prove what was received, what was changed, what reconciles and what still needs a decision.
The reporting layer remains useful after go-live
A migration reporting platform should not be discarded after the final reconciliation. It can become the ongoing finance reporting layer. Historical Agresso data remains queryable alongside Oracle Fusion, giving users continuity where only limited history was loaded into the new ERP.
The same data quality measures continue against Fusion. The ownership may move from the migration programme into business-as-usual finance systems governance, but the definitions and trend history stay intact. The organisation gains an enduring reporting asset from work that was initially funded to reduce migration risk.
Questions to take to the next programme board
- When does the data quality workstream start, and what can begin before the first test migration?
- Who owns each data quality rule and each unresolved exception?
- Which measures are tracked consistently across every migration cycle?
- Are dated snapshots retained so the programme can prove whether quality is improving?
- At what level will the trial balance, control accounts, subledgers and reporting dimensions be reconciled?
- How will finance report across Agresso and Fusion during cutover and immediately after go-live?
- Who proves that migrated data is correct independently of the team that extracted, mapped and loaded it?
- What reporting and historical access will remain after the implementation partner leaves?
These questions make ownership visible. They also separate ERP configuration from data assurance. Both are needed for a successful finance-system migration, but they are different responsibilities.
Make data quality a workstream from the start
The difficult moment is not discovering that an Agresso balance differs from Oracle Fusion. It is discovering it after cutover, without a retained history, without clear ownership and without enough detail to explain the cause.
Start the measures early, retain every snapshot and run source and target reporting in parallel. That gives finance evidence that remediation is working and a defensible basis for accepting the migrated data. It also leaves the organisation with a useful reporting platform rather than a folder of one-off validation queries.
If this gap exists in your Agresso to Oracle Fusion programme, I can help define the reconciliation, data quality and reporting workstream. Contact Business Intelligence Atlas to discuss the migration.
Comments are closed