Sage 100 (the ERP many distributors and manufacturers still call by its old name, MAS 90 or MAS 200) is one of the most common systems we integrate with a B2B storefront, and one of the most misunderstood. The integration that works for a cloud ERP with a modern REST API does not work for Sage 100, because Sage 100 was not built that way. This page is about the real mechanics: how Sage 100 actually exposes its data, which parts are safe to sync live and which must be batched, and what a Magento or Shopware integration with Sage 100 actually involves for a mid-market distributor.
If you want the general picture across every Sage product, start with our Magento Sage integration guide. This page goes deep on Sage 100 specifically, because the integration decisions here are genuinely different from Sage 300 or Sage X3.
First, which Sage 100 do you actually run?
This is the question that changes the entire integration, and it is the first one an honest partner asks. Sage 100 ships in flavors that store data completely differently:
- Sage 100 Standard runs on the ProvideX database, a file-based data layer with roots going back to the MAS 90 era. Access is through the ProvideX ODBC driver, which is read-capable but slow under load and was never designed to answer storefront traffic. Writes go through the Business Object Interface, not through SQL.
- Sage 100 Advanced is the same application over a client-server ProvideX runtime. Same data model, better concurrency, same ODBC and Business Object realities for integration purposes.
- Sage 100 Premium runs on Microsoft SQL Server. This is the one flavor where you get real SQL access to the data, which changes what a fast, near-live read layer can look like.
So before anyone quotes a Sage 100 integration, they need to know your flavor. A Premium-on-SQL integration and a Standard-on-ProvideX integration are different projects with different performance ceilings. Anyone who quotes without asking has not done one.
How Sage 100 actually exposes its data (and why it matters)
Two mechanisms carry almost every Sage 100 integration, and understanding them is the difference between a storefront that stays correct and one that generates a support ticket every morning:
Reads: ODBC or SQL
Pricing, inventory, customers, and order history are read out of Sage 100. On Standard and Advanced that means the ProvideX ODBC driver, which is functional but not fast, so the durable design never points the storefront directly at it for every page view. Instead a scheduled sync pulls pricing and availability into a fast local mirror that the storefront reads from, and the mirror refreshes on a cycle the ProvideX layer can sustain. On Premium you have SQL Server, so the mirror can refresh more aggressively, but the pattern is the same: read into a mirror, serve from the mirror.
Writes: the Business Object Interface
Orders do not get written to Sage 100 with a raw SQL insert. They go through the Sage 100 Business Object Interface (the BOI), a COM-based layer that enforces the same validation the Sage 100 order-entry screen does: valid customer, valid items, correct pricing, credit rules. That is a good thing, because it keeps bad orders out of your ERP, but it means the write path is a controlled, one-at-a-time posting through the BOI, not a bulk dump. So a working Sage 100 integration queues web orders and posts them through the BOI in a managed sequence, with error handling per order, so one bad order does not stall the rest.
The integration pattern that works for Sage 100
Put the two mechanisms together and the durable architecture for a Sage 100 storefront looks like this:
- Pricing and inventory sync into a mirror. A scheduled job reads customer-specific pricing, price levels, and item availability out of Sage 100 into a fast store the site reads from. Frequency is tuned to what your data layer can sustain: more often on Premium/SQL, more conservatively on ProvideX.
- Customers and catalog provision from Sage 100. Customer records, price levels, and item data originate in Sage 100 and flow to the storefront, so the sales and finance teams keep managing them where they always have, and the site stays in sync instead of drifting.
- Orders queue and post through the BOI. A web order is captured by the storefront, written to a queue, and posted into Sage 100 order entry through the Business Object Interface with full validation, then its status flows back to the buyer.
- Everything has error handling and visibility. Every sync and every posting is logged, failures are isolated per record, and operations can see what failed and why. This is the part cheap integrations skip, and it is the part that decides whether the system runs for years.
The Sage 100 specifics that catch integrations out
These are the details that separate a partner who has integrated Sage 100 from one who is about to learn on your project:
- User-defined fields. Most real Sage 100 installations carry UDFs added over years: a customer flag, an item attribute, a special-pricing marker. If the integration ignores them, it misses business logic that lives in those fields. They have to be discovered and mapped, not assumed away.
- Batch posting cycles. Sage 100 posts in batches (sales journals, inventory updates), and the timing of those cycles constrains when the storefront’s view of inventory and invoices is actually current. The integration has to respect the posting rhythm rather than assume real-time truth.
- Kit and bill-of-materials items. Distributors and light manufacturers on Sage 100 sell kits and assemblies. How a kit’s components, availability, and pricing surface on the storefront is a real modeling decision, not a checkbox.
- Multi-warehouse availability. The Inventory Management module tracks stock by warehouse. A buyer deciding between will-call and delivery needs warehouse-level availability, which means the sync has to carry it, not flatten it to a single number.
- Customer price levels and special pricing. Sage 100 pricing is customer-price-level plus item-level special pricing plus quantity breaks. Reproducing that correctly on the storefront, per logged-in customer, is the single most important part of the build and the most common place cheap connectors get it wrong.
Is Sage 100 the right fit for a B2B storefront, honestly?
Sage 100 runs a lot of solid mid-market distributors and manufacturers, and it integrates with a real B2B storefront perfectly well when the integration respects how it works. The honest caveats: if you are on Standard/ProvideX with a very large catalog and high traffic, the read layer needs careful design and you should expect the mirror-and-sync architecture rather than any fantasy of live ERP calls. If you are on Premium/SQL, you have more headroom. And if your operation has genuinely outgrown Sage 100, that is a conversation worth having before you build, not after. We would rather tell you that up front than sell you an integration on a platform you are about to leave.
For distributors weighing the storefront platform itself, our Magento B2B development guide and our Shopware work cover the choice; the Sage 100 integration layer is built the same way underneath either.
What a Sage 100 storefront changes
The payoff is operational before it is commercial, and for a Sage 100 distributor it is concentrated in the same places:
| What changes | Why | Direction |
|---|---|---|
| Order-entry labor | Orders customers place themselves through quick order and saved lists are orders your team no longer keys into Sage 100 | Down, in proportion to how much was phoned or faxed |
| Order accuracy | Web orders post through the BOI with validated items and pricing instead of being retyped from a message | Fewer credits and reships |
| Counter and CSR load | Self-service invoice lookup and reorder removes routine calls | Freed for real selling |
| Average order value | A buyer browsing the full, correctly priced catalog adds lines a phone order never would | Up, compounding with adoption |
How much each moves depends on how much of your Sage 100 order volume is routine reorder traffic today, which is exactly what an honest scoping conversation establishes before modeling a return.
Who builds this
Web Solutions NYC builds B2B commerce for distributors and manufacturers, with the ERP integration that makes it actually work. We have done this since 2007, with senior engineers in US time zones and deep experience across Epicor Prophet 21, Sage, SAP Business One, Microsoft Dynamics 365 Business Central, and Acumatica. We build on both Adobe Commerce (Magento) and Shopware, so the recommendation follows your requirements rather than our inventory. We are a Shopware Platinum Partner and an official Adobe Commerce partner.
Bring your Sage 100 details, leave with a real answer
If you are weighing a storefront on Sage 100, the three facts that decide the project are: which flavor you run (Standard, Advanced, or Premium), how your pricing is structured (price levels, special pricing, quantity breaks), and how orders reach you today. With those, we can tell you what the integration really involves, including whether a packaged connector covers you or where you will need a real build. Book a Sage Scoping Session
Frequently asked questions
Pricing and availability can be served near real time, but not by pointing the storefront directly at Sage 100 for every request. On Sage 100 Standard and Advanced the data lives in the ProvideX database, read through an ODBC driver that was not built for storefront traffic, so the durable pattern syncs pricing and inventory into a fast local mirror on a schedule and serves the site from the mirror. On Sage 100 Premium, which runs on SQL Server, the mirror can refresh more aggressively. Orders are written back to Sage 100 through the Business Object Interface in a managed queue, not a bulk insert.
Standard and Advanced store data in the ProvideX database and are integrated through the ProvideX ODBC driver for reads and the Business Object Interface for writes. Premium runs on Microsoft SQL Server, which gives real SQL access to the data and a higher performance ceiling for the read layer. The flavor you run changes the integration architecture and its performance headroom, so it is the first thing to establish before scoping a Sage 100 storefront project.
Sage 100 pricing combines customer price levels, item-level special pricing, and quantity breaks. A correct integration resolves each logged-in customer to their Sage 100 customer record and reproduces that pricing logic exactly, syncing it into the storefront so the buyer always sees their real price. Getting this right, per customer, is the most important part of the build and the most common place packaged connectors fall short, because distribution pricing is rarely as simple as a single price list.
Sage 100 exposes the Business Object Interface, a COM-based layer that enforces the same validation as the order-entry screen, which is the correct path for writing orders back. For reads it relies on ODBC (ProvideX) or SQL on Premium. It does not offer a modern REST API on the Standard product the way a cloud ERP would, which is why a Sage 100 integration is architected around a sync-and-mirror read layer plus a queued Business Object write path rather than live REST calls.
A packaged connector can work when your pricing and catalog are straightforward. Sage 100 distributors often are not straightforward: user-defined fields carrying business logic, kit and bill-of-materials items, multi-warehouse availability, and layered special pricing are exactly where packaged connectors run out. The honest test is your pricing complexity and how much custom logic lives in your Sage 100 setup. We build the integration where a connector cannot cover you, and we will tell you if a connector honestly would.