When pricing logic lives in the ERP and the storefront only knows what it was told last, the gap between them reveals exactly where you cannot afford it. In a B2B environment, that gap is neither minor nor cosmetic. It is structural, and it hits distributors, procurement managers, and long-term customers at the moment they commit to a purchase.
A Distributor's Price Feels Right Until Checkout
Picture a procurement manager at a regional distributor signing into a B2B commerce portal connected to Dynamics 365 Business Central. Their account is tiered, contractually defined, and layered with margin and rebate structures negotiated over three years. The distributor relies on predictable pricing: if a customer places a job-critical order for components, both sides expect the total to be the same whether the order is placed in the morning or just before the line closes.
The procurement manager navigates to a product page. The price looks consistent with recent quotes. The quantity discounts align with the last agreement. The order value feels familiar. They add materials to the cart. A promotional banner still appears at the top of the screen, tied to a volume-based campaign that the sales team had communicated to key accounts. The promotion looks active. The manager proceeds to checkout. The total changes. The promotion has been removed. The line-item price no longer matches what the ERP is enforcing under the current window, contract status, and tier. The order completes, but the buyer is left questioning whether the rules changed mid-transaction.
This is not one problem. It is two. But they share a single root cause. That is why the storefront and ERP disagree on price, and why most integrations that appear to be working quietly hollow out trust and margin.
What the Product Page Cannot Refresh
In Dynamics 365 environments, pricing is rarely a static value. It is a live calculation, evaluated at the moment an order qualifies. The ERP consults the customer's group, the quantity being ordered, the active price windows, and the status of any contracts. It does not store a single price per SKU. It derives one, every time an order or quote is processed.
The commerce layer approaches this differently. It displays a value that was calculated elsewhere, at another moment, and passed downstream through a sync process. That value is then retained until the next sync cycle overwrites it. The buyer sees a snapshot of the price the ERP produced the last time the two systems exchanged data, not a live reflection of the current logic.
Under stable conditions, this gap can remain invisible. A standard product with a flat list price for a broad customer group will rarely expose the lag. The gap becomes dangerous when any underlying variable shifts. A distributor may move to a higher margin tier. An order crosses a volume threshold that unlocks a new discount. A contract window closes, and the account reverts to a baseline rate. ERP reacts immediately. The storefront continues to show the last value it received.
In B2B, where pricing is rarely universal, this is not a minor UX issue. Distributor agreements layer rebates, margin structures, and category-based rules on top of base catalogs. Volume break structures introduce thresholds that fundamentally change unit cost once order size crosses a defined line. Those thresholds may vary by customer segment, by season, or by sales window. Contract pricing windows define periods during which negotiated rates apply. Once those windows close, the effective price changes even if the underlying SKU does not. Each scenario creates the same structural problem: ERP knows the current state, the storefront knows the last state, and the buyer is left to reconcile the difference at checkout.
What the Cart Does Not Remove
Discounts and promotions amplify this same gap but with different behaviors. In ERP, a promotion is not a static banner. It is a rule with a defined start, a defined end, and a set of conditions. When a campaign window closes in Business Central, that closure is an instruction.
Commerce platforms often treat promotions less as rules and more as states. Once a discount is published, it exists on the storefront until something explicitly removes it. If the signal that a promotion has ended in ERP does not reach the commerce layer in a way the platform can act on, the discount remains visible. The campaign calendar has closed inside the ERP, but the storefront has not enforced that closure.
To the buyer, the distinction between a promotion that is active and one that merely appears active does not exist. If it is visible in the cart, it is assumed to be valid. When checkout recalculates the total and removes the discount, the buyer does not think about sync latency or rule propagation. They think the business changed the terms mid-transaction. That perception is problematic, especially in relationships where trust in pricing underpins the entire commercial relationship.
The operational consequences extend beyond customer experience. An expired promotion that is still honored at checkout creates margin leakage. Sales teams, customer service, and procurement teams work from different versions of the same promotional calendar, which introduces friction into every escalation. The business is effectively living in two realities at once, and the gap between them is where revenue and credibility quietly erode.
One Buyer, Two Failures, One Root Pattern
The procurement manager in the opening scenario experiences both failures in a single journey. The pricing failure hits at browsing time. The discount failure hits at checkout. They are two manifestations of the same structural condition: the storefront only knows what it was told last.
Pricing sync fails when the logic that governs the value does not travel with the data. The calculated price crosses the system boundary. The conditions that produced it — account group, quantity tier, date window, contract status — do not. The storefront is left with a number stripped of its context. Discount sync fails when rule expiration does not translate into storefront behavior. The end of a promotion is recorded in ERP as an event. The storefront continues as though that event never reached it.
At , this is one of the most consistent patterns seen across ERP-commerce implementations on Business Central and Dynamics 365 Finance. The integration is functioning. Data is moving. The sync is running on schedule. Yet buyers still experience pricing inconsistencies, cart surprises, and post-checkout confusion because the logic that governs the data is not making the same journey as the data.
What a Stronger Integration Carries Across
Addressing this requires a change in how integration is framed. Most integration architectures are built to ensure data consistency: get the right records into the right systems and keep them in sync. That is necessary, but not sufficient.
For pricing, the integration must carry more than the calculated value. It must carry the conditions under which that value is valid: account group, quantity tier, date window, contract status. When the storefront understands those conditions, it can evaluate pricing in context at the moment of interaction rather than simply displaying a value that may no longer reflect current terms.
For discounts, the integration must treat expiration as an active event, not a passive absence. When a promotion ends in ERP, that closure must propagate to the storefront with the same fidelity as the original publication. In other words, the integration must be designed to carry meaning alongside data.
The practical result is a buying journey where product pages, cart, and checkout reflect the same underlying logic. Pricing is stable. Promotions behave according to their defined boundaries. A checkout total does not surprise a buyer who already knows what they should be paying.
The Distinction That Matters at Scale
There is a meaningful way to distinguish levels of integration maturity. Synchronization means keeping data consistent across systems. Integration means connecting those systems so they can exchange information and act on it. Translation means converting the logic, rules, and context from one system into a form the other can understand and enforce. Most implementations achieve the first. Many achieve the second. Very few are designed to achieve the third, and the gap between the second and third is exactly where pricing and discount failures accumulate.
Across ERP-commerce implementations on Business Central and Dynamics 365 Finance, the team sees this distinction play out consistently. The integrations that hold at scale are built with an understanding of how ERP actually makes decisions, and they ensure those decisions travel intact to every system the buyer touches.
As commerce environments become more complex, with finer customer segmentation, more dynamic pricing models, and more embedded promotional strategies, the cost of that gap rises. The procurement manager described at the start of this article will keep appearing, in different industries, on different platforms, with the same experience: a storefront that only knew what it was told last, and a business that could not afford the customer it just lost.