BigCommerce and SAP, connected properly.

Nothing about this project can be scoped until that is answered, because the three are different products with different integration surfaces. Anybody who quotes “a BigCommerce SAP integration” without asking is quoting a guess.

BigCommerce is the easy end. It gives you a documented REST and GraphQL API, webhooks, price lists and customer groups, and B2B Edition adds company accounts and hierarchies. It behaves like a modern SaaS product because it is one.

SAP is where the decisions are, and there are really only four routes:

• BAPIs and RFC. The classic path, and on ECC often the only one that reaches the logic you need. Synchronous, fast, and it requires an RFC connection into your landscape, which is a conversation with whoever owns Basis and the firewall.
• IDocs. Asynchronous documents. Excellent for order and invoice flow where a few minutes of latency is fine, and completely wrong for “what does this customer pay for this item right now.” A lot of underperforming storefronts are underperforming because somebody used IDocs for pricing.
• OData via SAP Gateway. The modern surface. Standard on S/4HANA, available on ECC if somebody configures it. This is where you want to be if you have the choice, because it is HTTP, it is cacheable and every developer already understands it.
• Middleware. SAP Integration Suite, or a third-party iPaaS such as Boomi, Celigo, Jitterbit or MuleSoft. Adds cost and a hop, buys you retries, transformation, monitoring and a place to put logic that belongs to neither system.

The honest default for most B2B builds: OData or BAPI for anything the shopper waits on, IDoc for document flow that can be asynchronous, and middleware in front so that a slow SAP does not become a slow storefront. Deciding that early is most of the architecture.

Strip away the diagrams and every B2B storefront asks its ERP the same six questions. Getting these six right is the project. Everything else is decoration.

1. Who is this customer. The SAP customer number behind the logged-in account, including sold-to, ship-to and payer where they differ, which in B2B they routinely do.
2. What do they pay. Net price for this customer, this material, this quantity, today. This is the hard one and it gets its own section below.
3. What can they have. Not just stock on hand. Available-to-promise, across the plants that customer is actually served from.
4. Place the order. And return a real SAP sales document number, not a BigCommerce order id with a promise to sync later.
5. Where is it. Delivery and shipment status, tracking where the carrier feeds it back.
6. What do they owe. Invoice history, open items, credit position. This is what turns a storefront into a self-service account portal, and it is the part buyers actually log in for.

Number six is consistently underestimated. Most B2B buyers do not visit your store to browse. They visit to reorder something they have bought before and to find out what they owe.

If one section of this page is worth reading, it is this one.

SAP does not store a price for a customer and a material that you can simply look up. It calculates one, at the moment you ask, using the condition technique: a pricing procedure made of condition types, evaluated through access sequences against condition records, filtered by validity dates. A customer's net price can depend on their price list, contract, material group, order quantity, scale breaks, promotions, surcharges, freight and tax, resolved in a specific sequence that your business configured over years.

You cannot reimplement that in a storefront, and you should not try. Every attempt we have been called in to rescue has been the same story: somebody exported condition records into BigCommerce price lists, it was right for most customers, and the exceptions turned into a quiet stream of incorrect orders that finance found weeks later.

The correct pattern is to ask SAP. Price the cart in SAP, whether through a pricing BAPI, a simulated sales order, or an OData service built for the purpose, and render what it returns. Then engineer around the latency rather than around the truth:

• Cache aggressively, and per customer. A price is valid for that customer for a workable window. Cache it, and invalidate on the events that actually change it.
• Price the list, price the cart exactly. Catalogue and search can serve a cached or indicative price. The cart, the quote and the checkout must be a live SAP number, because that is what gets invoiced.
• Never show a price you cannot honour. If SAP is unreachable and you have no valid cached price, show the customer that pricing is temporarily unavailable and let them request a quote. An unreachable ERP is an inconvenience. A wrong price is a credit note and a phone call.
• No price means no add-to-cart. If SAP holds no price for that customer and material, disable it rather than letting an order through that will fail downstream.

Plenty of the companies asking us this question are on ECC and have an S/4HANA programme somewhere on a roadmap. The instinct is to wait. Usually that is the wrong call, because the storefront is earning or losing money now and the S/4 programme will slip.

The right call is to build in a way that survives the migration:

• Put an integration layer in the middle. The storefront talks to your layer; your layer talks to SAP. When SAP changes underneath, you rewrite one adapter rather than the storefront.
• Define the six contracts in your own terms first. Not in SAP's. “Get net price for customer and material” is a stable idea. The BAPI behind it is not.
• Keep SAP-specific field names out of the storefront. Map at the boundary. This is the single cheapest thing you can do now to make the S/4 cutover uneventful.
• Test the contracts against S/4 before the ERP goes live, not after. Field lengths, document types and error behaviour all change, and the storefront is usually the last system anybody thinks to test.

Done that way, the S/4HANA migration touches one adapter and a test run. Done the other way, it becomes a second storefront project you did not budget for.

From the projects we have been brought into after the fact, in rough order of how often:

• Pricing was copied instead of asked. Covered above. It is the number one cause of a B2B storefront quietly losing the business money.
• The storefront is only as fast as SAP. No caching layer, so every product page waits on an ERP that was sized for batch work and internal users.
• Orders duplicate. No idempotency key on submission, so a retry or a double click creates two sales documents, and nobody notices until shipping does.
• Nobody owns the failure path. SAP goes down for a maintenance window and the storefront shows a stack trace or, worse, a zero price.
• Stock is right and useless. Total stock is synced instead of available-to-promise for that customer's plant, so the site promises what it cannot ship.
• No observability. When a customer says their price is wrong, nobody can answer what SAP returned at the moment they looked, so the investigation starts from nothing.

None of these are exotic. All of them are cheaper to prevent than to find in production, which is the argument for doing the integration design before the storefront design rather than after.