Pre-built concur data mapping for every standard object — Expense Report, Itinerary, Cash Advance, Mileage, Card Transaction, Allocation, Receipt. Custom Field routing through governed crosswalks. Every mapping reversible for audit.
Translating Concur's Expense Report → Itinerary → Allocation → Receipt model into Fusion's Expense Report → Expense Item → Distribution → Attachment model — field by field, with audit-grade traceability for every routing decision.
Concur's data model is shaped by its origins as a cloud-native T&E platform. Expense Reports contain Expense Entries, which contain Itemizations and Allocations. Receipts attach to Entries (or sometimes directly to Reports) with both image data and OCR-extracted metadata. Itineraries carry segment-level travel data (air, hotel, car, rail) that drives per-diem calculations. Cash Advances track money paid out before expenses are filed. Mileage logs capture point-to-point distance for vehicle expense calculations. Corporate-Card Transactions flow in as T-feeds from Amex/Visa/Mastercard.
Oracle Fusion Expenses has a tighter, more normalized data model. Expense Reports contain Expense Items, which contain Distribution lines (the multi-way cost split rows). Attachments are managed through UCM. Corporate Card Transactions are a separate object that gets matched to Expense Items during entry. There's no native Itinerary, no native Cash Advance ledger separate from regular AP, no native Mileage log object — those concepts have to be translated, not lifted.
Syntra ETL's concur data mapping is the governed translation between the two models. Every source field gets a routing decision: native target field, target DFF, COA segment, archive object or retired. Every routing decision is signed off in a versioned YAML crosswalk that ships as part of the project deliverables. When auditors test SOX controls post-go-live, the crosswalk YAML is the evidence document.
The 28 source fields on a Concur Expense Report header and their Fusion ExpenseHeader destinations. The most common fields shown here; the full crosswalk ships as a project deliverable.
Source Concur ReportID preserved as a prefix on the Fusion ExpenseReportNumber. Format: CNCR-{ReportID}. Enables direct cross-reference from any Fusion expense report back to the original Concur report.
Concur EmployeeID translated to Fusion PersonNumber via the worker crosswalk loaded during HCM Data Loader prep. Workers without a matching Fusion record get a project-managed worker-creation queue.
CreateDate → CreationDate (UTC), SubmitDate → SubmissionDate (UTC). Time zones preserved where Concur captures them; if not, UTC default applied. Both fields drive Fusion's age-based reporting.
TotalAmount in submission currency → ExpenseReportTotal. Reimbursement currency mapped separately to ReimbursementCurrencyCode. Exchange rate context preserved for multi-currency reports.
Concur ApprovalStatus (DRAFT, SUBMITTED, A_APPROVED, A_AUTHRZD, PAID, etc.) translated to Fusion Status via state mapping table. In-flight states preserved with approver chain via AMX.
Concur PolicyID (which drives which expense types and audit rules apply) translated to Fusion ExpenseTemplate via the expense-template crosswalk. Required field — no nulls allowed.
Entry-level and allocation-level fields. These drive the actual Fusion Expense Item and Expense Distribution rows that hit the GL.
Concur ExpenseType (Meals, Airfare, Hotel, etc.) mapped to Fusion Expense Template Item via expense-type crosswalk. Drives natural-account derivation in the COA crosswalk.
Amount in transaction currency → ReceiptAmount. ExchangeRate preserved as part of the report. ReimbursableAmount calculated in Fusion via standard reimbursement rules.
Concur TransactionDate → Fusion ReceiptDate. Drives period assignment for GL posting. Cross-validated against OCR.Date from the receipt image if available.
Concur Description (typically a free-text entry) preserved to Fusion Description. Truncated to 240 characters if needed; original preserved in the archive.
Each Concur Allocation row becomes one Fusion ExpenseDistribution row. Percentage and Amount preserved. Cost-object fields routed via COA segment crosswalk.
Customer-specific custom allocation fields (often project tags, internal orders, statistical accounts) routed to ExpenseDistribution DFFs via the Custom Field crosswalk.
The crosswalk doesn't write itself. Here's how Syntra ETL builds the concur data mapping crosswalk YAML for a real customer.
Concur tenant inventory via Admin APIs: every Custom Field, every expense type, every policy group, every workflow definition. Output: machine-readable JSON catalog.
Syntra ETL's standard concur data mapping defaults applied to all native Concur objects. 80% of fields auto-mapped on first pass. Output: crosswalk YAML draft.
Functional, technical and compliance leads walk every Custom Field, every overridden default and every routing decision. Decisions captured in the crosswalk YAML with owner and timestamp.
Sample of 500 expense reports extracted, mapped per the crosswalk, dry-loaded to Fusion non-prod. Field-by-field diff against expected output. Any mapping defect surfaces here, not in production.
Crosswalk YAML reviewed, signed off by finance, T&E ops, compliance and IT. Locked in source control. Version pinned to the project gantt.
Crosswalk YAML, sample-extract validation report and sign-off pack assembled into the audit evidence bundle. Becomes the SOX testing artifact for the post-go-live audit.
Concur data mapping is the field-level translation between SAP Concur's data model — Expense Report, Itinerary, Cash Advance, Mileage, Card Transaction, Allocation, Receipt — and Oracle Fusion Expenses' data model — Expense Report, Expense Item, Distribution, Attachment, Corporate Card Transaction. Syntra ETL ships pre-built concur data mapping for every standard Concur object: Expense Report header → Fusion ExpenseHeader (with 28 mapped fields), Expense Entry → Fusion ExpenseItem (32 fields), Allocation → Fusion ExpenseDistribution (12 fields), Card Transaction → Fusion CorporateCardTransaction (18 fields). Customer-specific Custom Fields are mapped through governed crosswalks at project kick-off.
Concur Expense Report header maps to Fusion ExpenseHeader at the field level: ReportID → ExpenseReportNumber (with Concur prefix preserved for cross-reference), ReportName → Description, EmployeeID → PersonNumber via worker crosswalk, CreateDate → CreationDate, SubmitDate → SubmissionDate, TotalAmount → ExpenseReportTotal, ApprovalStatus → Status (via state mapping table), PolicyID → ExpenseTemplate via expense-template crosswalk, ReportTotalApproved → ApprovedAmount, ReimbursementCurrency → ReimbursementCurrencyCode, plus 18 additional fields. The concur data mapping is reversible — every Fusion field carries a reference back to the source Concur field for audit. Custom report-header fields route to Fusion ExpenseHeader DFFs through the Custom Field crosswalk.
Concur receipts carry both image data and OCR metadata. The concur data mapping for receipts is: ReceiptID → Fusion ExpenseAttachment.SourceReference (preserved for cross-reference), ReceiptImage (binary) → Fusion attachment file via FBDI attachment metadata, ContentType → MimeType, UploadDate → CreationDate, ReceiptType → AttachmentCategory, OCR.Amount → captured as a validation cross-check against ExpenseItem.Amount, OCR.Vendor → captured for vendor matching, OCR.Date → ReceiptDate. The image binary itself is streamed to UCM (Oracle Content Server) and the FBDI Expense Report Import references it by the file path Syntra ETL emits. The full chain — GL journal → Distribution → ExpenseItem → ExpenseAttachment → original Concur ReceiptID — is preserved for IRS Pub 463 substantiation.
Concur supports multi-way Allocations — a single expense entry split across multiple cost-centers, projects, internal orders. The concur data mapping converts each Allocation row to a Fusion ExpenseDistribution row. Field-level: AllocationID → DistributionLineNumber, Percentage → DistributionPercentage, Amount → DistributionAmount, CostObject1 (typically cost-center) → ChargeAccount segment via COA crosswalk, CostObject2 (typically project) → ProjectNumber via project crosswalk, plus any customer Custom Allocation Fields routed to Fusion ExpenseDistribution DFFs. Allocation rounding is reconciled — Concur's percentage-based allocations sometimes leave a 1-cent rounding remainder, and the concur data mapping rule explicitly assigns the remainder to the first allocation line for repeatability.
Concur Itineraries (segment-level travel data: air, hotel, car, rail) don't have a 1:1 Fusion equivalent because Oracle Fusion Expenses doesn't carry an itinerary module — it expects pre-trip approval and post-trip expense reporting. The concur data mapping routes itinerary data through two paths: (1) per-diem and meal calculations driven by itinerary days → Fusion Expense Item with appropriate Per Diem expense type; (2) full itinerary detail → Fusion archive object store, indexed by ReportID for audit retrievability. The customer keeps the audit trail (which is what regulators care about) without forcing a non-existent Fusion module. If the customer is using Oracle Fusion Travel and Expenses (when GA), itineraries map natively.
Concur Custom Fields are configurable per-tenant fields appearing on report headers, expense entries, allocations and attendees. The concur data mapping handles them through a governed crosswalk built at project kick-off. Step 1: inventory every active Custom Field (name, type, level — header/entry/allocation/attendee — usage statistics, business purpose). Step 2: classify by reporting materiality — required vs optional vs analytical. Step 3: route — required fields collapse into Fusion COA segments where possible, optional fields route to the corresponding Fusion DFF (ExpenseHeader DFF, ExpenseItem DFF, ExpenseDistribution DFF), analytical-only fields route to OTBI dimensions via the archive. Every routing decision is signed off by finance and locked in the crosswalk before extract.
Concur ingests corporate-card transactions as T-feeds from Amex/Visa/Mastercard with rich metadata. The concur data mapping converts each card transaction to a Fusion CorporateCardTransaction record. Field-level: TransactionID → CorporateCardTransactionId, CardNumber → CardNumber (masked, with cardholder PersonNumber via worker crosswalk), MerchantName → MerchantName, MerchantCategoryCode → MerchantCategoryCode, TransactionDate → TransactionDate, PostingDate → PostingDate, Amount → BilledAmount in original currency, ExchangeRate → ExchangeRate, ReimbursableAmount → ReimbursableAmount, ExpenseReportID (if matched) → ExpenseReportNumber for the matched expense report. Card-program and BIN range context flow into Fusion's corporate-card configuration, not into the transaction record itself.
Every concur data mapping decision in Syntra ETL is configurable through a governed crosswalk — never hard-coded. Standard Concur object fields ship with default mappings refined across dozens of Concur migrations, but every default is overridable at project kick-off. The crosswalk file is a versioned, source-controlled YAML document with one row per source-field-to-target-field decision, an owner column, an approval timestamp and a rationale comment. When auditors arrive (internal audit during the project, external during SOX testing post-go-live) the crosswalk YAML is the evidence document — not screenshots, not undocumented SQL. Customer-specific Custom Field routing is the bulk of the crosswalk work, and gets the same governance.
Book a discovery call. We'll walk through your Custom Field design, expense-type catalog and policy groups — and produce a draft concur data mapping YAML scoped to your tenant in under 30 minutes.