Customer-Specific Prices from ERP: Synchronization and Caching

ERP systems like SAP Business One and Microsoft Dynamics offer comprehensive pricing logic. SAP Business One supports up to ten price lists per item, each containing tiered prices (quantity-dependent), validity periods and currencies. Dynamics 365 works with trade agreements that are even more flexible, additionally incorporating delivery terms and payment conditions into pricing.

The typical B2B price structure encompasses multiple levels: List price applies as the standard price for all customers without special agreements. Group prices apply to defined customer groups (dealers, major accounts, partner companies). Tiered prices vary by order quantity (from 10 pieces, from 100 pieces, from 1,000 pieces). Individual prices are conditions tailored to single customers, often agreed within a framework contract. And special prices are time-limited promotional or project prices.

The middleware must transfer this complex price hierarchy into the store system's pricing model. In Shopware, prices are mapped via customer groups, price rules and price tiers. The mapping between ERP price lists and Shopware price rules is the central configuration step of price synchronization.

Three fundamental strategies are available for price synchronization, which can be combined depending on data volume and timeliness requirements.

In practice, the hybrid strategy has proven optimal: standard and group prices are updated periodically via delta sync (every 15 minutes). Customer-specific prices and special conditions are queried from the ERP on demand and cached. This combination offers the best balance between performance, timeliness and ERP load.

A B2B catalog with 10,000 items and 50 customer groups generates 500,000 price records -- without tiered pricing. With tiered prices, the number can quickly reach millions. Directly querying every price from the ERP on each page load would be an unbearable load. An intelligent caching layer in the middleware is therefore indispensable.

The most proven solution is a Redis-based cache with differentiated TTL values (time-to-live) per price type: list prices with a TTL of 24 hours (change rarely), group prices with a TTL of one hour (change occasionally), individual prices with a TTL of 15 minutes (can change more frequently) and promotional prices with a short TTL of five minutes (time-critical). On a cache miss -- when the requested price is not in the cache -- it is queried from the ERP and cached for future requests.

In production, this approach achieves a cache hit rate of 95 percent (project experience), meaning only five percent of price queries actually hit the ERP. Average response time drops from 200 to 500 milliseconds (ERP query) to under 50 milliseconds (cache retrieval). For the store user, price display is thus virtually instantaneous.

The most critical aspect of any caching strategy is invalidation: when a price changes in the ERP, the cache must be updated immediately so that no outdated prices are displayed in the store. The middleware implements two mechanisms: event-based invalidation (ERP actively reports price changes) and periodic validation (cache is regularly checked against ERP data).

With event-based invalidation, SAP sends a webhook to the middleware on every price change, which immediately invalidates the affected cache entry. On the next access, the current price is queried from the ERP and the cache is updated. Periodic validation serves as a safety net: every 15 minutes, cached prices are spot-checked against ERP data to detect gradual deviations.

Tiered pricing is a central element of B2B pricing. A typical example: Item X costs 10 euros per piece from 1 piece, 8.50 euros from 50 pieces and 7 euros from 100 pieces. In the ERP, these tiers are stored as separate price entries per quantity range. In Shopware, tiered prices are mapped as price tiers within a price rule.

The mapping must ensure that quantity thresholds are correctly transferred, prices are assigned to the right price type (net in ERP, gross or net in store) and tier logic is consistent (no gaps or overlaps in quantity ranges). According to a Forrester analysis, B2B stores with correctly displayed tiered pricing see 23 percent (project experience) higher average order values compared to stores without tier display (Forrester, 2025), as customers deliberately order larger quantities to reach the next price level.

Framework agreements define individual prices for a specific customer over a set period. In the ERP, these are stored as special prices or trade agreements, often with quantity commitments and validity periods. The middleware must transfer these conditions to the store and ensure that the customer sees their individual contract prices after login.

Technical implementation requires an assignment between ERP customer number and store customer group or individual pricing model. In Shopware, individual prices can be mapped via price rules based on the customer account. The middleware synchronizes framework agreement prices either in advance to the store (pre-loading on customer login) or delivers them on demand via an API when the customer views a product.

International B2B stores serve customers in various currencies. The middleware must assign ERP price lists in EUR, CHF, USD and other currencies to the corresponding store currencies. Two strategies have proven effective: static exchange rates from the ERP (prices are centrally maintained per currency in the ERP and transferred unchanged) and dynamic exchange rates (a EUR price is converted to the target currency at the current exchange rate during synchronization).

