Data mapping is the structured documentation of the relationship between each data element in a source system and its corresponding element in a target system — specifying how source field values are translated, transformed, or enriched to produce valid target field values. In ERP and EPM implementations, data mapping is the foundational artefact for ETL design, data migration, and interface specification: it defines the logic that every data movement process will execute, at the field level, for every data domain in scope. Without accurate, complete data mapping, every downstream technical artefact — the ETL design, the migration scripts, the interface specifications — is built on assumptions that will be discovered to be incorrect in testing.
Data Mapping Structure
A data mapping document is structured at three levels:
- Entity-level mapping: For each source data entity (a GL account, a cost centre, an asset) — what is the corresponding target entity type, and what is the relationship (one-to-one, one-to-many, many-to-one)?
- Field-level mapping: For each source field — what is the corresponding target field, the data type transformation required (string to numeric, date format change), any default value when the source is null, and any conditional logic (if source value = X, target value = Y; otherwise target value = Z)?
- Value-level mapping: For enumerated source values — what is the corresponding target value? This is the dimension value mapping: GL account 4100 in the ERP maps to Revenue — Product Sales in the EPM account dimension. This level of the mapping is the most labour-intensive to produce and the most frequently incomplete.
For Oracle EPM implementations using FDMEE or Data Management, the value-level mapping is configured directly in the mapping rules within the tool — making the data mapping document both a design artefact and, effectively, the configuration specification.
Common Gaps and Failure Modes
The specific failure that extends EPM implementation testing cycles is a value-level mapping produced by IT based on system knowledge, without validation by the finance team. The IT team maps GL accounts to EPM account dimension members based on account codes and descriptions. The finance team, reviewing the first trial data load output, finds that several accounts have been mapped to incorrect EPM categories — revenue accounts mapped to gross profit lines, intercompany accounts mapped to external revenue — because the IT team applied a naming-convention assumption that the finance team’s actual account structure does not follow. Value-level mapping must be reviewed and signed off by the finance team before it is configured in the ETL tool, not after the first data load reveals the errors.
How Loop Wise Solutions Produces This
Loop Wise Solutions produces data mapping in structured collaboration sessions with the client’s finance and IT teams — the finance team provides the business intent (what should map to what and why), the IT team provides the technical source structure (what the source system actually contains). The mapping is documented in a standardised template and reviewed in two passes: a completeness review (are all source values covered?) and an accuracy review (does the target assignment reflect the correct business classification?). The signed-off mapping document is the authoritative input to ETL design, migration scripting, and interface specification — and any subsequent change to the mapping is subject to a formal change control process.
Answers before you ask.
The correspondence between data elements in a source system and their equivalents in a target system — including field-level transformations, lookup tables, and conditional logic. It records exactly how each source field becomes a target field, with any conversion applied. It is the foundational artefact for ETL design, data migration, and interface specification.
Because ETL processes and migrations are built from the mapping — it tells the build how to transform each field, apply lookups, and handle conditional cases. Without an accurate mapping, the pipeline moves data incorrectly. Getting the mapping right is therefore the prerequisite for correct ETL, migration, and interfaces; errors here propagate into every process built on it.
The specific conversion applied to each field as it moves from source to target — format changes, unit or currency conversion, code translation via lookup tables, and conditional logic where the transformation depends on other values. Documenting these precisely is what lets the source structure be reconciled to the target correctly. Vague mapping leaves transformation to be guessed during build.
Data mapping documents the field-level correspondence and transformation between systems; the interface specification uses that mapping and adds the operational elements — trigger, frequency, error handling, acceptance criteria. Mapping is the transformation detail; the interface spec is the complete build reference around it. Mapping also feeds migration and ETL, not only interfaces.