Concur fusion integration for hybrid scenarios — real-time and batch bridges between SAP Concur and Oracle Fusion Expenses. Corporate-card pass-through, approval-workflow bridging, OAuth2-governed REST sync, signed audit log.
The runtime gap between Concur and Oracle Fusion Expenses during cutover transition, phased multi-BU rollout, or long-term hybrid co-existence — through real-time REST sync, batch reconciliation, corporate-card pass-through and approval-workflow bridging.
Most concur migrations imagine a single-event cutover: Concur fully off, Fusion fully on, the weekend the bridge gets crossed. Reality is rarely that tidy. Acquisitions leave subsidiaries on Concur while the parent runs Fusion. Regional finance teams have distinct close calendars and can't cut over together. Corporate-card providers need a 2-week pass-through window to handle late-posting transactions. Approvers cut over before submitters and need to act on reports still living in the old system. Every one of those scenarios is a hybrid-co-existence problem that concur fusion integration solves.
Syntra ETL's concur fusion integration is the bridge layer that makes hybrid scenarios safe and auditable. Real-time REST sync handles user-facing data domains where freshness matters (expense submissions, approvals, card-transaction posting). Batch reconciliation handles audit-facing data domains where end-of-day completeness matters (expense register, GL journal cross-validation, audit-rule violation reporting). Corporate-card pass-through ensures cardholders see their transactions regardless of which system they're using. Approval-workflow bridging routes approvals to the manager's current system-of-record.
Every bridge runs as a governed integration — OAuth2 scoped clients on the Concur side, scoped Fusion service accounts on the target, token rotation enforced, every call logged with PII redacted and hash-signed for SOC 2 evidence. The audit trail demonstrates that no data crossed the bridge without authorization.
Different scenarios call for different bridge configurations. Picking the right ones from project kick-off saves weeks of operational friction.
Standard cutover with a 2–4 week parallel-reconciliation window. Real-time REST sync active for delta replay. Batch reconciliation for nightly cross-validation. Corporate-card pass-through during the card-feed overlap. Bridges retired at sign-off.
Multiple business units cutting over on a staggered schedule (3–9 months end-to-end). All four bridges active for the duration. Cross-BU approval routing and shared corporate-card programs require all bridges live.
Subsidiary on Concur, parent on Fusion (or similar). Steady-state operation. All four bridges active indefinitely. Operational support transitions from migration team to platform engineering.
M&A scenario — newly acquired company on Concur, acquirer on Fusion. Real-time sync for consolidated reporting. Card pass-through if cardholders span both. Approval bridging if approvers do.
Customer keeps Concur Travel for the online booking tool but moves Expense to Fusion. Itinerary data flows Concur → Fusion via REST sync to drive per-diem calculations. Real-time only, no card or approval bridging.
Pre-cutover parallel-run window where both systems take the same input (e.g., reports filed in Concur are replicated to Fusion for validation). Real-time sync plus batch reconciliation. Approval bridging not needed.
Every bridge endpoint is scoped, logged, and hash-signed. The integration is built for SOX testing and SOC 2 evidence, not just for data flow.
Concur-side endpoints run as OAuth2 clients with minimum-scope grant — read-only where possible, write only where required. Token rotation enforced. Client secrets in customer-managed vault.
Fusion-side endpoints run as service accounts with scoped role assignment — only the roles needed for the specific bridge surface. No broad-grant production access from the integration layer.
Every REST call (Concur and Fusion) logged with request/response payload, timestamp, source IP, response status. PII redacted at log-write time per the customer's data-classification rules.
Daily log files SHA-256 signed and persisted to immutable storage. SOC 2 evidence retention window respected. Read-access logged with signed timestamps for chain-of-custody.
Concur REST API rate limit (typically 25 req/s/tenant) and Fusion REST API rate limits respected per-bridge. Exponential backoff on 429 responses. No bridge can starve another tenant's API access.
Bridge endpoints deployed in regions matching customer data-residency requirements. EU data stays in EU regions. US data stays in US regions. Audit log captures the processing-region for each call.
From bridge provisioning through retirement. Each phase has its own operational requirements and sign-off gates.
OAuth2 clients registered with Concur (read+write scopes as required). Fusion service accounts created with scoped role assignment. Vault secrets populated. Bridge endpoints deployed to customer's preferred region. Smoke tests pass.
All required bridge surfaces activated. Real-time REST sync starts polling Concur deltas. Batch reconciliation jobs schedule to nightly cadence. Corporate-card pass-through kicks in for the overlap window. Approval bridging starts routing.
Dashboard surfaces every bridge endpoint's health: success rate, p99 latency, rate-limit consumption, failure-queue depth. On-call rotation responds to any failures within SLA. Daily reconciliation report reviewed by ops.
When batch reconciliation surfaces a variance (record present in one system but not the other), variance triage owner investigates root cause, applies fix (re-replay via REST, manual entry, or accept-with-note), updates the variance log.
For single-event cutovers and bridge-retirement scenarios: bridge endpoints scheduled for deactivation. OAuth2 clients revoked. Service accounts disabled. Variance log signed off. Audit evidence archived to long-term storage.
Bridge endpoints deactivated. OAuth2 clients revoked. Final audit log archived with SHA-256 signature. Concur tenant transitioned to read-only archive mode. Operational responsibility transferred from migration team to BAU.
Concur fusion integration is the runtime bridge between SAP Concur and Oracle Fusion Expenses when both systems are operational at the same time — typically during the cutover transition (where Concur is in read-only mode and Fusion is taking new submissions) and during longer hybrid co-existence scenarios where some business units stay on Concur while others move to Fusion. Syntra ETL's concur fusion integration covers four bridge surfaces: real-time data sync via REST APIs, batch reconciliation via Fusion Cloud Storage and Concur file exports, corporate-card pass-through where the same card-transaction file feeds both systems during transition, and approval-workflow bridging where an expense submitted in Concur is approved by a manager already cut over to Fusion.
Both, depending on the data domain. Real-time integration via REST API is used for: expense report submission deltas (Concur → Fusion within 15 minutes during parallel-run), approval state changes (Concur approval → Fusion AMX state sync), and corporate-card transaction posting (provider feed → both systems during the card-feed-cutover overlap window). Batch integration via file extract is used for: end-of-day expense register reconciliation, GL-journal cross-validation, audit-rule violation reporting and OTBI-vs-Cognos report-output comparison. The split is driven by data freshness requirements — anything user-facing goes real-time, anything reconciliation-facing goes batch.
Corporate-card pass-through is the trickiest concur fusion integration scenario because the card-provider feed is upstream of both Concur and Fusion. During the cutover overlap window — typically the 2-week period where Concur is in read-only mode but Fusion is being validated — the same Amex/Visa/Mastercard T-feed file needs to be processed by both systems so cardholders see their transactions in whichever system they're using. Syntra ETL's pass-through pattern: card provider continues to deliver the file to Concur during the overlap; Concur load completes; the same file is mirrored to Fusion's corporate-card import; both systems hold the same transaction set. Late-posting transactions discovered post-cutover are caught in the parallel reconciliation window.
Approval-workflow bridging handles the scenario where an expense report submitted in Concur needs approval from a manager already cut over to Fusion (or vice versa). The bridge: when a Concur report enters 'awaiting approval' state, concur fusion integration polls Concur's Approval API, identifies the approver, checks the approver's current system-of-record (Concur or Fusion) in the worker crosswalk, and routes the approval notification accordingly. If the approver is on Fusion, the report is created in Fusion as a 'pending approval' record with full original Concur context (ReportID, attachments, allocations) and the approver acts in Fusion's AMX. The approval action is then mirrored back to Concur's API to close the loop. This pattern is essential when business units cut over at staggered dates.
Yes — and phased cutover is one of the most common reasons concur fusion integration is needed. Some organizations can't cut over every business unit on the same weekend (acquisition timelines, regional finance team availability, distinct close calendars across geographies). The pattern: BU-1 cuts over in month 1, BU-2 in month 3, BU-3 in month 6. During each gap window, the BUs still on Concur and the BUs already on Fusion share a corporate-card provider feed, share an approval chain (when managers approve across BUs), and share a consolidated GL. Concur fusion integration provides the bridge surfaces — REST sync, batch reconciliation, card-feed pass-through, approval bridging — so the gap windows don't require disabling cross-BU operations.
Every bridge endpoint runs as a scoped OAuth2 client on the Concur side and as a service account with scoped role assignment on the Fusion side. Token rotation is enforced; secret management uses the customer's vault (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager); rate limits are respected per-tenant. Every API call is logged with full request/response context (PII redacted) and the log is hash-signed for SOC 2 evidence. The audit trail demonstrates that no data crossed the bridge without authorization — important for SOX testing and for the EU/UK VAT recovery audit window where data-residency rules require evidence of where data was processed.
It depends on the scenario. For a clean single-event cutover, concur fusion integration runs for the 2–4 week parallel-reconciliation window — bridge surfaces active during the window, decommissioned after sign-off. For phased multi-BU cutover, integration runs for the duration of the phased program — typically 3–9 months across all phases. For long-term hybrid co-existence (rare, but real when an acquisition leaves Concur active for a specific subsidiary while the parent runs Fusion), integration runs indefinitely as a steady-state operation, with operational support transitioning from migration to platform engineering.
The integration cost is small compared to the cost of siloed dual-platform operation. Siloed operation requires manual reconciliation across systems (typically 0.5–1 FTE per BU), duplicated user-management (workers exist in both systems with separate identity), separate audit-evidence collection for SOX/IRS/VAT, and double-charging from corporate-card providers (because the same cardholder appears in both systems). Concur fusion integration as a Syntra ETL service runs at a fraction of that — typically 5–10% of the siloed operating cost — because the bridges are automated and the audit evidence is collected once across both systems.
Book a discovery call. We'll walk through your cutover scenario (single-event, phased, or long-term hybrid) and produce a concur fusion integration plan with the required bridge surfaces, security model and operational SLA in under 30 minutes.