In practice, most B2B companies use static exchange rates, as they retain full control over pricing per market. Dynamic exchange rates are suited for companies with many target markets and little need for country-specific pricing. The middleware updates exchange rates at configurable intervals and logs every rate change for traceability.

ERP systems typically work with net prices. B2B stores display either net prices (for business customers) or gross prices (in mixed B2B/B2C stores) depending on configuration. The middleware must perform the conversion correctly and apply the appropriate tax rate.

Tax rate determination depends on several factors: product category (standard rate 19 percent or reduced rate 7 percent), customer location (domestic, EU with VAT ID, EU without VAT ID, third country) and delivery country. For EU deliveries to business customers with valid VAT ID, tax is waived (reverse charge). For OSS-liable deliveries to private customers, the destination country's tax rate applies. The middleware must consider all these rules in price calculation.

In B2B commerce, price changes are business-critical operations that must be documented traceably. The middleware logs every price change with timestamp, old and new value, affected price list and change source (ERP sync, manual correction, time-triggered special price). This audit trail enables seamless traceability of all price movements -- indispensable for resolving customer complaints and complying with GoBD requirements.

Beyond that, price histories can be used for business analysis: which customer groups have experienced the largest price adjustments? How do margins develop after synchronization? Which items have the most frequent price changes? This data provides valuable insights for sales management and pricing policy optimization.

With large price datasets, synchronization performance becomes the critical factor. A full import of 500,000 price records via the Shopware API can take several hours. The middleware therefore uses multiple optimization strategies: batch operations (multiple prices in one API call), parallel processing (independent price lists synchronized simultaneously), selective synchronization (only changed prices transferred) and temporary indexing pauses (Shopware search index deactivated during import).

In practice, optimized price synchronizations achieve a processing rate of 300 to 800 price records per second (project experience). A delta sync with typically 1,000 to 5,000 changed prices is completed within seconds. The nightly full reconciliation as safety net takes under 30 minutes for 500,000 records.

Comprehensive monitoring of price synchronization is indispensable for detecting price deviations between ERP and store. The middleware continuously monitors cache hit rate (below 90 percent indicates configuration issues), sync error rate (failed price imports), ERP response time (increasing latency may indicate ERP performance problems) and price deviation (spot-check comparisons between ERP and store prices).

Automatic alerts are triggered when significant price deviations are detected: for example when a store price deviates more than two percent from the ERP price or when a price import has more than three consecutive errors. With a central log/monitoring system for price synchronization, our experience shows that 73 percent (project experience) of all price-related customer complaints can be avoided (project experience).

For internationally operating B2B companies, an additional layer of complexity arises: price management in multiple currencies. SAP Business One supports price lists in different currencies, and the store must display prices to the customer in their home currency. The middleware synchronizes currency-specific price lists separately and assigns them to the corresponding store currencies.

The challenge lies in exchange rate handling: are prices maintained fixed in the ERP (then the rate reflects the time of the last calculation), or should they be dynamically converted based on current exchange rates? Both approaches have advantages and disadvantages. Fixed maintenance offers price stability and planning certainty, while dynamic conversion reflects current market conditions. According to a Statista survey, 43 percent (project experience) of B2B merchants in the DACH region process transactions in more than one currency (Statista, 2025). Correct multi-currency synchronization is thus relevant for a significant portion of B2B integrations.

Erroneous prices in the store can have significant financial and legal consequences. An item accidentally set to zero euros, a faulty tiered price showing the wrong quantity level, or a special price below the purchase price -- all must be detected before publication in the store. The middleware implements multi-level validation rules for this purpose.

The most important plausibility checks include: prices must not be zero or negative, gross prices must be greater than net prices, tiered prices must decrease with increasing quantity (not increase), the price difference from the previous sync must not exceed a configurable threshold (for example maximum 20 percent change) and the price must be above a defined lower limit. These validations prevent faulty ERP data from reaching the store unchecked. Records that fail validation are secured in the dead letter queue and reported to the administrator for review.

For GoBD compliance and internal audit security, a seamless price history is indispensable. The middleware logs every price change with timestamp, old value, new value and source of the change. This price history enables tracking when which price was active for which customer -- information that is indispensable for complaints, invoice audits or pricing disputes.

Price history is stored in the middleware database with a configurable retention period (typically 24 months for operational purposes, ten years for accounting-relevant price information). For analyzing price trends and optimizing pricing strategy, the price history can be exported to business intelligence systems. A professional price integration includes this audit functionality as an integral component.