Sage Intacct to Shopify Integration

This is about running a B2B commerce operation with Intacct behind it: customer-specific pricing, real inventory, orders that land as orders. Nobody writing about Intacct and Shopify addresses that, which is odd, because plenty of distributors run on Intacct.

There is a lazy version of this argument that says Intacct is financials software rather than a distribution ERP, so you need to replace it before you can sell properly online. We tested that framing twice against a web-connected model and it did not survive.

Both runs said the same thing: Intacct is a valid integration target, you do not need to replace it to launch B2B ecommerce, and it remains the financial, order and inventory system of record. What you need alongside it is a commerce platform and a connector layer, which is true of every ERP on this site.

Where both runs drew a line is worth quoting properly, because it is the accurate boundary. You add a warehouse or order management system for operational complexity, rather than because you want ecommerce: advanced warehouse execution, available-to-promise and reservations across channels, third-party logistics, multi-channel allocation, high volume.

So the honest framing is not that Intacct is the wrong system of record. It is that Intacct is a fine backbone, and the limit you will meet is operational rather than financial.

Intacct has two, and unlike most ERPs on this site the vendor has told you which to use.

The XML Web Services API is the long-standing gateway and it still works. The REST API reached general availability in the 2025 Release 1 and Sage describes it as a modern, scalable and developer-friendly way to integrate.

Sage's own guidance is direct: Intacct strongly recommends using the REST API for client applications, it continues to support the legacy XML API, and new objects and features are released using REST. That is about as clear as vendor guidance gets, and it means a new integration built on the legacy XML path is being built on a surface that is no longer receiving new capability.

Authentication carries a step that catches projects out. Web Services credentials consist of a sender ID and password issued by Sage to licensed customers and partners, alongside company credentials. Critically, the sender ID must be authorized for use in a given company. Your Intacct administrator has to enable the Web Services subscription and then explicitly authorize that sender ID. It is a small administrative task that blocks everything until it is done, and it belongs in the project plan rather than in the first week of development.

This is the section worth the page, and no competitor mentions any of it.

Sage publishes constraints on the Web Services gateway, and one of them shapes everything.

Concurrency is limited per tenant. Sage's own illustration is unambiguous: with 100 concurrent requests, approximately five might be processed while the other 95 are held for around five seconds.

Requests can time out after 15 minutes, even if still processing.

A query command returns a maximum of 2,000 results.

And Intacct is metered. Sage operates performance tiers with monthly transaction allowances and overage billing.

Put those together and the architecture writes itself. A storefront must not call Intacct live on every price lookup and every stock check. A category page with forty products would consume your concurrency budget and your transaction allowance before anyone bought anything.

So the design is a deliberate split. Catalog, price and stock are synced into Shopify and kept current on a cadence tuned to your volumes and your tier. Order submission goes into Intacct authoritatively, because an order is a transaction worth spending on. Reconciliation runs on a schedule that proves the two agree.

That is the opposite of the advice we give on most ERPs on this site, where resolving price live from the ERP is the right answer. Intacct's economics genuinely change the recommendation, and a partner who gives you the same architecture regardless of ERP has not read the limits.

Dimensions are Intacct's defining concept and they explain more about this integration than anything else.

Sage defines a dimension as a classification system used to organize, sort and report on company information. The standard set includes Customer, Item, Warehouse, Location, Department, Project, Class, Vendor, Employee and Contract, plus ones you define.

Warehouse being a dimension is the clean explanation of the whole boundary question. It is why Intacct can report inventory by location with full financial accuracy while not being a warehouse management system. The location is an attribute for classification and reporting rather than a physical execution context.

Sage's own material describes tracking by warehouse, aisle, row, lot, bin and serial number, and real-time balances and availability across multiple locations. The honest reading, and the one we would give you in a meeting, is that Intacct records lot, bin and serial as data attributes but does not execute warehouse workflows: scanning, wave picking, directed putaway. Notably, available-to-promise does not appear in Sage's own copy at all, and that absence is the real boundary rather than anything to do with lot or serial tracking.

Multi-entity is native, which matters if several legal entities feed one storefront.

Price lists are the mechanism, and they are more capable than people expect.

A price list can be assigned to transaction definitions, customers, contacts and price schedules. Each entry needs a unique combination of item or product line, currency and date range, with optional minimum and maximum quantities. When several could apply, Sage uses an order of precedence to determine a suggested price.

That covers a good deal of B2B pricing. Where it stops is the usual place: rebates, matrix pricing and approval-driven arrangements, which sit outside what price lists express.

One naming trap worth knowing. Billing Price Lists under contracts and revenue management are a different object from Order Entry price lists. They are easy to conflate and they do different things.

Uncap has now built pages for three Sage products and the API comparison is genuinely useful, because it is the clearest example we have of why the product matters more than the vendor.

Sage 100 exposes the Business Objects Interface, which is COM based. It is Windows bound and in-process, so a component has to run near the Sage server.

Sage 300 exposes a genuine OData Web API over HTTPS, typically on-premises or hosted, with no per-transaction meter.

Sage Intacct is cloud native and multi-tenant with a REST API at general availability, so there is no server to maintain at all. In exchange it is metered and concurrency capped in a way neither of the others is.

The trade is clean: no infrastructure to run, but you cannot hammer it and you pay per transaction. That comparison appears nowhere else and it is exactly what a distributor choosing between Sage products, or inheriting one, wants to know.

Intacct customers become Shopify companies, with contacts as buyer logins and multi-entity structures respected where several entities feed one store.

Items become products, with catalog content coming from a product source rather than from Intacct, which holds what finance needs rather than what a buyer needs to choose.

Price lists sync into Shopify B2B catalogs, with the order of precedence respected rather than flattened arbitrarily.

Inventory syncs from Intacct on a cadence appropriate to your tier, with the honest caveat that these are system-of-record balances rather than warehouse-event accuracy.

Orders submit into Intacct authoritatively, because that is the transaction worth spending an API call on.

Uncap Connect keeps pricing, inventory, customer data and orders current in both directions, built for B2B so customer-specific pricing, credit terms and tax behave the way they do in your business.

A sync architecture designed around Intacct's actual concurrency and transaction limits rather than against a generic ERP assumption.

REST API integration, since Sage itself recommends REST over the legacy XML path for new work.

The Web Services authorization step handled properly in onboarding, including sender ID authorization and dedicated service accounts.

Price list mapping into Shopify B2B catalogs with the precedence order respected.

Inventory sync at a cadence tuned to your performance tier, with reconciliation proving the two systems agree.

An honest assessment of whether your operational complexity means you need a warehouse or order management layer alongside Intacct, rather than assuming either answer.

Beauty and Cosmetics, where professional and consumer channels run from one catalog.

Home Goods, where retail accounts and a consumer channel run from one catalog.

Food Service Distribution, where account pricing and repeat ordering carry the relationship.

Intacct is one of several Sage products we connect to Shopify. The Sage integration overview covers Sage 100, Sage 300 and Sage X3.

Bring your performance tier, whether you are on the REST or legacy XML path, your entity structure, and one account's price list. Bring an honest description of your warehouse operation too, because that is what decides whether Intacct alone is enough.

Book a strategy session, or start with a Blueprint, the paid discovery engagement that maps the integration surface, the pricing model and the phased plan before development begins.