BigCommerce, wired into your ERP.
ProjectThunder connects BigCommerce to SAP, Microsoft Dynamics 365, NetSuite, and Acumatica through middleware and iPaaS, then engineers the storefront so pricing, stock, and orders feel live even though the platform syncs rather than reads the ERP in real time. Here is how that actually works, and where the seams are.
What actually needs to sync.
An ERP integration is not one pipe. It is a set of data flows, each with its own direction, latency target, and failure behavior. Get the contract for each one right and the storefront stays honest. Get it wrong and buyers see stale prices, oversells, or orders that never reach the ERP. This is what we map first, before any code. If your pricing truly has to be read live rather than synced, that is a different architecture, and our Sana Commerce vs BigCommerce comparison covers when to make that call.
Catalog & product data
- Direction: ERP to BigCommerce, the ERP item master is the source of truth
- Products, SKUs, variants, units of measure, and category hierarchy mapped to BigCommerce
Catalogobjects - Item attributes, specs, and spec sheets enriched on the way in, often with AI assistance
- Lifecycle flags: new, discontinued, replaced-by, and channel visibility per storefront
- Sync trigger on item-master change events, with a nightly reconciliation pass as a safety net
Customer-specific pricing
- Direction: ERP to BigCommerce, the hardest flow to get right
- Contract pricing, customer groups, volume breaks, and regional terms mapped to BigCommerce price lists
- Surfaced per buyer through the GraphQL Storefront API using a customer impersonation token
- Promotions and list-vs-net handled so the price shown equals the price ordered
- Note the platform limit: GraphQL does not sort by price-list pricing, so we design search and sort around it
Inventory & available-to-promise
- Direction: ERP or WMS to BigCommerce, the most latency-sensitive flow
- Near real-time stock updates pushed on inventory-change events rather than a slow poll
- Multi-warehouse and location-aware availability where the catalog supports it
- ATP logic kept honest: backorder rules, safety stock, and lead times reflected at the PDP
- Guardrails against overselling when sync lags, including soft-reserve at add-to-cart
Customers & accounts
- Direction: bidirectional, the ERP customer master and BigCommerce company accounts stay aligned
- B2B company accounts, sub-buyers, and ship-to addresses mapped to ERP sold-to and ship-to records
- Customer-group assignment that drives both pricing and catalog visibility
- New-account creation routed for approval, not auto-pushed into the ERP unchecked
- Net terms, credit limits, and AR holds read from the ERP so checkout respects them
Orders
- Direction: BigCommerce to ERP, with status flowing back
- Web orders posted as ERP sales orders with the correct document type and journal flow
- Idempotency keys so a retry never creates a duplicate order in the ERP
- Quote-to-order and PO-upload flows from B2B Edition mapped into the ERP cleanly
- Order, shipment, and tracking status synced back to the buyer's account view
Invoices & credit
- Direction: ERP to BigCommerce, read-only into the buyer portal
- Open invoices, balances, and document attachments exposed in the account area
- On-account checkout gated by live credit status so blocked accounts cannot over-order
- Payment and settlement status reconciled back against the ERP AR ledger
- No financial writes from the storefront, the ERP stays the system of record for AR
Integration patterns that survive production.
The platform syncs rather than reads the ERP live, so the engineering job is making a synced storefront behave like a live one, and degrading gracefully when the ERP is unreachable. These are the patterns we reach for.
Middleware & iPaaS
- iPaaS connectors (
Celigo,Boomi,Jitterbit,MuleSoft) for standard catalog, pricing, customer, and order flows - Packaged ERP connectors where one exists and fits the data model out of the box
- Custom services in
.NET 9for flows the connector cannot model: unusual pricing, multi-entity, strict latency - Often a hybrid: iPaaS backbone for the common entities, targeted custom code for the exceptions
- BigCommerce side wired through
REST Admin,GraphQL Storefront, and webhooks
Real-time vs batch
- Event-driven (webhooks and ERP change events) for stock, orders, and credit where latency matters
- Scheduled batch for slow-moving data like the full catalog and category tree
- A nightly reconciliation pass to catch anything a missed event left out of sync
- Per-flow latency budgets agreed up front, not a single sync cadence for everything
- Honest framing with stakeholders: near real-time on BigCommerce, not the live read Sana provides
Webhooks & idempotency
- BigCommerce webhooks for order and customer events, ERP events for stock and pricing
- Idempotency keys on every write so retries and duplicate deliveries never double-post
- A durable queue (for example
RabbitMQor a managed bus) between the platforms, not direct calls - Ordered, replayable processing so a burst of events cannot scramble state
- Dead-letter handling for events that fail repeatedly, surfaced to ops rather than dropped
Caching for live-feeling pricing
- Customer-specific pricing pre-resolved into price lists, not computed on every request
- Short TTL caches on high-read data with event-driven invalidation when the ERP changes
- GraphQL Storefront queries scoped to the customer token so each buyer sees their own price
- Edge caching for catalog metadata, kept separate from per-buyer pricing so nothing leaks
- The result reads as live to the buyer while sparing the ERP from storefront-rate traffic
Error handling when the ERP is unreachable
- The storefront keeps serving from its last good synced state, it does not go dark
- Orders queued with idempotency keys and posted when the ERP returns, never silently lost
- Circuit breakers and backoff so a slow ERP cannot cascade into a slow storefront
- Credit and ATP fall back to conservative rules when a live check cannot complete
- Clear operator alerting so a stalled bridge is a page, not a customer complaint
Observability & ops
- Shared correlation IDs from storefront to middleware to ERP for end-to-end tracing
- Centralized sync monitoring: queue depth, lag per flow, and last-successful-sync timestamps
- Synthetic checks on price, stock, checkout, and order post-back against staging
- Runbooks and paging for the bridge so commerce never silently degrades
- Reconciliation reports that flag drift between BigCommerce and the ERP before buyers do
ERPs we integrate with BigCommerce.
Each ERP exposes its data differently, so the integration design changes even when the BigCommerce side stays the same. Here is how we approach the systems we see most.
SAP S/4HANA & Business One
- S/4HANA pricing condition types, sales-area assignment, and ATP mapped into BigCommerce price lists and stock
- Business One for mid-market distributors, with item master and business-partner pricing flows
- Credit management read so blocked orders never reach checkout
- SAP-aware tax through
AvalaraorVertexrather than rebuilt in the storefront
Microsoft Dynamics 365
- Business Central for mid-market: customer-pricing groups, dimensions, and sales-order post-back
- Finance and Operations for enterprise: trade agreements, legal entities, and warehouse-aware ATP
- Legacy
NAVandGPsupported where the upgrade has not happened yet - Multi-company tenants exposed as one or many BigCommerce storefronts
NetSuite
- SuiteTalk and RESTlet integration for items, customers, pricing, and sales orders
- Customer-specific and quantity-based pricing mapped to BigCommerce price lists
- Multi-subsidiary and multi-currency handled per storefront
- Inventory and fulfillment status synced back into the buyer's account view
Acumatica
- Contract-based REST API for items, inventory, customers, and orders
- Customer price classes and special pricing mapped into price lists and groups
- Warehouse and lot/serial awareness reflected at the PDP where relevant
- Branch and entity separation modeled across storefronts as needed
Deliverables.
We scope the data flows, build the integration, and hand over something your team can operate. Want the storefront work alongside it? See our BigCommerce builds and portfolio.
BigCommerce ERP integration, answered.
Can BigCommerce show real-time ERP pricing?
BigCommerce does not read your ERP live the way Sana Commerce does. The platform serves pricing from its own catalog and price lists, so the honest answer is near real-time, not live. You get a real-time feel by mapping customer-specific contract pricing into BigCommerce price lists and customer groups, surfacing it through the GraphQL Storefront API with a customer token, and keeping it fresh with event-driven syncs and short cache windows. For genuinely live reads of every price at the moment of view, Sana Commerce Cloud is the architecture built for that.
How does BigCommerce connect to SAP, Dynamics, or NetSuite?
Through middleware. BigCommerce exposes Catalog, Pricing, Customers, and Orders through its REST Admin and GraphQL APIs plus webhooks, and an integration layer maps those to your ERP. That layer can be an iPaaS connector such as Celigo, Boomi, Jitterbit, or MuleSoft, or a packaged connector for SAP S/4HANA and Business One, Dynamics 365 Business Central and Finance and Operations, NetSuite, or Acumatica. Catalog and pricing flow from the ERP into BigCommerce, while orders, customers, and payment status flow back. We design the field mapping, the sync triggers, and the failure handling.
Should we use middleware or a custom integration?
It depends on how standard your data is. A pre-built iPaaS connector is faster and cheaper when your catalog, pricing, and order flows match the connector's assumptions. A custom integration earns its cost when you have unusual pricing logic, multi-ERP or multi-entity setups, strict latency targets, or back-office workflows the connector cannot model. We often do both: an iPaaS backbone for the common entities and targeted custom services for the parts that do not fit.
How is this different from Sana's live ERP read?
Sana Commerce Cloud makes the storefront a client of the ERP, so pricing, stock, credit, and order status are read from SAP or Dynamics at the moment of view with no separate copy. BigCommerce keeps its own catalog and syncs the ERP into it, so you own the sync and its edge cases but gain storefront flexibility, a large app ecosystem, and a blended B2B and B2C model. Neither is universally right. We build both and recommend per project. Read the full Sana Commerce vs BigCommerce breakdown.
Ready to wire BigCommerce into your ERP?
Tell us your ERP, your pricing model, and how live your stock needs to be. We will map the flows and give you a straight plan, including when the platform's near real-time model is enough and when it is not.
877.609.9029