Data Mapping Between ERP and Store: Field Assignment Done Right

Data mapping describes the process of assigning fields from a source system to fields of a target system. In ERP-store integration, this means concretely: which SAP field is written to which Shopware field? How is a SAP data type converted to the Shopware data type? What business logic is applied during transformation?

The criticality of mapping is often underestimated. A faulty mapping does not immediately produce a visible error -- data flows, but it is wrong. Prices are displayed in the store without VAT, inventory levels are interpreted as pieces instead of cartons, or customer data is assigned to the wrong account. Such errors only surface when a customer receives an incorrect invoice or an item is shown as available that has long been sold out.

According to a Gartner study, successful integration projects invest 25 to 30 percent of project time in the mapping phase (Gartner, 2025). This investment pays off: clean mapping reduces the error rate in the production phase by a factor of four and significantly lowers rework costs. For API development, the mapping document is the central specification.

Not every field mapping is equally complex. In practice, we distinguish five mapping types that differ in their transformation effort and are each implemented differently in the middleware.

Item master data is the most extensive mapping area. A typical ERP item record encompasses 80 to 150 fields (project experience), of which 30 to 60 are needed in the store depending on requirements. The challenge lies not only in the number of fields but in structural differences: SAP works with a flat item model and separate variant tables, while Shopware maps products with configurable property groups and variants as separate entities.

Variant mapping is particularly complex. In SAP, variants are frequently managed as separate items with a parent bill of materials or matrix. In Shopware, variants are child elements of a parent product configured via property groups (size, color, material). The middleware must analyze the SAP variant structure, derive property groups and establish the assignment between SAP variant codes and Shopware property values.

Price mapping is among the most error-prone areas of ERP-store integration. The main reason: ERP systems typically work with net prices, while store systems display gross or net prices depending on B2B/B2C configuration. The middleware must determine the correct tax rate and calculate the gross price -- where the tax rate can vary by product category, customer location and delivery country.

With customer-specific pricing, complexity multiplies. SAP Business One supports up to ten price lists per item. Each price list can contain tiered prices (quantity-dependent) and time periods (valid from/to). In Shopware, these structures are mapped via price rules and customer groups. The mapping must define: which SAP price list corresponds to which Shopware customer group? How are tiered prices converted to Shopware price tiers? How are time-limited special prices handled?

According to an EHI Retail Institute survey, 68 percent of B2B merchants use customer-specific pricing models (EHI Retail Institute, 2025). Correct price mapping is therefore business-critical for the majority of B2B integration projects. An error in price mapping -- such as a missing VAT calculation or incorrectly assigned tiered price -- can have significant financial impact.

Validation is the protective layer between transformation and transfer. Before a mapped record is sent to the target system, the middleware checks the data for completeness, consistency and validity. Faulty records are not transferred but collected in an error list and reported to the administrator.

Important validation rules include required field checks (item number, price, unit of measure must be present), value range checks (prices must not be negative, inventory not less than zero), reference checks (the referenced customer group must exist in the store), format checks (item numbers must conform to the defined format) and plausibility checks (gross price must be greater than net price). According to an IBM study, systematic validation rules reduce error rates in data migrations by 75 to 85 percent (IBM Data Quality Study, 2024).

A mapping document is the central specification of an ERP-store integration. It defines every field assignment, transformation logic, validation rules and data authority (which system leads which field). This document is created before implementation and approved by both departments -- IT and business.

A tabular structure with the following columns has proven effective: source system, source field, source data type, target system, target field, target data type, mapping type, transformation rule, validation rule and data authority. For a typical SAP-Shopware integration, the mapping document encompasses 150 to 300 rows (project experience) -- an investment that pays for itself many times over through reduced implementation errors and easier maintenance.

The mapping document should be versioned and maintained in a format accessible to all stakeholders. Changes to mapping -- such as new ERP fields or changed store requirements -- are documented and go through an approval process. This approach ensures that the middleware configuration always corresponds to the current state of the mapping document.

