Which direction does data move between Sage Intacct and BigCommerce?

The main flow is BigCommerce into Sage Intacct. Order transactions and refunds move from BigCommerce into Intacct's general ledger and accounts receivable, while GL account mappings and customer dimensions are configured once and reused on every order. Intacct does not push data back into BigCommerce.

How does the integration handle BigCommerce's webhook stub payloads and Intacct's XML gateway?

When BigCommerce sends a webhook containing only an order ID and type, ml-connector immediately calls the BigCommerce REST API to fetch the full order, transaction, and refund details. It then constructs an Intacct XML message with all required fields and sends it to the single gateway endpoint, parsing the HTTP 200 response for application-level errors inside the XML body rather than assuming success.

What happens when Intacct session tokens expire or BigCommerce webhooks are auto-deactivated?

Intacct session tokens are cached for 50 minutes and automatically refreshed on the next gateway call if they have expired. BigCommerce webhooks are monitored for delivery failures, and ml-connector will re-register a webhook if it detects that the original has been auto-deactivated after 90 days of inactivity or 48 hours of failed retries.

Sage IntacctBigCommerce

Sage Intacct and BigCommerce integration

BigCommerce runs your online store. Sage Intacct runs your accounting. Connecting them keeps order revenue flowing into your general ledger automatically, with no manual re-entry of sales totals. Order line items become billable transactions in Intacct, refunds post to the correct GL accounts, and your AR and revenue accounts stay in sync with e-commerce activity. ml-connector handles the very different API styles on each side and moves the order data on a webhook schedule that BigCommerce controls.

How Sage Intacct works

Sage Intacct is a cloud-based ERP and accounting system that exposes vendors, payable bills, GL accounts, and accounting dimensions through a single XML gateway endpoint at https://api.intacct.com/ia/xml/xmlgw.phtml. Authentication uses session-based credentials with a senderId, senderPassword, companyId, userId, and userPassword; an initial getAPISession call exchanges partner and user credentials for a sessionid that is cached for 50 minutes and automatically refreshed. The gateway requires all operations to serialize through one POST connection and returns HTTP 200 responses that may contain application-level errors inside the XML body, so responses must be parsed for errormessage tags. Sage Intacct does not push webhooks, so all data flows are scheduler-driven or manual-run.

How BigCommerce works

BigCommerce is a cloud e-commerce platform that exposes orders, transactions, refunds, customers, and products through a REST API at https://api.bigcommerce.com/stores/{store_hash}/v3/. Authentication uses a static API key via the X-Auth-Token header, generated in the store control panel at Settings > API Accounts > Store-level API accounts. BigCommerce also supports webhooks via HTTP POST to an HTTPS endpoint, with events including store/order/created, store/order/updated, store/order/statusUpdated, and store/refund. Webhook payloads contain stub data only (type and ID), so the full details must be fetched immediately via the REST API. Webhooks are auto-deactivated after 90 days of inactivity or 48 hours of delivery failures, and the retry schedule includes 11 retries over approximately 48 hours with increasing backoff.

What moves between them

The main flow runs from BigCommerce into Sage Intacct. When orders are created or updated in BigCommerce, ml-connector receives the webhook, fetches the full order and transaction details via the REST API, and maps the order total and line items into Intacct as a payable bill or revenue journal entry against the configured GL accounts. Refunds and partial payments are posted separately to maintain accurate AR and revenue recognition. Reference data such as GL account mappings and customer dimensions are configured once and reused on every order.

How ml-connector handles it

ml-connector stores the BigCommerce API key encrypted and registers an HTTPS webhook endpoint in BigCommerce to receive store/order/created, store/order/updated, and refund events. When a webhook arrives, ml-connector extracts the order ID from the stub payload and immediately calls the BigCommerce REST API to fetch full order and transaction details. It then opens an Intacct session using the stored credentials, refreshing the session token if it has expired after 50 minutes, and maps the order line items and totals to the configured GL accounts and customer dimension. The transaction is sent via the Intacct XML gateway and the response is parsed for application-level errors or success confirmation. Refunds are processed sequentially to avoid conflicts. Rate limits on the BigCommerce API (450 per 30 seconds on Pro, 150 on Standard) are respected with backoff, and every record carries a full audit trail so failed orders can be inspected and replayed once the root cause is fixed.

A real-world example

A mid-sized e-commerce retailer sells home goods through BigCommerce and manages accounting in Sage Intacct. Before the integration, the finance team exported BigCommerce orders every day and manually entered the daily totals into Intacct as a revenue journal, then spent hours matching transaction IDs to reconcile discrepancies at month-end close. With BigCommerce and Intacct connected, each order posts to revenue automatically the moment it is completed, allocated to the correct GL account by product category, and refunds reverse the revenue on the same account. Month-end close starts with revenue accounts already reconciled, and the manual export-and-entry step is gone.

What you can do

Post BigCommerce order transactions into Sage Intacct's general ledger on webhook, allocated to the correct revenue GL accounts and customer dimensions.
Map order line items to product-category-based GL accounts so revenue lands on the right account for each sales channel.
Handle BigCommerce webhook auto-deactivation by monitoring delivery failures and re-registering webhooks before they expire.
Refresh Intacct session tokens automatically when they expire after 50 minutes so order posting never stalls mid-transaction.
Parse Intacct XML responses for application-level errors and replay failed orders into the GL once the root cause is fixed.

Questions

Which direction does data move between Sage Intacct and BigCommerce?: The main flow is BigCommerce into Sage Intacct. Order transactions and refunds move from BigCommerce into Intacct's general ledger and accounts receivable, while GL account mappings and customer dimensions are configured once and reused on every order. Intacct does not push data back into BigCommerce.
How does the integration handle BigCommerce's webhook stub payloads and Intacct's XML gateway?: When BigCommerce sends a webhook containing only an order ID and type, ml-connector immediately calls the BigCommerce REST API to fetch the full order, transaction, and refund details. It then constructs an Intacct XML message with all required fields and sends it to the single gateway endpoint, parsing the HTTP 200 response for application-level errors inside the XML body rather than assuming success.
What happens when Intacct session tokens expire or BigCommerce webhooks are auto-deactivated?: Intacct session tokens are cached for 50 minutes and automatically refreshed on the next gateway call if they have expired. BigCommerce webhooks are monitored for delivery failures, and ml-connector will re-register a webhook if it detects that the original has been auto-deactivated after 90 days of inactivity or 48 hours of failed retries.

Connect Sage Intacct and BigCommerce

Free to use. Add your credentials, ping your real systems, and see if we fit.

Get started