BigCommerce Sage integration, for the Sage you actually run.

ProjectThunder integrates BigCommerce with Sage for B2B companies. ProjectThunder is a California B2B ecommerce studio, founded in 2004 and a BigCommerce Partner, that builds Stencil and Catalyst storefronts, sets up B2B Edition and integrates BigCommerce with SAP, Microsoft Dynamics and Sage. On Sage 100, 300, X3, Intacct, 50 and 200 it connects customers and terms, customer pricing, stock by warehouse, orders, shipments and invoices, through the API or connector each product supports, while your Sage partner runs the ERP.

The studio has launched 150 B2B storefronts across ERPs, its median client relationship is 10 years, and everyone works California hours, developers included.

Sage sells several ERP and accounting products under one name, and they share very little underneath. Each has its own data model, its own pricing and its own way in, so a BigCommerce Sage integration is scoped product by product. This is how each one is reached, from Sage’s own developer documentation.

Not sure which Sage or which version you run? Your Sage partner will know, and it is the first thing we ask.

Whichever Sage you run, a B2B storefront asks it the same six questions. Getting them right is most of the project.

1. Customers and terms. Each BigCommerce company or buyer maps to a Sage customer number, with its bill-to and ship-to addresses, payment terms, tax status and credit limit. Decide which system creates new customers, and how a new web account gets its Sage number.
2. Price levels and customer pricing. Sage 100 prices through price codes, customer price levels and customer-specific pricing, Sage 300 through price list codes and contract pricing, and X3 through configurable price lists. Simple price levels map to BigCommerce price lists and customer groups and can be synced. Customer-specific and quantity pricing is where copies drift, so ask Sage for the price where its API allows it, or resolve the rules the way Sage does, and test against your hardest pricing customers.
3. Stock by warehouse. Sage 100, 300, X3, Intacct and 200 keep quantities per warehouse or location, with on hand, committed and on order tracked separately. Sage 50 US does not track stock by warehouse without an add-on. Decide which warehouses serve the store and show available stock, not total on hand across every location.
4. Orders written back. The web order becomes a Sage sales order for the right customer and ship-to address, with tax, freight and payment handled, and the store keeps the Sage order number. An idempotency key on submission stops a retry from creating two orders.
5. Shipments. When Sage ships the order, the shipped quantities, carrier and tracking number come back to BigCommerce and the order status moves on, partial shipments and backorders included.
6. Invoices. Open invoices, balances and invoice history from Sage, shown in the buyer’s account so they can find and pay what they owe without calling. B2B Edition’s invoice portal can be fed from Sage.

Shipments and invoices are the two most often left out of scope, and they are what stops buyers calling to ask where an order is or what they owe.

The BigCommerce App Marketplace lists connectors for some Sage products. What their own listings describe:

• IN-SYNCH for Sage 100, from DSD Business Systems. Products, inventory quantities and pricing, including standard, group and customer-specific prices, to BigCommerce; orders and customers to Sage 100; tracking and order status back to the store. The listing also names B2B Edition options for Sage order history, price lists and company contacts.
• Commercient SYNC for Sage 50 US. Customers, orders with status and tracking, products and pricing, and inventory, one way or both ways, on a schedule you set rather than live.
• Sage cloud connector by CarryTheOne. Its listing says it supports cloud versions of Sage only. It posts BigCommerce orders to Sage as accounts receivable invoices, along with customers, items, tax and payments.

The IN-SYNCH and Commercient listings note that the app may not be fully compatible with multi-storefront. For the other Sage products, look at iPaaS platforms, connectors your Sage partner supports, or custom code against the APIs above. These summaries come from the vendors’ listings as of November 2026, so confirm current coverage with the vendor.

Before you buy, ask any connector vendor about customer-specific and quantity pricing, credit position and B2B Edition company accounts. When those matter, a hybrid often fits: a connector for catalog, stock and orders, and a small custom layer for pricing and the account portal. A fully custom build makes sense when pricing, approvals or your Sage customizations are central to how you sell.

• Customer pricing was flattened. The price levels synced, the customer-specific prices and quantity breaks did not, and the customers with negotiated prices are the ones who notice.
• The wrong stock figure. On hand synced instead of available, or every warehouse added together, so the store promises what it cannot ship.
• Orders duplicate. No idempotency key, so a retry or a double click creates two sales orders.
• Customer numbers drift. A web account is created twice, or ships to an address that is not a Sage ship-to, and orders land on the wrong account.
• The on-site service stops. On Sage 100 and Sage 50 the integration runs beside Sage on your network, and it stops quietly when that machine restarts, moves or is replaced. Monitor it like any other system you depend on.
• Scheduled sync shows old numbers. A sync every few hours suits the catalog and is slow for stock, so a fast-moving item sells out in Sage while the store still offers it.
• Web Services were not budgeted. On Intacct the integration needs a Web Services subscription and sender ID, and finding that out at go-live delays the launch.
• An upgrade changes the ground. A Sage upgrade changes a field, a screen or an API version the integration relied on. Test the integration in a test company or sandbox before each upgrade.

Each of these is cheaper to design out than to find in production, and each is easier to diagnose when the integration logs what Sage returned.

Every ProjectThunder project starts with 50 to 100 hours of planning at $100 an hour: which Sage and version you run, which API or connector each flow uses, how your pricing is set up and what the six contracts look like. We agree the scope and the cost together before the build. The build then runs at $185 an hour, or $165 an hour prepaid on 7-day terms, with four layers of testing before launch, and a 20 to 50 hour monthly retainer after it. We integrate Sage; your Sage partner implements, supports or moves the ERP. The detail is on our process page.