SAP Concur Data Validation — Hash-Signed, Audit-Ready

Concur data validation is the post-load reconciliation that proves the Concur to Fusion migration moved every expense report, every receipt image, every allocation, every card transaction without loss or distortion. Syntra ETL's concur data validation covers six layers: (1) count reconciliation — number of expense reports, entries, allocations, receipts per fiscal period per business unit; (2) sum reconciliation — total expense amount, reimbursable amount, tax amount, in each currency, per period; (3) hash signature reconciliation — header hash + entry hash + attachment hash per report, end-to-end; (4) receipt-image hash validation — every image SHA-256 signature preserved from Concur to Fusion attachment; (5) period reconciliation — month-end expense register tied to GL; (6) audit pack output — IRS Pub 463, SOX trace, EU/UK VAT recovery evidence.

Every receipt image extracted from Concur gets a SHA-256 hash computed at extract time, stored alongside the source ReceiptID and the original Concur image-id. When the image lands in Fusion's UCM attachment store (or in the long-term cloud archive), the hash is recomputed on the landed file. Concur data validation compares hash-for-hash and produces a defect list — any image where the post-load hash doesn't match the pre-load hash. In a well-run migration this list is empty; if not, the affected images are re-streamed and re-validated. The hash chain is also the IRS Pub 463 evidence — when auditors ask 'is this the same receipt image the employee submitted three years ago' the hash chain proves it bit-for-bit.

Each catches a different class of defect. Count reconciliation catches missing records — '527 expense reports in Concur for July 2024, only 525 in Fusion' — and is fast to compute. Sum reconciliation catches value distortion — counts match but the total expense amount is off by $1,247, often a rounding or currency-conversion defect. Hash reconciliation catches per-record corruption — counts and sums match but record-level field corruption has happened (e.g., a Description field got truncated, or an allocation rounding remainder routed differently). The Syntra ETL concur data validation runs all three layers in sequence — count first because it's cheap, hash last because it's exhaustive — and only signs off when all three pass.

Period reconciliation is the bridge from operational data (expense reports) to the financial close (GL). For every fiscal period in scope, concur data validation produces a reconciliation report: total expense-report-driven GL postings in Concur (from the legacy GL extract or Concur's reimbursement file) vs total expense-report-driven GL postings in Fusion (from Fusion's GL journal). Difference = zero is the pass condition. If there's a difference, the variance is broken down by expense category, by business unit and by approver, and the offending records are surfaced. Period reconciliation is the artifact finance leaders care about most because it's the artifact that lets them sign off on the cutover without writing a six-figure reserve.

The audit pack is the signed, timestamped output bundle that proves the concur data validation passed. Contents: count reconciliation report (per period, per BU, per expense category); sum reconciliation report (per currency, per period, per BU); hash signature reconciliation (record-level, with any defects called out); receipt-image hash chain (every receipt's pre/post hash with the SourceReference); period-to-GL reconciliation; receipt-image substantiation evidence (IRS Pub 463 retrievability proof for a sample of 100 receipts spread across the retention window); SOX trace evidence (GL journal → ExpenseDistribution → ExpenseItem → ExpenseAttachment chain demonstrated end-to-end for a sample); EU/UK VAT recovery evidence (gross/net/tax preservation, vendor VAT registration carried). Internal audit signs off on the pack; external auditors test it during the post-go-live SOX cycle.

Yes — and this is a class of defect most migration tools miss. Concur's Audit Service flags policy violations (over-limit, missing receipt, alcohol policy, etc.) with the violation reason, the override approver and the override justification. If that violation context isn't preserved through the migration, the Fusion expense report looks compliant when it actually carried an approved override. Concur data validation reconciles the violation context: for every Concur expense report with a recorded violation, the violation type and override approver are checked against the Fusion ExpenseHeader DFF or attachment metadata where they were routed by the data mapping. Any report where the context is missing is flagged and the routing is corrected before sign-off.

Yes. Corporate-card transactions don't just need to reconcile Concur to Fusion — they need to reconcile to the upstream card-provider statement (Amex, Visa, Mastercard). Concur data validation pulls the card-provider statement file for the period(s) in scope, reconciles count and sum to both Concur's card-transaction load (the file Concur received) and Fusion's CorporateCardTransaction records (the records post-cutover). Any transaction present in the provider file but missing from Fusion is a feed-cutover defect — common during the parallel-run window — and gets manually replayed. The reconciliation is per-card, per-cardholder, per-period.

For a typical full-scope concur migration (Expense + Travel + Invoice, multi-TB receipt images, 24 months of operational history), concur data validation runs across the parallel-run window — 2–3 weeks. Automated reconciliation (counts, sums, hashes) runs nightly and surfaces defects within hours of extract. Manual review by finance and T&E ops is concentrated in the period reconciliation step (1–2 days per fiscal period). Internal audit signs off on the audit pack in the final 3–5 days before cutover, typically with a one-hour sign-off meeting after reviewing the bundle. Syntra ETL produces every artifact; the customer's finance, T&E ops, compliance and IA teams review and sign off.