Post-load peoplesoft data validation that proves data landed in Fusion matches source PeopleSoft to the cent. Row counts, sum totals, hash signatures, full drill-through from Fusion GL back to PS_ source. Signed audit pack accepted by internal audit and external auditors.
Fusion's standard FBDI and HDL job logs catch row-syntax errors. They cannot catch a successful load that posted the wrong amount, dropped 200 rows silently, or routed history to the wrong worker.
Every Fusion FBDI Journal Import job produces a log. The log shows N rows processed, M rows rejected, K rows successful. It is necessary, but it is not peoplesoft data validation. A successfully processed FBDI Journal Import can still result in $4.2M of voucher distributions posted to the wrong cost center because the SetID re-model had a documented gap that nobody flagged at sign-off. Or 47 workers loaded without their full effective-dated history because EFFSEQ collisions weren't handled in the HDL Assignment.dat builder. Or 200 PS_JRNL_LN rows silently failed downstream because the resolved ChartField combination hit a suspended GL code combination — Fusion accepted the rows then quarantined them.
None of that surfaces in a Fusion job log. It surfaces months later when finance closes the first post-migration period and the Trial Balance is off by $4.2M — at which point the original PeopleSoft environment has been frozen, the source extracts have aged out, and reconstructing what happened consumes a quarter of forensic effort.
Syntra ETL's peoplesoft data validation engine inverts that. Every load produces a signed reconciliation pack that proves source PS_ table state matches post-load Fusion state — at row, sum and hash level — before the load is accepted as final. Discrepancies surface in the next 24 hours, not the next quarter. Internal audit and external auditors sign off the pack directly, with full drill-through evidence.
Every load produces a signed evidence pack. Discrepancies surface before the next load runs.
PS_ table row count at source vs Fusion entity row count post-load, per BU per Ledger per Period (financial) or per legal employer per effective date (HCM). Variance threshold zero. Mismatch blocks downstream loads.
Posted amount per period per ledger reconciled to the cent. Per-currency totals reconciled for multi-currency ledgers. AP gross_amt per supplier per BU. AR receipt_amt per customer per BU. Headcount per legal employer.
Each PS_ table row hashed via deterministic content-hash at source and re-hashed post-Fusion-load. Hash drift surfaces as row-level diff showing source vs loaded value per field — catches transformation bugs.
PeopleSoft Trial Balance per BU per Ledger per Period queried via nVision or direct PS_LEDGER aggregation, vs Fusion Trial Balance via OTBI. Same period, same ledger, same BU — to the cent. SOX-relevant evidence.
PeopleSoft AP aging per supplier per BU per aging bucket vs Fusion AP aging. Same for AR aging per customer. Open balance to the cent. Critical for finance close in first post-cutover period.
PS_EMPLOYEES headcount per legal employer per effective date vs Fusion Worker count. PS_JOB effective-dated history depth vs Fusion Assignment HISTORY_DATA depth per worker. Position-to-worker mapping preserved.
Validation runs in parallel with the load and produces a signed pack before the load is accepted as final.
Immediately before extraction: snapshot of PS_ table state — row counts per partition, sum totals per relevant aggregation, hash signatures per row. Snapshot stored with timestamp and PSOPRDEFN audit context. Becomes the source-of-truth baseline.
PS_ table rows extracted, ChartField/SetID crosswalk applied, FBDI/HDL payloads built. Each transformation logged. Each transformation produces an intermediate hash compared to source hash via documented transformation rules.
FBDI ZIPs submitted to Fusion ESS. HDL bundles loaded via Worker. Job logs captured. Row-syntax errors surface here and feed back to the transformation layer for fix-and-resubmit.
Fusion entity state queried via OTBI and Fusion REST APIs. Row counts, sum totals, hash signatures compared against the T-0 source snapshot. Discrepancies classified critical/warning/informational and surfaced to the appropriate owner.
Critical discrepancies block downstream loads until resolved. Row-level diff published. Affected functional lead remediates either in source (re-extract), in transformation (fix crosswalk), or in target (Fusion manual correction). Re-validation runs.
Signed evidence pack produced as PDF + JSON bundle: Trial Balance parity per ledger per period, AP/AR aging parity per BU, Worker headcount parity per legal employer, row-level diff appendix for warnings, drill-through links. Reviewed and signed by finance, HR, audit leads.
The peoplesoft data validation pack format that internal audit and external auditors sign off directly. No reconstruction needed.
PeopleSoft TB per BU per Ledger per Period vs Fusion TB. Variance per period. Cent-level reconciliation evidence. SOX-relevant for first post-cutover close. Signed by Controller.
Per supplier per BU per aging bucket: PeopleSoft open balance vs Fusion open balance. Per-currency. Variance threshold $0.01. Signed by AP Manager.
Per customer per BU per aging bucket: PeopleSoft open AR vs Fusion open AR. Per-currency. Signed by AR Manager.
Per legal employer per effective date: PeopleSoft active/terminated/leave headcount vs Fusion headcount. Position-to-worker mapping preservation evidence. Signed by HR Director.
Per-row hash comparison summary: source hash vs loaded hash per PS_ table. Drift cases with row-level diff. Documented expected-transformation cases (XLAT, derivation) called out separately. Signed by Migration Lead.
Sample drill-through evidence: Fusion GL line → Journal Import batch → PS_JRNL_LN → PS_VOUCHER → PS_ATTACHMENT. Per-business-unit sample. Proves the audit chain works without source environment access. Signed by IT Audit Lead.
PeopleSoft data validation is the post-load reconciliation layer that proves the data landed in Oracle Fusion matches what came out of PeopleSoft 9.2 — to the cent on financial totals, to the person on headcount, and to the row on transactional history. It is not the FBDI/HDL job validation Fusion runs on row syntax; that catches malformed rows but cannot detect a load that succeeded with the wrong amount or missing 200 vouchers. Syntra ETL's peoplesoft data validation engine compares source PS_ table snapshots (PS_LEDGER, PS_JRNL_LN, PS_VOUCHER, PS_EMPLOYEES, PS_JOB) against the corresponding Fusion entities post-load using counts, sum totals, hash signatures and key-level diffs, then produces a signed evidence pack that internal audit and external auditors sign off directly.
FBDI and HDL job validation is row-syntax validation — it catches missing required columns, invalid lookups, broken supplier references, malformed dates. Necessary but not sufficient. A successfully processed FBDI Journal Import can still result in: 200 PS_JRNL_LN rows that silently failed because the ChartField combination resolved to a suspended GL code combination, $4.2M of voucher distributions posted to the wrong cost center because the SetID re-model had a gap, 47 workers loaded without their effective-dated history because EFFSEQ collisions weren't handled. None of that surfaces in Fusion's job log. Syntra ETL's peoplesoft data validation catches all of it by comparing source PS_ table state against post-load Fusion state at the row, sum and hash level.
Three layers of comparison per PS_ table per business unit per period. (1) Row counts: PeopleSoft source row count vs Fusion target row count, variance threshold zero. PS_LEDGER rows vs Fusion GL Period Balance rows. PS_VOUCHER vs Fusion AP Invoice. PS_JOB effective-dated rows vs Fusion Assignment HISTORY_DATA. (2) Sum totals: posted_total_amt per ledger per period, gross_amt + tax_amt per supplier per BU, monetary_amount per journal per currency, headcount per legal employer per effective date — all reconciled to the cent or to the person. (3) Hash signatures: each PS_ table row content-hashed at source and re-hashed post-load. Hash drift indicates transformation bug or data corruption — surfaced with row-level diff showing original vs loaded values.
Yes — full drill-through is the point. Syntra ETL preserves the PeopleSoft source key on every loaded row (FBDI Source Reference, HDL Source System ID, plus custom DFFs where Fusion's standard reference fields are insufficient). Drill from a Fusion GL Period Balance back to the Journal Lines that posted to it, back to the FBDI Journal Import batch, back to the PS_JRNL_LN rows that fed the batch, back to the PS_VOUCHER row that originated the journal entry, back to the PS_ATTACHMENTS row that holds the original PDF support document. Auditors get the complete chain without standing up the source PeopleSoft environment. Same drill path for AP, AR, Assets, Worker history.
Discrepancies are classified by severity and routed to the appropriate owner. (1) Critical (sum totals off by more than $0.01 per ledger per period, or row count mismatch): load is blocked, the FBDI/HDL batch is rolled back where possible, the row-level diff is published to the migration project workspace and the affected functional lead is paged. (2) Warning (hash drift on non-financial fields like description text, or expected-and-documented transformations like XLAT value translation): logged but not blocking. (3) Informational (effective-dated history collapsed per documented policy, redundant PeopleCode-derived defaults dropped per crosswalk sign-off): logged for audit. Every discrepancy produces a remediation ticket; nothing silently drops.
Yes — HCM peoplesoft data validation is structurally identical to financial validation: source PS_ table snapshot vs post-load Fusion HCM entity comparison. PS_EMPLOYEES row count vs Fusion Worker count per legal employer. PS_JOB effective-dated history depth vs Fusion Assignment HISTORY_DATA depth per worker. PS_POSITION_DATA vs Fusion Position. PS_PAY_CHECK vs Fusion Payroll Element Entry for current FY. PS_TL_RPTD_TIME vs Fusion Time and Labor record. Plus HR-specific reconciliation: active/terminated/leave status parity per worker per effective date, position-to-worker mapping preserved, manager hierarchy depth matches. Output is the same signed evidence pack format that finance gets — but reviewed and signed off by HR leads.
Multi-currency PeopleSoft data validation reconciles per-currency totals: PS_JRNL_LN.monetary_amount per currency_cd vs Fusion Journal Line per Entered Currency, AND PS_JRNL_LN.base_amount per base_currency vs Fusion Journal Line per Ledger Currency. Conversion rates (RATE_MULT, RATE_DIV) reconciled per journal date per currency pair. For intercompany, PS_JRNL_LN with INTERCOMPANY flag set vs Fusion Intercompany Transaction rows per Intercompany BU pair. PS_VCHR_DST rows that span intercompany cost centers vs Fusion Intercompany AP transactions. Mismatches in intercompany elimination amounts are flagged at consolidation level — critical for SOX sign-off on intercompany balances after migration.
Validation runs in parallel with the load itself. For a typical mid-size PeopleSoft migration (20+ Business Units, 7–10 years history, full HCM + FSCM scope), full peoplesoft data validation across all loaded entities takes 4–8 hours per pass. A typical migration runs 6–10 validation passes: initial bulk load, plus subsequent rebatch loads as discrepancies are resolved, plus 2–4 parallel-run period validations, plus a final pre-cutover validation. The signed evidence pack is produced as a single PDF + JSON bundle: Trial Balance parity per ledger per period, AP/AR aging parity per BU, Worker headcount parity per legal employer, plus row-level diff appendix for any non-critical warnings. Internal audit and external auditors sign off the pack directly.
30-minute call. We'll walk through your PeopleSoft footprint and reconciliation requirements — and show you exactly what the signed peoplesoft data validation pack looks like for your scenarios.