Sage 50 and BigCommerce integration

What moves between them

Orders and customers move from BigCommerce into Sage 50. ml-connector reads paid BigCommerce orders and writes them into Sage 50 as sales invoices, creating or matching the customer record first, and posts the captured payment as a customer receipt. Inventory moves the other direction: Sage 50 inventory counts are pushed up to the matching BigCommerce catalog products so the store reflects what is in stock. Order line items map to Sage inventory items by SKU. Refunds recorded in BigCommerce are read and applied against the corresponding Sage invoice. The cadence is a scheduled poll, since Sage 50 cannot be triggered by an external event.

How ml-connector handles it

ml-connector stores both credential sets encrypted. The BigCommerce side uses the store hash and access token in the X-Auth-Token header; the Sage side hands the company data folder path, user name, and password to the local agent, which opens the company file through the SDK. Because Sage 50 is pull-only and locks the company file to one session, the agent polls BigCommerce orders, customers, and refunds on a schedule, typically every few minutes, rather than waiting on a push, and it must not run while a person is logged into Sage interactively under the same user. BigCommerce webhooks can shorten the lag by signaling that an order changed, but since the payload is only a type and ID, ml-connector still calls the BigCommerce REST API to fetch the full order before handing it to the agent. Customers are matched by email and orders by order number so the same storefront order is never invoiced twice, which matters because Sage has no idempotency key. Inventory writes go to the BigCommerce variant or product by SKU. BigCommerce rate limits return HTTP 429, so ml-connector reads the reset header and backs off, and the local agent reconnects when the company file is briefly locked. Every record carries a full audit trail and can be replayed if a downstream step fails.

A real-world example

A home and garden retailer with around forty staff sells through a BigCommerce store and keeps its books in Sage 50 US on a back-office Windows PC. Before the integration, a bookkeeper exported the day's online orders to a spreadsheet each morning and re-keyed every invoice, customer, and payment into Sage 50, then manually adjusted stock counts in BigCommerce whenever a warehouse count changed. With Sage 50 and BigCommerce connected, paid orders post into Sage as invoices and receipts on a short poll, new shoppers become Sage customers automatically, and the stock counts Sage tracks flow back to the storefront. The morning re-keying is gone and the books match the store.

What you can do

• •Turn paid BigCommerce orders into Sage 50 sales invoices and post the payment as a customer receipt.
• •Create or match Sage 50 customer records from BigCommerce shoppers by email.
• •Push Sage 50 inventory counts to the BigCommerce catalog so the store shows current stock.
• •Read BigCommerce refunds and apply them against the matching Sage 50 invoice.
• •Run a local Sage agent that polls BigCommerce on a schedule, with retries and a full audit trail on every record.

Questions

Why does Sage 50 need a local agent instead of a cloud connection?

Sage 50 is desktop accounting software with no cloud REST API and no webhooks, so there is nothing to call over the internet. ml-connector runs a small agent on the same Windows machine as Sage 50, using the .NET SDK on the US edition or Sage Data Objects on the UK edition. The agent reads and writes the company file locally and syncs to BigCommerce over HTTPS.

How are BigCommerce orders kept from being invoiced twice in Sage 50?

Sage 50 has no idempotency key, so ml-connector matches on stable references before it writes. Customers are matched by email and orders by their BigCommerce order number against the Sage invoice already created from them. If a match exists, the record is updated rather than duplicated.

Does the integration use BigCommerce webhooks or polling?

It uses polling as the backbone because Sage 50 cannot be triggered by an outside event and only one process can open the company file at a time. BigCommerce webhooks can be added to signal that an order changed sooner, but the webhook payload carries only a resource type and ID, so ml-connector still calls the BigCommerce REST API to fetch the full order before the agent writes it into Sage 50.