SAP S/4HANA DATA MAPPING

    SAP S/4HANA Data Mapping to Oracle Fusion — Field by Field

    The complete SAP S/4HANA data mapping pack for Oracle Fusion — BKPF/BSEG and ACDOCA → GL Journals, KNA1/KNB1 → Customers, LFA1/LFB1 → Suppliers, MARA/MARC → Items, EKKO/EKPO → Purchase Orders. CDS view extraction, BAPI routing, governed crosswalks, full audit traceability.

    47
    Source tables mapped
    12
    Fusion FBDI templates targeted
    CDS + BAPI
    Cloud-friendly access modes
    Audit-ready
    PDF + CSV per object

    What SAP S/4HANA data mapping to Oracle Fusion really requires

    The challenge isn't the obvious one-to-one mappings — it's account-assignment collapse, hierarchy translation, and effective-dated history reshaping.

    Any junior consultant can map MATNR to ITEM_NUMBER. The hard mappings — the ones that consume the most consulting time and cause the most cutover defects — are the dimensional collapse from SAP's account-assignment model to Fusion's fixed 6-segment COA, the de-duplication of multi-system vendors carrying different LIFNR numbers across companies, the translation of SAP profit-centre and cost-centre hierarchies into Fusion segment-value hierarchies, and the reshaping of effective-dated SAP master data (cost centre KS02 history, profit centre KE52 history) into Fusion's date-effective record model.

    Syntra ETL's SAP S/4HANA data mapping engine ships with these hard mappings pre-built. The account-assignment analyser reads 36+ months of ACDOCA postings, identifies which dimensions drive material variance, and proposes a Fusion 6-segment design that preserves the analytic intent. Vendor and customer de-duplication runs fuzzy-match logic across LFA1/KNA1 with configurable thresholds. Profit-centre and cost-centre hierarchies translate to Fusion segment-value hierarchies in a single pass.

    Every mapping is governed: source table, source field, target FBDI template, target field, transformation rule, business owner, sign-off date, version. The mapping repository is exportable as PDF and CSV, which is what internal audit, SOX control owners, and German HGB/AO regulators ask for during a migration-period review.

    The five hard mappings in SAP S/4HANA data conversion

    1
    Account assignment → 6-segment COA
    Eight SAP dimensions collapsed to six Fusion segments. Material dimensions become segments; non-material route to DFFs or PPM dimensions; usage-analyser drives the decision.
    2
    Vendor / customer de-duplication
    Multi-system LIFNR / KUNNR records consolidated via fuzzy-match on name + address + tax ID. Hierarchical parent-child relationships preserved into Fusion supplier/customer model.
    3
    Profit / cost centre hierarchy
    KE5Z profit-centre hierarchy and KS13 cost-centre hierarchy flattened to Fusion segment-value hierarchies. Multi-version SAP hierarchies handled with effective-date awareness.
    4
    Effective-dated master data
    SAP master-data change history (cost centre KS02, vendor LFA1 changes via CDPOS/CDHDR) reshaped into Fusion's date-effective record model with no history loss.

    Field-level SAP S/4HANA data mapping — six core object families

    Each object family ships with a documented mapping spec, FBDI/HDL template generation, and a sign-off pack for internal audit.

    📒

    GL Journals (BKPF/BSEG → ACDOCA → GL_INTERFACE)

    BSEG.HKONT → SEGMENT3 (Account), BSEG.KOSTL → SEGMENT2 (Cost Centre), BSEG.WRBTR → entered amount, BSEG.DMBTR → accounted amount, BSEG.SHKZG drives debit-vs-credit placement. ACDOCA targeted natively on S/4HANA.

    💸

    Suppliers (LFA1/LFB1/LFM1 → POZ_SUPPLIERS_INT)

    LFA1 → supplier header, LFB1 + LFM1 → supplier sites per BU, LFBK → bank accounts, LFA1.QSSKZ → withholding tax setup. Fuzzy-match dedup across LIFNR groupings consolidates multi-system vendors.

    📥

    Customers (KNA1/KNB1/KNVV → HZ_PARTIES + HZ_CUST_ACCOUNTS)

    KNA1 → party record, KNB1 → customer account per BU, KNVV → selling-BU + sales-channel attributes, KNB1.KKBER → credit-management profile. Open AR from BSID → RA_INTERFACE_LINES_ALL.

    📦

    Items (MARA/MARC/MBEW → EGP_SYSTEM_ITEMS_INTERFACE)

    MARA → item master, MARC plant-specific attributes → inventory-org-specific item, MBEW → cost profile per inventory org. Multi-plant items become one Fusion item with multiple org assignments.

    🛒

    Purchase Orders (EKKO/EKPO → PO_HEADERS_INTERFACE)

    EKKO → PO header, EKPO → PO lines, EKKN → account assignment per line, EKBE → goods receipt history (for open POs only). Open POs migrated with full approval-state context and remaining quantities.

    🏭

    Sales Orders (VBAK/VBAP → DOO_ORDER_HEADERS_INT)

    VBAK → order header, VBAP → order lines, KONV → conditions/pricing, LIKP/LIPS → delivery state (for open orders only). Customer-product cross-references preserved into Fusion Order Management.

    SAP S/4HANA CDS view extraction — the cloud-friendly mapping layer

    When direct HANA SQL is restricted (RISE Cloud Private Edition, S/4HANA Cloud Public Edition), CDS views become the strategic extraction layer. Syntra ETL maps every key business object through its delivered CDS view.

    📊

    I_JournalEntryItem

    Strategic CDS view replacing ACDOCA direct read. Surfaces universal-journal items with all account-assignment dimensions joined. Application-layer authorisation enforced — works on RISE-locked instances.

    👥

    I_Supplier + I_SupplierCompany

    Vendor master and company-code-specific vendor data joined. Authorisation enforced via S_BUKRS check. Throughput is 70–80% of direct LFA1/LFB1 read but cloud-friendly.

    🤝

    I_Customer + I_CustomerCompany

    Customer master and company-code-specific customer data. Includes payment terms, credit limits, dunning configuration — replaces direct KNA1/KNB1 read on RISE.

    📦

    I_Product + I_ProductPlantSupplyPlanning

    Material master and plant-specific MRP/supply data. Includes MARA cross-client attributes joined with MARC plant-specific. Cloud-friendly equivalent of direct MARA/MARC read.

    🛒

    I_PurchaseOrderItem

    PO line items with header context joined. Includes EKKO + EKPO + EKKN account assignment in a single view. Throughput-optimised for high-volume PO extraction on RISE.

    📦

    I_BillingDocumentItem

    Billing document line items (VBRK + VBRP joined) with AR aging context. Used for open AR extraction on cloud-restricted instances.

    SAP S/4HANA data mapping — the design-to-load workflow

    A repeatable workflow that produces governed, audit-ready mapping artifacts. The mapping engine pays back its design time during validation and cutover.

    1

    Source profiling — Week 1

    Discovery runs across in-scope S/4HANA tables, profiles cardinality, null rates, value distributions, account-assignment usage. Output: data-quality scorecard and assignment-collapse recommendation.

    2

    Crosswalk drafting — Weeks 2–3

    Field-level mapping rules drafted per object, account-assignment-to-segment proposal generated, vendor/customer dedup rules drafted. Reviewed with functional leads in workshops.

    3

    Sign-off — Week 4

    CFO/Controller sign mapping for GL Journals, AP Lead signs Suppliers + Open AP, AR Lead signs Customers + Open AR, Materials Manager signs Items, Procurement Lead signs Open POs. Signatures captured in PDF mapping pack.

    4

    Build & unit-test — Weeks 5–8

    FBDI/HDL/REST templates generated per signed-off mapping, unit-tested against synthetic and sample-real data, edge cases identified and resolved (null handling, unmapped lookup values, currency mismatch).

    5

    Dry-run reconciliation — Week 9

    Full S/4HANA dataset extracted, transformed using crosswalks, loaded to Fusion non-prod. Reconciliation pack generated: counts, sums, hash signatures, error reports. Mapping refinements logged.

    6

    Production load — Cutover weekend

    Final mapping versions applied, production data extracted, loaded to Fusion production, reconciled to the cent, sign-off pack issued to internal audit. Mapping repository archived with the migration cutover bundle.

    Frequently asked questions

    What does SAP S/4HANA data mapping to Oracle Fusion involve?+

    SAP S/4HANA data mapping is the field-by-field, table-by-table specification of how source S/4HANA data structures get reshaped into Oracle Fusion target structures. For Finance it covers BKPF/BSEG (or the modern ACDOCA universal journal) → Fusion GL_INTERFACE journal lines; for AP, LFA1/LFB1 → Fusion POZ_SUPPLIERS_INT + POZ_SUPPLIER_SITES_INT and BSIK open items → AP_INVOICES_INTERFACE; for AR, KNA1/KNB1 → HZ_PARTIES + HZ_CUST_ACCOUNTS and BSID open items → RA_INTERFACE_LINES_ALL; for inventory, MARA/MARC → EGP_SYSTEM_ITEMS_INTERFACE and MBEW → CST_ITEM_COST_PROFILES_INT; for procurement, EKKO/EKPO → PO_HEADERS_INTERFACE + PO_LINES_INTERFACE. The hard part isn't the obvious one-to-one fields — it's account-assignment collapse, cost-centre-to-segment mapping, and effective-dated history reshaping.

    How does the SAP S/4HANA data mapping handle the account-assignment collapse?+

    S/4HANA's account-assignment model is rich and flexible: every BSEG/ACDOCA line carries up to eight independent dimensions (GL account HKONT, cost centre KOSTL, profit centre PRCTR, WBS element PS_PSP_PNR, internal order AUFNR, functional area FKBER, segment SEGMENT, business area GSBER). Oracle Fusion has a fixed 6-segment COA — typically Company, Cost Centre, Account, Product, Intercompany, Future. The mapping engine analyses 36+ months of ACDOCA postings to identify which SAP dimensions actually drive material variance — typically only three or four do. Those become Fusion segments. Profit-centre hierarchies become segment-value hierarchies. WBS, internal order, and functional area get routed to Fusion DFFs (descriptive flexfields) or PPM analytical attributes if they're material for project accounting. Non-material dimensions are dropped with full audit traceability.

    What does the BKPF/BSEG → Fusion GL Journals mapping actually look like?+

    BKPF (header) and BSEG (line item) are the classic ECC journal-entry tables, still readable on S/4HANA for migrations spanning the ECC-to-S/4HANA upgrade history. The mapping: BKPF.BELNR + GJAHR → GL_INTERFACE.REFERENCE3 (preserves traceability); BSEG.HKONT → GL_INTERFACE.SEGMENT3 (Account segment, after value-set translation); BSEG.KOSTL → GL_INTERFACE.SEGMENT2 (Cost Centre segment); BSEG.WRBTR (transaction currency amount) → entered debit/credit; BSEG.DMBTR (local currency amount) → accounted debit/credit; BSEG.SHKZG ('S' or 'H') drives debit-vs-credit column placement; BSEG.WAERS → GL_INTERFACE.CURRENCY_CODE; BSEG.BUDAT → GL_INTERFACE.ACCOUNTING_DATE. The modern equivalent uses ACDOCA which combines BKPF+BSEG+COEP+FAGLFLEXA — the mapping uses the same target fields with different source columns.

    How does the SAP S/4HANA data mapping handle vendors (LFA1/LFB1) to Oracle Fusion suppliers?+

    LFA1 is the cross-client vendor master with cross-company-code attributes (name, address, country, search terms, withholding tax country). LFB1 is the company-code-specific vendor data (recon account, payment terms, dunning area, accounting clerk). LFM1 holds the purchasing-org-specific data, LFBK the bank accounts. The Fusion target: POZ_SUPPLIERS_INT for the supplier header, POZ_SUPPLIER_SITES_INT for the BU-specific sites (one Fusion site per LFB1 + LFM1 combination), POZ_SUPPLIER_CONTACTS_INT for contacts, and AP_SUPPLIER_BANK_ACCT_INT for bank accounts. Fuzzy-match de-duplication runs across LIFNR groupings to consolidate multi-system vendors. Withholding tax codes from LFA1.QSSKZ map to Fusion's withholding-tax configuration. Payment terms (LFB1.ZTERM) map via a crosswalk to Fusion payment terms reference data.

    How does the SAP S/4HANA data mapping handle customers (KNA1/KNB1) to Oracle Fusion?+

    KNA1 is the cross-client customer master (name, address, country, industry code WKW1/WKW2). KNB1 is the company-code-specific data (recon account, dunning area, payment terms, credit-control area). KNVV holds the sales-area data (sales org + distribution channel + division). The Fusion target uses TCA (Trading Community Architecture): HZ_PARTIES for the party record, HZ_CUST_ACCOUNTS for the customer account per BU, HZ_CUST_SITE_USES_ALL for the BILL_TO/SHIP_TO uses, HZ_LOCATIONS + HZ_PARTY_SITES for addresses. KNVV sales-area data maps to Fusion selling-BU + sales-channel attributes. Credit-control area (KNB1.KKBER) maps to Fusion credit-management profile. Open AR from BSID maps to RA_INTERFACE_LINES_ALL with aging buckets preserved.

    What about the MARA/MARC → Fusion Items mapping?+

    MARA is the client-level material master (material number MATNR, material type MTART, base unit of measure MEINS, gross weight, dimensions, material group MATKL). MARC adds plant-specific attributes (MRP type, lot size, procurement type, profit centre per plant). MBEW carries valuation data per plant + valuation type (price control V/S, standard price, moving average). The Fusion target: EGP_SYSTEM_ITEMS_INTERFACE for the item master (one row per MARA), EGP_ITEM_REVISIONS_INT for revision history, CST_ITEM_COST_PROFILES_INT for valuation methods, and INV_TXN_INTERFACE for the opening balance. MARA.MTART (material type) maps to Fusion item-class assignment; MARC plant-specific attributes map to inventory-org-specific item attributes. Items in multiple SAP plants result in one Fusion item with multiple inventory-org assignments — not duplicate items.

    How does the S/4HANA data mapping use CDS views for extraction?+

    Direct table reads are fastest for on-premise S/4HANA, but CDS views are the strategic SAP-blessed access layer and are mandatory for RISE Cloud Private Edition extraction. For Finance, the I_JournalEntryItem CDS view replaces ACDOCA, surfacing the universal-journal items with all account-assignment dimensions joined. For vendor master, I_Supplier and I_SupplierCompany. For customer master, I_Customer and I_CustomerCompany. For material master, I_Product and I_ProductPlantSupplyPlanning. For purchase orders, I_PurchaseOrderItem. CDS views deliver application-layer authorisation enforcement, which is important for RISE-managed environments. Throughput is 60–80% of direct HANA SQL, which is still production-viable for billion-row extracts running over a controlled extraction window.

    Where is the SAP S/4HANA data mapping documented for audit purposes?+

    Every mapping rule lives in the Syntra ETL crosswalk repository: source table, source field, source data type, target Fusion FBDI/HDL/REST template, target field, target data type, transformation rule (direct copy, lookup, calculated, conditional), reference data dependencies (value sets, crosswalk tables), business sign-off (who signed, when, what version), and example values (one valid, one edge case, one error case). Output is exported as PDF and CSV per object — Suppliers data mapping document, Customers data mapping document, Items data mapping document, GL Journals data mapping document, Open AP data mapping document, Open AR data mapping document. Internal audit and SOX-control owners get the full pack. This is the artifact German HGB/AO regulators expect to see during a migration-period audit.

    Want to see the full SAP S/4HANA data mapping pack?

    Book a 30-minute call. We'll walk through the field-level data mapping for the modules in your scope, show example crosswalk specs from real S/4HANA-to-Fusion conversions, and give you a concrete timeline for your project.