Strip away the vendor decks and every ERP-to-commerce integration is one of two architectures. In the first, the storefront reads from the ERP at request time: a logged-in buyer hits a product page, and the platform asks the ERP, right then, what this customer pays and what's in stock. Sana Commerce is built this way. In the second, a connector copies catalog, pricing, and inventory out of the ERP and into the commerce platform's own database, on a schedule or via webhooks. The storefront then serves that copy. BigCommerce, Adobe Commerce, and most platforms work this way, with middleware sitting between the two systems.
We build both. We've shipped Sana storefronts that read pricing live from Business Central and S/4HANA, and we've built middleware-synced BigCommerce stores where a connector keeps the catalog in step with the ERP. Neither is "the right answer" in the abstract. They fail differently, they cost differently, and they're each obviously correct for some businesses and quietly wrong for others. This is the honest comparison.
The two models, precisely
The cleanest way to define them is by where the answer to "what does this customer pay for this item right now" physically lives at the moment the page renders.
In the live-read (real-time) model, the answer lives in the ERP, and the storefront does not have it until it asks. Every authenticated price, every stock figure, every credit check is a round trip to the system of record. There is exactly one copy of the truth, and the storefront never owns it. This is the ERP-first pattern we've written about elsewhere in the context of Sana Commerce.
In the middleware (sync) model, the answer lives in the commerce database, having been written there earlier by a connector that read it from the ERP. The storefront owns a copy. That copy is as fresh as the last sync that touched it. The ERP is upstream and, at request time, out of the loop. This is how most BigCommerce ERP integrations are built.
Everything else follows from that one difference. Hold onto it, because almost every tradeoff below is just a consequence of where the data sits.
Accuracy: one source of truth vs a managed copy
Live read is correct by construction. If the price changed in the ERP a second ago, the next page render sees the new price, because the page render is the query. There is no window during which the storefront is confidently wrong. For B2B, where pricing is frequently customer-specific (contract rates, tier breaks, negotiated overrides) and where being wrong about a contract price is a billing dispute, this is a real and underrated benefit.
The middleware model is correct between syncs and drifts in between. The size of the drift window is a design choice: a webhook-driven connector can push a price change in seconds, while a nightly catalog job leaves you up to a day stale. Most real systems are a blend, and the honest framing is not "is it accurate" but "what is your worst-case staleness, and can the business tolerate it for these particular fields." Stock counts that flip from 4 to 0 between syncs are the classic painful case, because the customer who ordered the phantom unit finds out at fulfillment.
Performance: the ERP is in the request path, or it isn't
This is where the middleware model wins cleanly. Serving a price from your own database, or a cache in front of it, is fast and predictable. You can put a CDN in front of anonymous browse pages and never trouble the ERP at all. Page latency is decoupled from how the ERP is feeling today.
Live read puts the ERP's response time on the critical path of the page. A platform like Sana mitigates this hard with caching and connection pooling, and for typical B2B catalogs (authenticated buyers in the hundreds to low thousands, not millions of anonymous sessions) it's a non-issue. But the ceiling on your page speed is set by the ERP, and if the ERP is a heavily loaded on-prem box, you feel it. The mitigation is architectural discipline: keep anonymous browse pages cacheable and reserve the live round trip for the moments that genuinely need it, like an authenticated price or an add-to-cart stock check.
Resilience: what happens when the ERP is down
This is the question most evaluations skip, and it's the one that bites hardest in year two.
In the live-read model, the ERP is a hard dependency for the parts of the site that read from it. If the ERP goes down for maintenance or falls over, authenticated pricing and live stock degrade with it. Good implementations soften this with cached fallbacks and graceful messaging, but you cannot pretend the storefront is fully independent, because architecturally it isn't. Your storefront's uptime is, for its most ERP-coupled features, bounded by your ERP's uptime.
In the middleware model, the storefront keeps serving its copy while the ERP is down. Browse, prices, and cached stock all keep working. The catch is the other direction: orders placed during the outage have to go somewhere. A well-built connector queues them and posts them when the ERP returns, which means your order-posting path has to be durable and idempotent (more on that below). A badly built one drops them or double-posts them. Decoupling buys you read-side resilience and hands you a write-side queueing problem in return.
Customer-specific pricing: the B2B crux
This single requirement decides more architectures than any other. In B2B, the price is often a function of who is asking: contract pricing, tiered volume breaks, ship-to-specific rules, promotional overrides that the sales team maintains in the ERP.
Live read handles this natively, because the customer context is part of the query. You ask the ERP for "this customer, this item, today," and you get the answer the ERP would give, with no pricing engine to rebuild. Middleware has to replicate the pricing logic, or at least the resolved price lists, into the commerce platform. For a few flat price lists that's trivial. For a deep matrix of customer-specific contract rules, replicating it accurately (and re-validating it every time the ERP rules change) becomes a project of its own, and it's exactly the kind of second pricing engine that drifts. This is the strongest single argument for live read in contract-heavy B2B, and the place where teams most often underestimate the middleware build.
Cost and complexity
Neither model is free, and they spend your budget in different places. Live read concentrates cost in the ERP connector and in ERP performance: you need the ERP to answer quickly and reliably under web load, which sometimes means ERP-side tuning or capacity you didn't plan for. Middleware concentrates cost in the connector's data pipeline: the sync jobs, the field mapping, the conflict and invalidation logic, and the monitoring that tells you when sync has drifted. Middleware also adds an operational surface that live read simply doesn't have, namely a sync system that itself can break, lag, or silently stop, and that therefore needs its own alerting. The recurring mistake is budgeting for the connector build and forgetting the connector's permanent operational tax.
Making middleware feel real-time
Most platforms are middleware platforms, so the practical question is usually not "how do I avoid middleware" but "how do I make a synced storefront behave like a live one where it matters." Three techniques do most of the work.
Cache with explicit invalidation, not just expiry. Time-based expiry guarantees staleness up to the TTL. The better pattern is to let ERP changes actively invalidate the relevant cache entries via webhooks, so a price or stock change pushes an invalidation rather than waiting for a timer. Expiry then becomes a backstop, not the primary mechanism. The hard part is invalidation scope: a single contract-price change can touch many computed entries, and getting the blast radius right is the real engineering.
On-view live calls for sensitive SKUs. You don't need everything live. Identify the fields and items where being wrong is expensive (contract-priced items, low-stock or made-to-order SKUs, anything credit-gated) and make a targeted live call to the ERP for just those, just on the pages where they appear. The rest of the catalog stays cached and fast. This selectively borrows the live-read model's accuracy exactly where it pays for itself, which is often the right blend.
Idempotent, durable order posting. Whichever model you read with, the write path back to the ERP must be safe to retry. Give each order a stable idempotency key, queue posts durably, and make the ERP-side handler reject duplicates rather than create a second sales order. This is what lets you survive ERP outages and connector restarts without double-posting orders, and it matters in both models, but it's non-negotiable for middleware because the queue is doing real work during every ERP hiccup.
A decision framework
Here is the short version we actually use, as prose rather than a table. Lean toward live read when the ERP holds deep customer-specific or contract pricing you don't want to rebuild, when real-time available-to-promise and credit state genuinely gate sales, when your audience is mostly authenticated buyers rather than anonymous browsers, and when your ERP can answer quickly under load. Lean toward middleware sync when most traffic is anonymous catalog browsing that should be CDN-fast, when pricing is simple enough to replicate as a handful of price lists, when you need the storefront to keep selling while the ERP is offline, or when the ERP cannot take live web traffic. And reach for the hybrid (sync the bulk, live-call the sensitive few) when you have a fast anonymous catalog but a tail of contract-priced or low-stock items that must be exact. The thing to avoid is choosing a model and then operating it as if it were the other one: caching a live-read platform until it's secretly a stale copy, or bolting so many live calls onto a middleware platform that you've rebuilt the ERP dependency without the single-source guarantee.
What this means for buyers
The platform you pick has already made this choice for you, mostly. Sana is live read. BigCommerce and Adobe are middleware. So the real decision is upstream: does your business run on the ERP to the point that a copy is a liability, or is the ERP light enough that decoupling is pure upside? Answer that honestly and the platform shortlist mostly writes itself. If you're weighing exactly this, our Sana Commerce vs BigCommerce comparison walks the same fork from the platform side.
If you're sizing this on a real project and want a straight answer about which model fits, that's the work we do. Start a conversation here.