Concur load automation that turns Concur extracts into Fusion-ready FBDI ZIPs and REST payloads, submits via ESS, tracks jobs, routes failures, binds receipt images via UCM, and emits a complete signed run log for audit.
Generating FBDI ZIPs, submitting via ESS, polling jobs, routing failures, uploading receipts to UCM, running REST API deltas — the orchestration layer that turns 'extract complete' into 'data is live in Fusion'.
Without concur load automation, every Fusion Expenses load becomes a manual SOAP-era ceremony. Generate a CSV. ZIP it. Upload to UCM. Navigate Fusion's Scheduled Processes UI. Submit Manage Expense Report Imports. Wait 4 hours. Pull the ESS log file. Forensics-grep it for errors. Cross-reference offending row numbers back to the source CSV. Repeat for the next batch. Repeat for receipts (separate UCM upload, separate attachment metadata generation). For a real Concur migration with hundreds of thousands of expense reports and multi-TB of receipt images, that ceremony is a multi-month, multi-person operation. And it's where most concur load automation projects spend their last 8 weeks.
Syntra ETL's concur load automation collapses that into a DAG of orchestrated steps. FBDI generation is automatic from staged Parquet. ESS submission is API-driven. Job polling is continuous with backoff. Failure-queue routing is automatic with row-level diagnostics. Receipt-image upload to UCM is parallel-streamed with hash validation. REST API deltas run continuously during parallel-run with checkpointed watermarks. The whole thing emits a complete signed run log per execution.
The same orchestration handles every Concur-to-Fusion scenario: initial bulk load of multi-year history, parallel-run delta replay, post-cutover hybrid loads where some Concur data continues to flow during the decommission window, and audit-retrieval scenarios where a historical receipt image needs to be pulled from long-term archive.
The initial bulk load of Concur history into Fusion Expenses. FBDI is the Fusion-native bulk mechanism — concur load automation makes it fast and reliable.
Staged Parquet data transformed per the data-mapping crosswalk and emitted as Fusion-validated FBDI Expense Report Import ZIPs. Each ZIP sized to 50K–100K rows for ESS efficiency.
FBDI ZIPs uploaded to Fusion UCM and submitted to Manage Expense Report Imports ESS process via REST. ESS Job IDs captured and persisted to the run log.
ESS job state polled via Fusion REST API with exponential backoff to respect rate limits. State machine: Wait → Running → Completed (or Error/Warning/Cancelled).
On completion, ESS log file pulled from UCM and parsed for row-level errors. Field-level failure reason extracted from each error row.
Failed rows grouped by failure reason. Bulk fix applied (e.g., missing workers loaded). Retry queue re-submitted via the same FBDI path. Final disposition logged.
Count diff (rows in vs rows successfully loaded), sum diff (total expense amount), hash diff (header + entry hash) computed per ESS submission. Output: per-submission reconciliation row in the run log.
The two parallel paths that run alongside FBDI bulk: receipt-image upload to UCM and REST API delta replay for parallel-run.
Receipts API streamed in parallel — 25 concurrent connections respecting Concur rate limits. SHA-256 hash computed at stream time. SourceReceiptID indexed in hash registry.
Receipt images uploaded to Fusion UCM (Oracle Content Server) via UCM REST API. Folder structure mirrors Fusion BU/expense-template hierarchy. UCM document ID returned.
Attachment metadata rows generated linking each ExpenseHeader/ExpenseItem to its UCM document ID. Bound into the FBDI Expense Report Import ZIP.
During parallel-run, Concur REST API polled every 15 minutes using modified-since watermark per domain (reports, receipts, card transactions, approval changes).
Delta records run through the same transformation pipeline as bulk load and submitted to Fusion via Expense Report REST API for near-real-time replay.
Modified-since watermarks checkpointed per domain per BU after every successful poll. A re-run picks up exactly where the last successful run left off.
Fusion Expenses has hard dependencies between objects. Concur load automation enforces the dependency DAG so a downstream step never starts before its prerequisites complete.
Fusion enterprise structures, ledgers, BUs, COA segments, expense templates, AMX flows, corporate-card programs configured via FSM. Not data load — but everything downstream depends on it. Sign-off required before next step.
Worker.dat loaded via HCM Data Loader. PersonNumber crosswalk validated against Concur EmployeeID mapping. Workers without a matching Fusion record routed to project-managed creation queue.
Expense Templates, Corporate-Card Programs, Vendor Master (from Concur Invoice) loaded via FBDI. Each step polled to ESS Completed before next step starts.
Receipt-image streaming begins in parallel to structured data. Runs continuously for the bulk window (multi-TB takes 5–10 days). Hash chain populated per receipt.
Expense Report Import FBDI submitted with receipt-attachment metadata pre-bound. Bulk ZIPs sized 50K–100K rows. ESS jobs polled. Failure queue worked. Reconciliation per submission.
Corporate-Card Transaction Import FBDI submitted. Card transactions matched to expense entries where pre-matched in Concur. Reconciliation to provider statement validates the load.
Concur load automation is the orchestration layer that takes data extracted from SAP Concur, transformed per the data-mapping crosswalks, and submits it to Oracle Fusion Expenses through Fusion's load mechanisms — FBDI for bulk, REST APIs for incremental, ESS for job tracking, UCM for attachments. Syntra ETL's concur load automation handles: generating FBDI Expense Report Import ZIPs from staged Parquet data; submitting via Fusion ESS jobs (Manage Expense Report Imports); polling ESS job state; pulling job-level error logs; routing failed records to a failure queue with row-level diagnostics; binding receipt images via FBDI attachment metadata; running REST API delta loads during parallel-run; emitting reconciliation reports per ESS submission. Without this automation, each FBDI submission is a manual SOAP-era ceremony.
Both are Fusion-native load mechanisms but they serve different scenarios. FBDI (File-Based Data Import) is the bulk path: ZIP files with CSVs, submitted to ESS, processed in batches of thousands to hundreds of thousands of rows. Best for the initial bulk load (full Concur history into Fusion). REST APIs are the incremental path: single-record or small-batch submissions, processed in near-real-time. Best for parallel-run delta replay (Concur changes during the parallel window, replayed to Fusion within minutes) and post-cutover hybrid scenarios. Concur load automation uses both — FBDI for the initial bulk, REST for everything after. A single orchestration layer routes records to the appropriate path based on volume and freshness requirements.
FBDI loads go through Fusion's ESS (Enterprise Scheduler Service) which assigns each submission an ESS Job ID. Concur load automation polls the ESS job state machine — Wait → Running → Completed (or Error/Warning/Cancelled) — through Fusion's ESS REST API, with backoff to respect Fusion's rate limits. On completion, the automation pulls the job-level log file (the .log emitted to UCM by the FBDI process), parses it for row-level errors, and routes any failed rows to a failure queue with the exact field-level reason ready for bulk fix. ESS Job IDs and outcomes are persisted to the run log for audit. A failed FBDI ZIP isn't a 4-hour mystery — it's a row-level diagnostic surfaced within minutes of the job completing.
Receipt images go through a parallel path to the structured expense data. Concur load automation: (1) streams images from Concur's Receipts API to staging, with SHA-256 hash and SourceReceiptID indexed in the hash registry; (2) uploads images to Fusion's UCM (Oracle Content Server) via UCM REST API with proper folder structure and metadata; (3) writes the FBDI Expense Report Import attachment metadata rows referencing the UCM document ID; (4) re-validates the post-upload SHA-256 hash against the pre-load registry to confirm no corruption; (5) emits the hash chain to the audit pack. Receipt image migration runs in parallel to structured data migration and the two are joined at the FBDI submission step via the attachment metadata rows.
Yes — failed-record routing is the heart of why the automation exists. When a Fusion ESS job emits an error or warning, concur load automation parses the job log file, identifies the offending row, captures the field-level failure reason (typically 'invalid worker', 'invalid expense template', 'missing approver', 'duplicate report number'), and routes the row to a failure queue. The failure queue groups rows by failure reason so a 5,000-row 'invalid worker' batch can be bulk-fixed in one operation (workers loaded, retry queue re-submitted) rather than as 5,000 individual investigations. The failure queue is visible in the run dashboard for both Syntra ETL ops and the customer team — no log-file forensics required.
Yes — the REST API delta-replay path is purpose-built for parallel-run. During the 2–3 week parallel-run window, Concur continues taking expense submissions while Fusion is being validated. Concur load automation polls Concur's REST API every 15 minutes using the modified-since watermark on each domain (expense reports, receipts, corporate-card transactions, approval state changes), pulls the delta records, runs them through the same transformation pipeline as the bulk load, and submits via Fusion's REST APIs (Expense Report REST API, Corporate Card Transaction REST API) for near-real-time replay. The watermarks are checkpointed so a re-run picks up exactly where the last successful run left off.
Fusion Expenses has hard dependencies between objects: workers must exist before expense reports referencing them load; expense templates must be configured before expense reports load; corporate-card programs must be configured before card transactions load. Concur load automation handles dependency sequencing automatically. The run plan is a DAG of load steps: foundation (FSM) → workers (HDL) → expense templates (FBDI) → corporate-card programs (FBDI) → expense reports (FBDI) → receipt images (UCM + FBDI attachment metadata) → corporate-card transactions (FBDI). Each step waits for its prerequisites to complete (ESS Completed status), and a failure at any step blocks downstream steps until resolved. No 4-hour FBDI submission failing on row 47,000 because the worker reference didn't exist.
Every concur load automation run emits a complete, signed run log to the audit pack. Contents: source-extract manifest (Concur API endpoints called, rate-limit consumption, row counts, hash signatures); transformation log (crosswalk version applied, any defaulted fields, any data-quality warnings); FBDI generation manifest (ZIP file paths, CSV row counts per object); ESS submission log (every ESS Job ID submitted, outcome, completion timestamp, ESS log file UCM path); failure-queue contents (failed rows by reason, retry count, final disposition); receipt-image hash chain (SourceReceiptID → pre-load hash → UCM doc ID → post-load hash); reconciliation outputs (count/sum/hash diff). Total artifact bundle is typically 50–200 MB and is the source-of-truth for any post-cutover audit question.
Book a discovery call. We'll walk through your Concur data volumes, receipt-image archive size and Fusion target topology — and produce a concur load automation plan with the DAG, throughput estimates and failure-handling sequence in under 30 minutes.