SAP Business One runs a particular kind of company: mid-market distributors and manufacturers, often with international operations, multi-currency books, and more process rigor than their size would suggest, because they chose SAP. Connecting Business One to a B2B storefront is very doable, and unlike some older ERPs it has a genuinely modern integration path. But the details of how Business One models pricing, partners, and inventory decide whether the integration is clean or a constant fight. This is the real picture, from the implementer side.
This is the hub for Business One specifically. For the broader distribution-ERP picture see our Magento B2B development guide; the integration layer below is built the same way whether the storefront is Magento or Shopware.
The good news: Business One has a real API
Unlike some distribution ERPs where you are reading a file-based database through a slow driver, Business One gives you a modern way in. Which one you use depends on your database and version:
- The Service Layer is Business One’s modern REST/OData interface, available on the SAP HANA edition. It is the right integration path for a new storefront project: standards-based, well-documented, and capable of both reads and writes without a COM bridge. If you are on Business One for HANA, this is what a good integration is built on.
- The DI API and DI Server are the older Data Interface layer, COM-based, used on the Microsoft SQL Server edition and still common in the field. They work, and they enforce Business One’s business rules on writes, but they are heavier to operate than the Service Layer and constrain how the integration is architected.
So the first scoping question for a Business One storefront is simple: HANA or SQL Server, and which version? On HANA with the Service Layer you can design a cleaner, more real-time integration. On SQL with the DI API the pattern leans more on scheduled sync. Either works; the architecture differs, and an honest partner establishes this before quoting.
Where Business One integrations actually get hard: pricing and partners
The API is the easy part. The reason Business One integrations succeed or fail is how faithfully they reproduce its pricing and business-partner model on the storefront:
The price-list and special-price model
Business One prices through a hierarchy: base price lists, then special prices per business partner, then period and volume discounts, then discount groups. A given customer’s real price for a given item is the resolved output of that stack, and it changes as the sales and finance teams maintain it in Business One. The storefront cannot own this pricing; it has to resolve each logged-in customer to their business-partner record and reproduce their price exactly, or mirror it and keep it current. Getting this right, per partner, is the core of the build.
Business partners, not just customers
Business One models the customer as a business partner with ship-to and bill-to addresses, contacts, payment terms, and credit limits. A real integration maps storefront logins to the right business partner (and often the right contact within it), so pricing, terms, and order history all resolve correctly and one partner never sees another’s data. Multi-contact, multi-ship-to accounts are the norm in distribution, not the exception.
User-defined fields and tables
Business One installations lean heavily on user-defined fields and user-defined tables. Years of customization live in UDFs and UDTs: a partner attribute, an item flag, a custom pricing input, an entire auxiliary table. An integration that ignores them misses business logic that is genuinely load-bearing. They have to be discovered and mapped, which is exactly the kind of thing a partner who has done Business One knows to look for and a generalist does not.
The integration pattern that works for Business One
- Pricing and inventory resolve from Business One. On HANA/Service Layer this can be near real time; on SQL/DI API it is a tuned scheduled sync into a fast read layer the storefront serves from. Either way the customer sees their resolved price and accurate, warehouse-level availability.
- Business partners and catalog provision from Business One. Partners, price lists, and items originate in the ERP and flow to the storefront, so the teams keep managing them where they always have and the site stays in sync.
- Orders write back through the Service Layer or DI API with Business One’s own validation applied, then post as real sales documents with the correct partner, terms, and lines. Status flows back to the buyer.
- Everything is queued, logged, and error-isolated, so a maintenance window delays a post rather than losing an order, and operations can see exactly what failed and why.
Business One specifics that catch integrations out
- Localizations. Business One is localized per country (tax, legal, document numbering). International operations run multiple localizations, and the integration has to respect them rather than assume a single US setup.
- Multi-currency. Business One books in multiple currencies by design, common in the international companies that run it. Pricing and documents on the storefront have to honor the partner’s currency.
- Warehouse-level inventory and item management. Stock is tracked by warehouse; distributors need warehouse-level availability surfaced, not a flattened global number.
- Document flow. Business One has a specific sales-document chain (order, delivery, invoice). Where a web order enters that chain, and how its status maps back, is a real design decision.
- The Service Layer vs DI API choice is not cosmetic: it changes throughput, how real-time reads can be, and how the write path is built. It follows from your HANA-or-SQL edition.
Is Business One the right platform to build a storefront on?
For a mid-market distributor or manufacturer, Business One is a solid foundation for a B2B storefront, and its Service Layer makes for a cleaner integration than several older ERPs allow. The honest caveats: on the SQL/DI API edition, expect the sync-and-mirror architecture rather than fully live calls; and if your operation has genuinely outgrown Business One and you are eyeing a larger SAP tier, that is worth surfacing before you build the storefront, not after. We would rather have that conversation up front than integrate against a system you are about to replace.
One scope note we make explicit: this is about SAP Business One, the mid-market product. Enterprise SAP (S/4HANA, SAP Commerce Cloud) is a different world with different partners, and it is not what we are describing here.
What a Business One storefront changes
| What changes | Why | Direction |
|---|---|---|
| Order-entry labor | Orders customers place themselves stop being keyed into Business One by your team | Down, in proportion to phoned and emailed volume |
| Order accuracy | Web orders post through the API with validated partners, items, and pricing | Fewer credits and reships |
| International order friction | Multi-currency, multi-localization buyers self-serve in their own currency and terms | Lower friction on the hardest orders |
| Average order value | A buyer browsing the full, correctly priced catalog adds lines a manual order never would | Up, compounding with adoption |
How much each moves depends on how much of your Business One order volume is routine reorder traffic today, which an honest scoping conversation establishes before modeling any return.
Bring your Business One setup, leave with a straight answer
If you are weighing a storefront on SAP Business One, the facts that decide the project are: HANA or SQL Server and which version, how your pricing is structured (price lists, special prices per partner, discount groups), and how orders reach you today. With those we can tell you what the integration really involves, including whether the Service Layer makes a lighter build possible or where custom work is unavoidable. Start that conversation here.
Frequently asked questions
Yes, and more cleanly than several older ERPs, because Business One on the SAP HANA edition offers the Service Layer, a modern REST/OData interface built for exactly this. On HANA you can design a near real-time integration for pricing and availability, with orders written back through the Service Layer. On the Microsoft SQL Server edition the integration uses the older DI API and leans more on scheduled sync into a fast read layer. Either works; the architecture and how real-time it can be depend on your edition.
The Service Layer is the modern REST/OData interface available on Business One for HANA, standards-based and capable of reads and writes without a COM bridge, and it is the preferred path for a new storefront integration. The DI API (and DI Server) is the older COM-based Data Interface used on the SQL Server edition; it enforces Business One’s business rules on writes but is heavier to operate and constrains the architecture. Which you use follows from whether you run Business One on HANA or SQL Server.
Business One resolves a customer’s price through a hierarchy: base price lists, special prices per business partner, and period, volume, and group discounts. A correct integration maps each storefront login to its Business One business-partner record and reproduces that full pricing stack so the buyer always sees their real price. Reproducing this per partner is the core of the build and the most common place packaged connectors fall short, because distribution pricing in Business One is rarely a single flat list.
It has to, because multi-currency and per-country localizations are exactly why many companies run Business One. The integration honors each business partner’s currency in pricing and documents, and respects the localization rules (tax, document numbering) for the relevant country. This is a normal requirement for the international distributors and manufacturers Business One serves, and it is designed in from the start rather than bolted on.
A packaged connector can work when your pricing and partner setup are standard. Business One shops often are not standard: special prices per partner, heavy use of user-defined fields and tables, multi-currency, and localizations are where packaged connectors run out. The honest test is how much custom logic lives in your Business One setup and how complex your pricing hierarchy is. We build the integration where a connector cannot cover you, using the Service Layer where your edition supports it, and we will tell you if a connector honestly would.