FROM THE FIELD

Why your ERP breaks when you bolt ecommerce on top of it

Ecommerce doesn't break the ERP, it exposes the gaps that were already there. When the storefront starts asking the ERP for live pricing, availability, customer history, and order state at customer scale, the data quality, integration latency, and business logic it was running on quietly become very visible. The work to fix it is rarely in the ecommerce platform; it's in the ERP and the contract between them.

What does it actually mean to say the ERP 'breaks' when ecommerce is added?

'Breaks' is shorthand for four very different failures: data breaks, load breaks, logic breaks, and latency breaks. Each one shows up differently in the storefront and each one has a different remedy. Conflating them is the most common mistake we see during stalled B2B launches.

Data breaks look like wrong prices, missing units of measure, duplicate customers, and SKUs that exist in the ERP but cannot be displayed. Load breaks look like a sluggish ERP whenever the storefront runs a category page. Logic breaks look like contract pricing applied incorrectly, approvals missed, or rebates ignored. Latency breaks look like a checkout that times out under traffic. Pinpointing which one is happening is the first job of a discovery team.

These failures aren't unique to a particular ERP. They show up against Acumatica, NetSuite, SAP, Microsoft Dynamics, Infor, and a long tail of regional and legacy systems. The ERP is doing what it was always doing; it's just now being asked to do it for an audience of anonymous and authenticated buyers instead of a handful of internal users.

Which failure modes show up most often in B2B launches?

The four we see repeatedly are: duplicate customer records that fragment pricing, missing or inconsistent units of measure on SKUs, expired or orphaned price lists still flagged active, and inventory locations that the storefront has no way to interpret. Any one of them is enough to delay a launch. All four together is a project that has stalled and doesn't know why.

Beyond data, the next failures are usually about API surface. The ERP may have a working API but no endpoint that returns customer-specific pricing in one call. Or it returns the data but uses internal codes the storefront can't map to a product. Or the endpoint exists but throttles at a rate well below what category browsing produces. These are integration shape problems, and they are solvable, but they need to be discovered before the platform is bought.

The third pattern is business logic the ERP performs as part of order entry but the storefront has to imitate. Tax overrides, freight rules, line-level discounts, contract terms, and rebate accruals are typical examples. The right answer is rarely 'rebuild this in the storefront', because then you have two sources of truth that will diverge. The right answer is usually to expose the ERP's calculation as a service the storefront can call, or to accept a lighter-weight calculation on the storefront and reconcile in the ERP.

Why do real-time calls to the ERP expose hidden technical debt?

Internal ERP users work in narrow, predictable patterns. A handful of people open a few screens, save a few records, and close. Ecommerce traffic is the opposite shape: many concurrent, anonymous, bursty reads, with category pages requesting inventory and prices for fifty SKUs at a time. The ERP may have been sized for the old shape and never tested against the new one.

That mismatch surfaces design choices that nobody had to think about before. Indexes that were good enough are now slow. Stored procedures that ran once a day are now running per page view. Customizations that wrote to a single user's session are now race conditions. None of this is a flaw in the ERP, it's the natural cost of asking a system of record to also be a system of engagement. Acumatica's own developer guidance on building integrations and Microsoft's Dynamics 365 performance recommendations both acknowledge that integration patterns matter as much as raw throughput.

There's a quieter form of debt that surfaces here too: business logic encoded in screen behaviour. If validating a discount only happens because the order-entry clerk hits 'Save' on a particular form, and the API path skips that screen, the discount goes through unvalidated. We see this often enough that we now ask, during discovery and strategy, what business rules are enforced only at the UI layer of the ERP. That answer tells us how much logic the integration has to recreate, defer, or move.

What architectural patterns protect the ERP from ecommerce traffic?

The dominant pattern is a thin integration layer that caches what doesn't change often, calls the ERP live for what must be exact, and queues writes so they never block a customer. That layer is sometimes a dedicated middleware, sometimes a feature of a composable commerce stack, sometimes a custom service. The shape matters less than the discipline: separate the call patterns so the ERP isn't asked to do everything synchronously.

Caching is the highest-leverage move. Product attributes, category structures, and most pricing components change minutes-to-hours at a time, not millisecond to millisecond. A cache with a sensible invalidation strategy reduces ERP load by orders of magnitude with no customer-visible cost. The exception is anything that affects the buyer's commitment at checkout: final price, final availability, and tax. Those should call live or use a near-time reservation pattern.

Write patterns deserve equal care. Order creation should be queued, idempotent, and observable. If the ERP is briefly slow, the customer should not see it. If a write fails, the system should retry safely without creating duplicates. We see machalliance.org's MACH principles cited often for this, and they do describe the shape well, but the principles are older than the acronym. They're the same patterns that worked before composable commerce had a name.

When should we cache, call live, or rebuild the logic somewhere else?

A rough rule of thumb: cache what's read often and changes slowly; call live what affects the buyer's commitment; rebuild the logic in a service when the ERP cannot serve the call pattern that commerce needs. The boundaries between those three are the most consequential design decisions in an ERP-driven build, and they should be made deliberately, per domain, during ERP integration and expansion work.

Pricing is the canonical mixed case. Base prices and customer-specific price lists can be cached; final line totals and order-level discounts often need a live call; freight and tax are usually externalised to dedicated services. Inventory is similar: stock buckets can be cached on a short TTL for browse; checkout should call live or use a near-time reservation. Account hierarchy data, in our experience, can be cached aggressively because it changes infrequently and is read constantly.

Rebuilding logic in a service is a last resort, but sometimes the right one. If the ERP's API doesn't expose a calculation cleanly, or if the calculation depends on data the ERP doesn't surface, building a thin pricing or eligibility service that the commerce platform calls is cleaner than re-creating it in the storefront. The discipline is to feed that service from the ERP nightly or hourly, so the ERP remains the source of truth even when it isn't the runtime.

Underneath all of this is a posture: the platform doesn't matter until the business logic is understood. Manufacturers who skip the discovery work and start with the platform almost always end up redesigning the integration twice. The teams who design the integration shape first, then pick the platform, ship faster and with fewer regressions, because they've already done the hard thinking before anyone wrote a line of front-end code.

Frequently Asked Questions

Next step

Get the foundation right before you build.

For readers scoping a platform decision or wanting a full architecture recommendation.