u/Ayush_Agarwal29

One thing that gets overlooked in ERP eCommerce integrations is that a discount is usually not just a number.

In many systems, a “promotion” is actually a set of rules: who qualifies, when it starts and ends, what quantity triggers it, and whether it applies to a customer account or a campaign. The problem is that a storefront often handles those rules differently than the ERP does.

So even when the discount value syncs correctly, the promotion can still behave wrong online. A promotion may expire in ERP but stay visible on the storefront, or a customer-specific rule may get flattened into a generic discount. That is where confusion starts for both buyers and support teams.

The bigger takeaway for me is this: syncing the price is not the same as syncing the logic behind the price.

Has anyone here run into this with Business Central, NetSuite, Dynamics, SAP, or Shopify/Adobe Commerce integrations?

I work in ERP–eCommerce integration and this is probably the most misdiagnosed problem I see in B2B commerce setups: discount sync appears to work perfectly, but promotions behave incorrectly in ways that take weeks to surface.

Here's the root cause, and it's not technical, it's architectural.

The core mismatch

ERP systems like Business Central, SAP B1 treat discounts as rules. A 12% promotional discount isn't just a number, it's an instruction set:

• Valid between Date A and Date B
• Applicable only to customers in pricing group X
• Triggered only at a minimum quantity of N units
• Tied to a specific marketing campaign

eCommerce platforms like Adobe Commerce (Magento), Shopify, BigCommerce treat discounts as display states. A promotion is either on or off. When you sync from ERP to eCommerce, most integrations move the value (12%) but not the reasoning behind it.

The storefront interprets "12% discount" and applies it. Universally. Until someone turns it off.

Three failure modes this creates

1. Promotions outlive their expiry

ERP ends promotions automatically at the defined end date, no manual action needed. eCommerce promotions are state-based, they stay active until explicitly deactivated.

When the sync carries the discount value but not the expiration rule, promotions that have closed in ERP continue running on the storefront. Customers see and order against discounts that no longer exist.

The damage: customers get invoiced at full price after ordering against a "live" promotion. Support tickets follow. Repeat buyers start calling to verify discounts before ordering, defensive behavior that signals broken trust.

2. Browse price ≠ checkout price

ERP calculates discounts at order processing time, using live rules at the moment of commitment. eCommerce shows pricing at browse time, a pre-calculated snapshot from when the product page was loaded.

If anything between those two moments changes the applicable discount (quantity thresholds, customer group logic, promotion state), the checkout price differs from what the product page showed.

New buyers hit this and abandon. No error message. No indication anything went wrong. Just a cart left behind.

3. Customer-specific discounts apply universally

Account-level pricing agreements and group-specific promotions in ERP are tied to specific customer segments. When the sync strips that context, the discount becomes universal, visible and applicable to anyone who visits the product page.

This creates incorrect pricing expectations for customers who shouldn't see those prices, and can create margin exposure depending on the discount depth.

What actually fixes it

The integration needs to carry rule metadata alongside the discount value:

• Start and end dates (so expiry triggers automatically in eCommerce)
• Customer group and account eligibility (so discounts apply only to the right segments)
• Quantity thresholds (so tier-based discounts activate correctly)
• Campaign identifiers (so promotions tie back to marketing calendars)

Additionally, checkout calculation needs to use live ERP rules, not the browse-time snapshot, so the price a customer sees on a product page matches what they're charged.

When you build it this way, discount logic is enforced consistently across both systems. Promotions expire when they're supposed to. Prices are stable from browse to checkout. Account agreements stay account-specific.

How to diagnose this in your setup

A few questions worth asking:

• Do promotions ever stay active on your storefront after they've been closed in ERP?
• Do customers ever question why the checkout total differs from the product page?
• Does finance notice margin inconsistencies that don't match campaign performance?
• Do repeat buyers call or email to confirm discounts before placing orders?

If any of these are familiar, the integration is moving values but not logic.

Happy to go deeper on any specific ERP or eCommerce platform combination if useful.

I work in ERP–eCommerce integration and this is probably the most misdiagnosed problem I see in B2B commerce setups: discount sync appears to work perfectly, but promotions behave incorrectly in ways that take weeks to surface.

Here's the root cause, and it's not technical, it's architectural.

The core mismatch

ERP systems like Business Central, SAP B1 treat discounts as rules. A 12% promotional discount isn't just a number, it's an instruction set:

• Valid between Date A and Date B
• Applicable only to customers in pricing group X
• Triggered only at a minimum quantity of N units
• Tied to a specific marketing campaign

eCommerce platforms like Adobe Commerce (Magento), Shopify, BigCommerce treat discounts as display states. A promotion is either on or off. When you sync from ERP to eCommerce, most integrations move the value (12%) but not the reasoning behind it.

