Dynamics gp data validation that proves every row, sum and audit chain landed correctly in Fusion. GL30000 trial balance parity per company, PM30200 vendor totals, RM30201 customer totals, item on-hand. Hash-signed audit pack accepted by internal and external audit.
'The FBDI job completed' is not validation. Real dynamics gp data validation proves trial balance, AP aging, AR aging and item on-hand match GP to the cent — per company, per period.
The cutover decision on a GP-to-Fusion programme is the single most career-relevant moment for the executive sponsor. Production traffic moves from a system finance has trusted for two decades to a system that's been live for 12 weeks. The only thing that makes that decision survivable is reconciliation evidence that proves GP and Fusion produce the same answer — to the cent, per company, per period, across every module that matters. Without that evidence, the sponsor is signing off on faith, and the first month-end close in Fusion becomes a forensic exercise instead of a routine one.
Consultant-led GP-to-Fusion programmes routinely under-invest in this discipline. Reconciliation gets scoped as 'we'll spot-check a few balances' or 'we'll run the trial balance and review variances'. When the trial balance doesn't reconcile, the team scrambles to assemble PowerPoint explaining the variance to executive sponsors who are already nervous. When the auditors arrive in the first year-end after go-live and ask to trace 50 sample GL lines back to source evidence, the broken audit chains get discovered the hard way.
Dynamics gp data validation in Syntra ETL is the discipline built into the load flow. Every row hashed at source. Every row re-hashed at destination. Counts compared per company per period per vendor per customer. Sums compared per dimension. Hash signatures compared on the chain itself. Variances surfaced at field-level — not as 'this batch had 12 errors' but as 'voucher PM-12345 in company FAB1 fiscal period 2024-09 failed Fusion validation because supplier site code did not exist'. The audit pack assembles itself. Internal audit signs off on it directly. External auditors accept it as cutover evidence in the first year-end.
What internal audit and external audit actually receive — and what they sign off on.
GL30000 trial balance vs Fusion GL trial balance per company per fiscal period to the cent. Variance breakdown by account by source. Sign-off line per finance lead per company.
PM30200 vendor open balance vs Fusion Payables per vendor per BU. Aging bucket reconciliation. Apply history walk for sampled vouchers. Sign-off per AP lead.
RM30201 customer open balance vs Fusion Receivables per customer per BU. Aging bucket reconciliation. Cash apply history walk. Sign-off per AR lead.
IV00101 site quantities vs Fusion Inventory on-hand per warehouse. Cost-layer preservation for valuation continuity. Sign-off per inventory ops lead.
Sample GL lines walked from Fusion back through subledger to original GP source row. Hash signatures at every link. Auditor-ready trace evidence.
Known reconciling items captured (currency revaluation handled differently, periods reclassified, write-offs absorbed into Fusion subledger). Finance sign-off per exception.
A repeatable validation workflow with explicit finance sign-off gates. SMB scope: 3–5 days. Mid-market: 5–10 days. Multi-entity 12+ companies: 10–20 days.
GP-side baselines captured at extract time: row counts per table per company, sum totals per dimension, hash signatures per partition. These are the numbers Fusion has to reconcile against.
Engine runs the four mandatory checks (GL trial balance, AP aging, RM aging, item on-hand) per company per period. Variances surfaced at field level with drill-to-source-row.
Finance / AP / AR / inventory leads classify each variance: legitimate reconciling item (currency revaluation, period reclassification, deliberate write-off) or error requiring fix. Reconciling items captured in exception register with finance sign-off.
Errors requiring fix bulk-corrected (typically corrected at source data, re-extracted, re-transformed, re-loaded). Re-reconciliation runs. Goal: every per-company per-period trial balance to the cent (within signed exception register).
Hash-signed timestamped audit pack assembled. Internal audit walkthrough per company. External audit walkthrough where year-end is in scope. Sponsor sign-off as the formal cutover gate.
The patterns that trip up consultant-led reconciliation — handled deterministically by the validation engine.
Extract caught mid-period before final close in GP. Engine recognises the in-flight state, reconciles to the actual GP close balance once final, replays incremental deltas.
GP revaluation methodology differs from Fusion in subtle ways. Engine captures GP-side revaluation per period, compares to Fusion equivalent, flags the per-period delta as reconciling item with finance sign-off.
Customer-built inter-company in GP (often without the optional ICA module) flagged during extract. Reconciled against Fusion Intercompany or explicit elimination accounting per finance rule.
Open AP voucher in GP partially paid → split between historical apply and open balance in Fusion. Engine reconciles both sides, ensures aging total matches GP aging at cutover date.
Vendor consolidated from 3 GP company codes into one Fusion supplier. Engine reconciles consolidated Fusion balance against sum of source GP balances. Drift surfaced explicitly.
Account moved from one Fusion segment to another during transform. Engine reconciles per source GP account → per target Fusion combination, captures reclassification in the audit chain.
Dynamics gp data validation is the post-load reconciliation discipline that proves every row, every sum and every audit chain that existed in your Great Plains system has landed correctly in Oracle Fusion. The work goes beyond 'did the FBDI job complete' — that just tells you Fusion accepted the file. Real validation answers: does the trial balance per company per period match GP30000 to the cent in Fusion's general ledger? Does AP aging per vendor per BU match PM30200 to the cent in Fusion Payables? Does AR aging per customer per BU match RM30201 to the cent in Fusion Receivables? Does item on-hand per warehouse match IV00101 in Fusion Inventory? And critically: can an auditor trace any GL line in Fusion back to its original GP source row, with hash-signed evidence at every link?
Four mandatory checks plus optional extensions. Mandatory: (1) GL trial balance parity — GL30000 trial balance per company per fiscal period reconciles to Fusion GL trial balance per BU per period to the cent; (2) PM30200 vendor total reconciliation — open and historical AP balance per vendor per BU matches Fusion Payables; (3) RM30201 customer total reconciliation — open and historical AR balance per customer per BU matches Fusion Receivables, including apply-history detail; (4) Item on-hand parity — IV00101 site quantities reconcile to Fusion Inventory on-hand per warehouse. Optional extensions: SOP/POP open document parity, fixed asset NBV parity, bank rec statement parity, payroll YTD parity, and any Dexterity custom-field that finance flagged as reporting-material.
Reconciliation runs per company DB, then aggregated. The validation engine pulls GL30000 trial balance for each source company DB (TWO, FAB1, customer-specific codes), pulls Fusion GL trial balance for each target BU, and reconciles the per-company pair to the cent. If GP had inter-company transactions that Fusion now processes through native Fusion Intercompany, the elimination reconciliation is captured separately. SY01500 company master is preserved as a top-level dimension throughout the reconciliation pack so finance can see 'this is the parity check for company FAB1 → Fusion BU Northern Operations' rather than fighting with an aggregated number that hides per-company drift.
Variances are captured with explicit field-level diagnostics, not opaque error counts. For a GL trial-balance variance per company per period, the engine drills to the specific accounts that don't reconcile, the specific journal sources contributing to the variance, and the specific GP source rows that didn't make it to Fusion (with reason: validation rejection, transform skip, post-load adjustment). For a vendor balance variance, the engine drills to the specific vouchers and apply history that don't reconcile. The output is actionable — finance can either approve the variance as a known reconciling item (e.g., currency revaluation handled differently in Fusion), or trigger a bulk fix and re-reconcile.
A typical audit pack contains: per-company trial balance reconciliation (GP30000 vs Fusion GL per fiscal period to the cent), per-vendor AP aging reconciliation (PM30200 vs Fusion Payables), per-customer AR aging reconciliation (RM30201 vs Fusion Receivables), item on-hand parity (IV00101 vs Fusion Inventory), open SO and PO document parity, reconciliation pack metadata (extract timestamp, load timestamp, reconcile timestamp, run operator, sign-off owner), hash signatures over every reconciliation file, and an exception register for known reconciling items signed off by finance. The pack is timestamped and hash-signed end-to-end. Internal audit, external audit and Fusion go-live governance accept it as the formal cutover evidence.
Yes, for any Dexterity custom field or ISV add-on data field that the customer's finance team flagged as reporting-material during the migration assessment. The validation engine tracks every custom field through the extract → transform → load chain and reconciles the destination Fusion DFF, value-set or AMX attribute against the source GP value. For ISV add-on data (Mekorma MICR detail, Greenshades W-2 detail, Integrity Data payroll detail), the validation pattern is the same: source-vs-destination reconciliation at the field level for any data the customer needs preserved beyond GP retirement. Non-material custom fields can be deliberately scoped out with finance sign-off — not every custom field needs to migrate.
During the 1–2 fiscal period parallel-run window, both systems take transactions. Validation runs daily: pull GL30000 and Fusion GL trial balance for the day, reconcile per company per period; pull PM30200 and Fusion AP for the day, reconcile per vendor per BU; pull RM30201 and Fusion AR, reconcile per customer per BU. Daily variances are investigated and resolved before they compound. The parallel-run validation pack accumulates daily, with weekly sign-off checkpoints. By the end of the parallel window, finance has 30–60 days of daily reconciliation evidence proving that GP and Fusion produce the same answer — which is what gives executive sponsors confidence to cut production traffic to Fusion.
For a typical SMB scope (single-company or 2–3 company DBs): 3–5 days of validation work covering full historical and open reconciliation, plus the audit pack assembly. For mid-market 4–6 company DBs: 5–10 days. For multi-entity 12+ company DBs: 10–20 days. The validation engine itself runs in hours — the time goes into finance sign-off workshops where every reconciling item is reviewed, every variance is classified (legitimate reconciling vs error requiring fix) and the audit pack is signed off per company per period. That sign-off cadence is the work that consulting firms routinely under-scope and that the validation engine cannot compress.
Book a 30-minute walkthrough. We'll show you a sample audit pack from a recent GP-to-Fusion cutover — per-company trial balance to the cent, AP aging, AR aging, item on-hand, signed exception register — the way an internal auditor expects to see it.