For international B2B stores, an additional mapping dimension comes into play: language assignment. Item descriptions, product texts and units of measure can be maintained in multiple languages in SAP. The middleware must map language codes between systems (SAP uses ISO codes like 'DE', 'EN'; Shopware uses locale codes like 'de-DE', 'en-GB') and assign translated fields to the correct language versions in the store.

A particular challenge is handling missing translations. When an item in SAP is only maintained in German but the store also requires an English version, the middleware must decide: is the German text used as fallback, a placeholder inserted, or the item hidden on the English page? This fallback logic must be configured in the mapping and coordinated with the business department.

Most ERP-store integrations are bidirectional: master data flows from ERP to store, orders and customer data flow from store back to ERP. A separate mapping is needed for each data flow -- and the mapping direction significantly influences transformation logic.

In order mapping (store to ERP), Shopware structures must be converted to SAP orders. Shopware line items become SAP order positions, Shopware payment methods become SAP payment terms, Shopware shipping methods become SAP shipping types. This reverse mapping requires its own lookup tables and validation rules. Error handling is particularly critical here: a non-assignable order value must not lead to data loss but must create a clarification case in the middleware.

Systematic mapping requires systematic testing. For each mapping rule, at least one test case should exist that verifies correct transformation. In practice, a three-level testing approach has proven effective: unit tests for individual mapping rules (is the net price correctly converted to gross?), integration tests with real data records (is a complete SAP item correctly created as a Shopware product?) and end-to-end tests for the complete data flow (is a store order correctly created as a SAP sales order?).

Automated mapping tests can be integrated into the CI/CD pipeline: with every change to mapping code, all tests are executed and regressions immediately detected. This approach is particularly valuable for long-lived integration projects where new fields are added and existing mappings adjusted over months or years.

Experience from numerous integration projects reveals recurring mapping errors that can be avoided with the right approach.

A data mapping is not a static document. Over the course of an integration, fields are added, transformation rules adjusted and validations tightened. Without clean versioning, overview is quickly lost: which version of the mapping is currently running in production? Which change caused the error? Can the last change be reverted?

The middleware stores mapping configurations versioned -- similar to source code in a version control system. Each change receives a timestamp, the editor's name and a description of the change. In case of problems, the middleware can be rolled back to a previous mapping version without reimplementing the integration. According to a Gartner study, versioning mapping configurations reduces error analysis time for integration problems by 50 percent (Gartner, 2025).

Mapping inventory data requires particular attention since multiple ERP values must be aggregated into a single store value. Physical warehouse stock in SAP consists of total stock minus reserved quantities, committed quantities (for open orders) and safety stock. Only the resulting available stock is transferred to the store.

In multi-warehouse scenarios, complexity multiplies: inventory from multiple warehouses must be summed, maximized or displayed location-specifically depending on business logic. The middleware implements aggregation logic as a configurable rule that can differ per item category or customer group. Additionally, minimum order quantities and packaging units must be considered -- an item sold only in cartons of 10 displays stock not in individual pieces but in available cartons.

Customer master data mapping is particularly complex in the B2B context because B2B customers frequently have hierarchical structures: a corporation has multiple subsidiaries, each subsidiary has multiple locations, and each location may have its own delivery addresses and contacts. In SAP Business One, these structures are mapped via business partner hierarchies and contact persons.

The middleware must transfer these hierarchies into the store's customer model. In Shopware, customer accounts can be created with multiple addresses and contacts, but the hierarchical assignment (which subsidiary belongs to which corporation) requires custom fields or special B2B extensions. The mapping must define at which hierarchy level pricing conditions apply (corporation price or location price) and what permissions each user has within the hierarchy. According to an EHI Retail Institute analysis, 45 percent of B2B customers have more than five different delivery addresses (EHI Retail Institute, 2025), underscoring the relevance of well-thought-out address mapping.