The storefront interprets "12% discount" and applies it. Universally. Until someone turns it off.

Three failure modes this creates

1. Promotions outlive their expiry

ERP ends promotions automatically at the defined end date, no manual action needed. eCommerce promotions are state-based, they stay active until explicitly deactivated.

When the sync carries the discount value but not the expiration rule, promotions that have closed in ERP continue running on the storefront. Customers see and order against discounts that no longer exist.

The damage: customers get invoiced at full price after ordering against a "live" promotion. Support tickets follow. Repeat buyers start calling to verify discounts before ordering, defensive behavior that signals broken trust.

2. Browse price ≠ checkout price

ERP calculates discounts at order processing time, using live rules at the moment of commitment. eCommerce shows pricing at browse time, a pre-calculated snapshot from when the product page was loaded.

If anything between those two moments changes the applicable discount (quantity thresholds, customer group logic, promotion state), the checkout price differs from what the product page showed.

New buyers hit this and abandon. No error message. No indication anything went wrong. Just a cart left behind.

3. Customer-specific discounts apply universally

Account-level pricing agreements and group-specific promotions in ERP are tied to specific customer segments. When the sync strips that context, the discount becomes universal, visible and applicable to anyone who visits the product page.

This creates incorrect pricing expectations for customers who shouldn't see those prices, and can create margin exposure depending on the discount depth.

What actually fixes it

The integration needs to carry rule metadata alongside the discount value:

• Start and end dates (so expiry triggers automatically in eCommerce)
• Customer group and account eligibility (so discounts apply only to the right segments)
• Quantity thresholds (so tier-based discounts activate correctly)
• Campaign identifiers (so promotions tie back to marketing calendars)

Additionally, checkout calculation needs to use live ERP rules, not the browse-time snapshot, so the price a customer sees on a product page matches what they're charged.

When you build it this way, discount logic is enforced consistently across both systems. Promotions expire when they're supposed to. Prices are stable from browse to checkout. Account agreements stay account-specific.

How to diagnose this in your setup

A few questions worth asking:

• Do promotions ever stay active on your storefront after they've been closed in ERP?
• Do customers ever question why the checkout total differs from the product page?
• Does finance notice margin inconsistencies that don't match campaign performance?
• Do repeat buyers call or email to confirm discounts before placing orders?

If any of these are familiar, the integration is moving values but not logic.

Happy to go deeper on any specific ERP or eCommerce platform combination if useful.

Your ERP says 95 units. Your warehouse can ship 50. Your customer ordered 80. Sound familiar?

I've been digging into a pattern that keeps coming up in eCommerce operations, and it's costing businesses customers silently.

Here's the core problem:

Most teams treat inventory sync as the "easy" part of ERP-eCommerce integration. Products are mapped, pricing is aligned, taxes are sorted, inventory is just a number, right? Sync it, display it, done.

That assumption is exactly where things fall apart.

ERP inventory ≠ eCommerce inventory.

Your ERP manages operational availability. Your storefront makes commercial promises. These are fundamentally different things, and when you sync one as the other without interpretation, customers pay the price.

Here are the three failure modes I see most often:

1. Reserved stock gets shown as sellable stock

Your ERP correctly holds 30 units in reserve for existing orders, 15 units as safety buffer. Total on-hand: 95. What does Shopify show? 95.

A customer orders 80. The warehouse can't ship it. Customer is furious, not because you lied, but because your storefront made a promise operations couldn't keep.

Fix: derive sellable quantity = on-hand minus reservations minus safety buffers. Never sync raw on-hand.

2. Multi-warehouse inventory collapses into one number

Customer in California orders 20 units. Storefront shows availability. Three days later, all stock is in New Jersey. Two-week delivery. Customer doesn't come back.

The inventory number was accurate. The availability was completely misleading.

Fix: preserve warehouse context in your integration. Route orders by geography. Show realistic lead times per region.

3. Inbound POs inflate current availability

Your procurement team includes inbound purchase orders in available totals, smart for planning, but that number flows into Shopify as "in stock." Customers order. Stock arrives in 12-18 days. They expected tomorrow.

Fix: separate "in stock now" from "available in X days." Surface honest availability signals instead of one inflated number.

The fix that actually worked (for a B2B distributor I read about with this exact problem):

They stopped syncing inventory numbers. They started translating inventory intent.

Sellable qty = on-hand − reserved − safety stock

Warehouse-aware routing for each region. Three distinct availability states: ships today / available in X days / backorder

Result: support tickets dropped. Repeat buyers stopped calling to "confirm" before ordering online. The storefront became a reliable channel again.

Has anyone else dealt with this? Curious what your experience has been with inventory sync accuracy across ERP platforms.