Field Mapping
Field mapping is the unambiguous assignment of data fields in a source system to the matching fields in a target system – such as "Customer no." to "Debtor number". It defines which field belongs where and how values are recoded or reformatted along the way.
Field mapping is the unambiguous, documented assignment of data fields in a source system to the matching fields in a target system. It answers the question of which field in one system corresponds to which field in the other – for example the legacy field "Customer no." to the ERP field "Debtor number", or a free-text country to the standardized ISO country code. The mapping defines not only the field-to-field relationship but often also how values have to be transformed along the way: recoded, reformatted, merged or split.
Field mapping is needed wherever data flows between differently structured systems: during a one-time data migration into a new ERP, during recurring data imports (such as a price list via CSV) and during permanent integration via APIs, for example between the ERP and an online shop. Because barely any two systems use the same field names, data types and value lists, the mapping is the translation rule without which data cannot be meaningfully transferred. A carefully aligned field mapping is therefore the heart of every data takeover – a wrong or incomplete mapping reliably leads to swapped, truncated or factually incorrect records.
At a glance
- Assignment of data fields from source system → target system (field-to-field relationship)
- Also governs recoding, formatting, merging and splitting of values
- Foundation of every migration, every import and every interface/integration
- The challenge is usually semantics, not technology: field names are deceptive
- Must be documented and functionally agreed so that runs remain reproducible
How field mapping works
A field mapping is usually created as a table or set of rules that pairs each source field with a target field. In the simplest case this is a 1:1 assignment of identical fields – "email" to "email". In practice, however, cases predominate where a transformation is additionally required because the target system expects different data types, number ranges, mandatory fields or value lists. The mapping then defines the rule by which the source value is converted into a valid target value.
Technically, the mapping is implemented differently depending on the context: in a migration tool or ETL tool, in the ERP import wizard, in a middleware or directly in the code of an API interface. Regardless of the tool, one thing applies: the mapping should be versioned and documented in a traceable way so that test runs remain repeatable and decisions can be justified later.
Types of assignment: 1:1, recode, split, merge
The simplest form is the direct 1:1 assignment. With recoding (value mapping), a source value is mapped to a different target value via a translation table – such as the country "Germany" to the ISO code "DE", or an old product group number to a new one. When splitting, one field is divided into several, classically a free-text address field into street, house number, postal code and city. Conversely, merging combines several source fields into one target field. Often there are additional target fields that are calculated or filled with fixed default values and for which there is no equivalent at all in the source system.
Semantics beat the field name
The biggest source of error is not the technology but the meaning of a field. Two identically named fields can mean different things – a "price" may be gross or net, with or without discount, in a different currency. A purely technically correct mapping then still produces wrong results. That is why the mapping must be aligned on the business side: those who know the processes clarify what a field really means before it is assigned.
Why field mapping determines data quality
The field mapping is the point at which it is decided whether correct or corrupted data arrives in the target system. An error in the mapping does not affect a single record but all of them: if the wrong field is assigned or a recoding is defined incorrectly, the entire data set is systematically flawed. Unlike isolated typos, such mapping errors are often hard to notice because the data looks formally valid and only surfaces in day-to-day operation.
That is why every mapping requires validation: checksums, record counts and spot checks show whether values were transferred correctly and completely. Typical checkpoints are the truncation of overly long values by shorter target fields, misinterpreted date formats (for example day/month swapped), lost leading zeros in numbers, or recodings that map a source value to no valid target category. A good mapping deliberately defines a behavior for such edge cases instead of letting them pass silently.
Field mapping in the ERP system
In the ERP context, field mapping appears in two roles. First, during implementation: the takeover of master data such as products, customers and suppliers from the legacy system stands or falls with a clean mapping onto the field structure of the new ERP. Second, in ongoing operation: every interface between the ERP and connected systems – shop, marketplace, shipping service provider, accounting – relies on a mapping that maps the fields of both sides onto each other. Because many ERP systems impose fixed mandatory fields and defined number ranges, the mapping here is often more demanding than a simple CSV import.
The scope and target field structure should be clarified early and ideally recorded in the requirements specification. Standard ERP usually comes with predefined import templates for common objects that simplify the mapping; deviating or custom fields, on the other hand, require a manual, documented mapping. In DACH practice there are additional specific requirements – such as the correct assignment of VAT ID, IBAN, general ledger accounts or DATEV-relevant fields – whose formats and validation rules have to be taken into account in the mapping.
Distinction: field mapping vs. data migration vs. interface
Field mapping is not a standalone process but a building block. Data migration is the overarching, one-time process of data takeover, in which the mapping provides the translation step. An interface or API describes the permanent technical connection of two systems – it too contains a mapping as the substantive translation rule. In short: migration and interface are the "how and when" of the transfer, the field mapping is the "what belongs where".
Common pitfalls and how to avoid them
The most frequent errors are mappings that were only agreed technically but not functionally, unnoticed format differences (date, decimal separator, character set) and missing rules for values that have no equivalent in the target system. Relying on identical field names is also risky, because equal names do not guarantee equal meaning. Another problem is target fields that are too short and truncate values unnoticed.
This becomes manageable through a methodical approach: a fully documented mapping document that records every assignment together with its transformation rule and exception handling; the involvement of the business department to clarify field semantics; several test runs with real data; and clear acceptance criteria with checksums and spot checks. This keeps the mapping reproducible and finds errors in testing rather than in production.
Example
Example: shop connection at a mid-sized company
A retailer connects its online shop to a new ERP. In the shop the customer field is called "billing_country" and contains the spelled-out country name ("Germany", "Austria"), whereas the ERP expects the two-letter ISO code ("DE", "AT") in the field "Country". The mapping assigns the two fields to each other and stores a recoding table for the values. In addition, the shop's single-line address field is split into the four ERP fields street, house number, postal code and city during import.
In the first test run it turns out that orders with the country "Switzerland" slip through without a valid ISO code, because that value was missing in the recoding table – the affected records ended up in the ERP without a country. The team adds the rule, defines an error message instead of an empty value for unknown countries and repeats the run. Only after an error-free spot check does the interface go live. The effort thus lay not in the technical connection but in the clean functional mapping of the fields and values.
Frequently asked questions
Related services
Sources
Questions about Field Mapping in your ERP project?
We advise vendor-neutrally – and implement it ourselves on request.