Most teams assume discounts are where integration finally becomes predictable.
Products are translated. Inventory is aligned. Tax logic is reconciled. Pricing rules are replicated. Discounts seem simple by comparison — create a promotion in ERP, push it to the storefront, let customers see the price.
But here is the integration truth no one tells you:
Discounts are not values. They are rules. And rules don’t sync the same way numbers do.
When discount logic doesn’t translate — when ERP’s conditional, time-bound, customer-specific reasoning collapses into a flat percentage on a product page — promotions don’t just break. They linger. They misfire. They apply when they should not.
And revenue quietly leaks while integration logs stay clean.
The Setup
Vertex Supply Co. (name changed) is a growing B2B distributor running seasonal promotions, customer-specific pricing agreements, and volume-based discount campaigns.
Their stack:
- Storefront: Adobe Commerce
- ERP: Dynamics 365 Business Central
In Business Central, their discount structure was deliberate and layered:
- Customer-specific pricing agreements tied to account relationships
- Time-bound seasonal promotions with defined start and end dates
- Tiered quantity discounts applied at order thresholds
- Campaign-based pricing aligned to marketing calendars
Everything worked inside ERP. The logic was airtight. When eCommerce launched, the assumption followed naturally: sync discounts from Business Central, show them on Adobe Commerce, keep everything aligned.
At first glance, it worked. Prices looked right. Discounts appeared on product pages. Customers started ordering.
But within weeks, something began fraying at the edges.
Two Customers, Two Very Different Outcomes
Meet Derek Santos. He is the procurement director at a regional industrial supplies firm and has been buying from Vertex for four years. His orders are structured around quarterly planning cycles and seasonal promotions — he times purchases deliberately to capture the right windows.
Meet Priya Mehta. She is a procurement coordinator at a mid-sized facilities management company. She discovered Vertex through a campaign promotion offering 15% off on a product line her team needed. This was her first order.
Both encountered discounts on the Vertex storefront. Neither had the experience the system was designed to deliver.
First Translation Failure
Discounts Synced as Values, Not Rules
In Business Central, every discount carried context. A 12% promotional discount on industrial fasteners was not just a number. It was:
- Valid between two specific dates
- Applicable only to accounts in the Standard Commercial pricing group
- Conditional on a minimum order quantity of 50 units
Adobe Commerce received that discount.
But not the reasoning behind it.
What the storefront interpreted: “Apply 12% discount.”
What Business Central intended: “Apply 12% discount, if the buyer is in this group, ordering this quantity, within this window.”
No context. No conditions. No expiration logic.
The discount value traveled. The discount intelligence did not.
This is the invisible starting point for every failure that followed. A technically correct sync that was logically incomplete — and that incompleteness compounded with every subsequent order.
Second Translation Failure
Promotions Expire in ERP — But Persist Online
This is where the financial impact became visible. And where Derek’s experience made the problem impossible to ignore.
In Business Central, promotions had clear validity windows: start date to end date. Once expired, Business Central no longer applied those promotions to any new orders. The logic was automatic, rule-driven, and consistent.
Adobe Commerce operated differently.
Promotions in eCommerce are state-based — they remain active until someone explicitly turns them off. Business Central’s expiration rule did not travel with the discount. It was the one piece of logic the sync did not carry across.
So promotions that had officially closed in ERP continued running on the storefront.
Derek knew about Vertex’s end-of-quarter seasonal discount. He had used it before. He placed a large order three weeks after the promotion had officially ended in Business Central, having seen it still active on the product pages. He planned his purchase around it.
His invoice came back at full price.
Business Central had recalculated at order processing time, found no active promotion, and applied standard pricing. Adobe Commerce had shown him a discount that no longer existed anywhere except the storefront.
Derek spent forty-five minutes on the phone with Vertex’s support team before anyone understood what had happened.
The promotion was over. Just not everywhere.
ERP ends promotions by rule. eCommerce ends them by manual action. When the integration does not carry expiration logic, promotions outlive their intended window — and business makes commitments it never intended to honor.
Third Translation Failure
Browse Price vs. Checkout Price
Priya’s experience hit differently — and earlier in the journey.
She was browsing Vertex’s catalog during an active campaign. 15% off on the product line her team needed. She added items to her cart, reviewed the total, and proceeded to checkout.
At checkout, the discount had changed. Not disappeared — changed. The percentage applied was different from what the product pages had shown.
Why?
ERP calculates discounts at order processing time, applying live rules, current quantity thresholds, and customer group logic at the moment of purchase.
eCommerce displays discounts at browse time — pricing shown on product pages reflects a pre-calculated snapshot, not the live calculation that runs when the order finalizes.
That gap — between what the product page showed and what checkout confirmed — created hesitation. Priya refreshed the page. Checked the math. Could not reconcile the difference. She abandoned the cart and ordered from a competitor the same afternoon.
Vertex never knew they had lost her until data showed an abandoned cart with no follow-up. The storefront had shown no errors. The sync had shown no failures.
ERP discount logic is calculated at the point of commitment. eCommerce discount display is calculated at the point of discovery. When those two moments don’t produce the same number, the customer experience fractures — and often silently.
The Breaking Point
Derek’s support call was not the only one. Finance began noticing margin inconsistencies — discount percentages on invoices that did not match campaign performance expectations. The sales team heard from account managers: customers were confused about pricing.
Repeat buyers started calling to verify discounts before placing orders — the same defensive behavior that had appeared with inventory. And Priya’s abandoned cart was one of several that week from new buyers who never completed their first order.
Individually, each issue seemed like a minor inconsistency. Together, they pointed to the same root cause.
The integration logs showed no errors. Everything was syncing correctly. Vertex eventually named the problem plainly:
“We synced discounts. We never synced discount logic.”
Enter i95Dev: Translating Discount Intelligence
When Vertex partnered with i95Dev, the conversation shifted from moving values to preserving intent.
Instead of asking: “How do we sync discounts better?”
We asked: “How should a discount behave when a customer buys — and when should it stop?”
1. Syncing Discount Rules, Not Just Values
Rather than pushing final discounted prices, the integration was rebuilt to carry the full rule set from Business Central into Adobe Commerce:
- Start and end dates for every promotion
- Customer group eligibility and account-level agreements
- Minimum quantity thresholds
- Campaign identifiers linking promotions to marketing calendars
Adobe Commerce stopped receiving static discount values. It started receiving promotional logic — the instructions behind the discount, not just its result. This meant the storefront could apply discounts conditionally, the way Business Central intended, rather than universally, the way a raw sync had produced.
2. Enforcing Promotion Lifecycle Across Systems
The critical fix for Derek’s situation was building a real-time promotion lifecycle layer.
When a promotion expired in Business Central, that expiration event now triggered an automatic update in Adobe Commerce. The storefront did not wait for a manual deactivation. It responded to the ERP’s state.
No more lingering promotions. No more customers ordering against discounts that had already closed. When a promotion ended in ERP, it ended everywhere.
A call like Derek’s — forty-five minutes of confusion over a discount that had silently outlived its window — became structurally impossible.
3. Aligning Checkout Calculation with ERP Logic
The fix for Priya’s situation required closing the browse-vs-checkout gap directly.
The cart and checkout flow were enhanced to recalculate discounts using live ERP rules at the point of purchase confirmation, not the pre-calculated snapshot from when the product page first loaded.
Customers now saw:
- Accurate pricing on product pages
- The same pricing reflected in their cart
- Confirmed pricing at checkout — no last-moment revision
The hesitation moment Priya experienced — the page refresh, the arithmetic that wouldn’t resolve, the abandoned cart — was removed from the buyer journey entirely.
The Result
Expired promotions stopped appearing on the storefront. Discount values on product pages matched checkout consistently for the first time. Margin reporting stabilized and aligned with campaign expectations.
Support volume for pricing-related calls dropped. Calls like Derek’s — that consumed forty-five minutes and tested a four-year relationship — stopped happening.
New buyer conversion improved. The friction that cost Vertex Priya’s first order — and others like her — was removed from the path.
Repeat buyers stopped calling ahead to confirm discounts before ordering. The storefront had earned back the trust that earned the self-service behavior in the first place.
Pricing became something customers could rely on, from product page to invoice.
| Attribute | ERP (BC / NetSuite / SAP B1) | eCommerce (Adobe Commerce / Shopify / Magento) | The Gap |
| Discount structure | Rule-driven: conditions, dates, groups, quantity thresholds | Display-driven: value shown on product page | Conditions stripped during sync; context lost in transit |
| Promotion expiry | Automatic and rule-based; ends at defined date without manual action | State-based; remains active until explicitly deactivated | Promotions expire in ERP and persist on the storefront |
| Calculation timing | At order processing time, using live rules and current conditions | At browse time, from a pre-calculated snapshot | Product page price diverges from checkout price |
| Customer-specificity | Discount eligibility tied to customer groups and account agreements | Applied broadly unless manually segmented in the storefront | Group-specific discounts display universally, creating incorrect expectations |
The i95Dev Fix
Translate discount intelligence, not just discount values
- Sync rule metadata: start and end dates, customer group eligibility, quantity thresholds, campaign identifiers
- Enforce promotion lifecycle: expired ERP promotions automatically deactivated on the storefront
- Align checkout calculation with ERP logic — live rules applied at order confirmation, not at browse time
- Prevent invalid or expired discounts from persisting beyond their intended window
The Integration Truth
Discounts don’t fail because they don’t sync.
They fail because their logic doesn’t translate.
ERP discounts are built to control pricing with precision — conditional, time-bound, and customer-aware. eCommerce discounts are built to influence buying behavior — visible, immediate, and conversion-driving.
When those two systems aren’t aligned, promotions overstay. Discounts misapply. Revenue leaks through a channel your integration logs will never flag.
At i95Dev, we don’t sync discount values. We translate the logic behind them — so both systems enforce the same rules, honor the same conditions, and respect the same expiration.
Because a discount that applies when it shouldn’t is not a benefit. It is a liability that your ERP, your finance team, and eventually your customer will all notice at different times.
This Was the Sixth Translation Failure
The first made the catalog misleading before a single order was placed.
The second made products behave unexpectedly the moment someone purchased.
The third broke financial reconciliation — quietly, repeatedly, in amounts too small to see but too consistent to ignore.
The fourth eroded customer trust through accurate inventory that meant the wrong thing.
The fifth created pricing inconsistencies that finance and customers noticed simultaneously.
The sixth let promotions overstay their welcome, let discounts misapply without error, and let revenue leave through a gap no integration log would ever surface.
Where might discount translation be missing in your experience?
- Do promotions continue appearing on the storefront after they have been closed in ERP?
- Do customers question why the checkout price differs from the product page?
- Does finance notice margin inconsistencies that don’t match campaign expectations?
- Do repeat buyers call to confirm discounts before placing orders?
- Do support calls frequently involve pricing that looked right but invoiced differently?
If these feel familiar, you are not looking at a sync problem.
You are looking at a translation gap — something beyond the sync.
And even when discount logic is aligned, another layer waits. Orders change after they are placed. Edits, partial fulfillments, cancellations, and returns introduce the next translation challenge. That is where the next failure begins.
