Key points
- A first integration has five mandatory pieces: stock levels, customer prices and terms, the customer record with its balance, orders passed to the ERP, and access to documents. Everything else can wait.
- Name one source of truth and one direction for every type of data. Two systems editing the same field will always drift apart, and the drift surfaces during a complaint or a credit note.
- Sync frequency is a cost decision, not a technical one. Choose real time where a mistake is expensive, not everywhere, because "everything live" is usually bought to avoid having to decide.
- Plan the fallback mode before the outage: what the store does without the ERP, how long it can run that way, who is told, and who re-keys the queued orders once the connection returns.
The commercial decisions from the previous chapter share one trait: the platform can execute almost none of them on its own data. A credit limit needs a balance, blocking needs a list of overdue invoices, contract prices and stock levels live where the company has worked for years, which is the ERP. This chapter is about decisions rather than technique: what to connect first, who owns which field, how often to exchange data, and what happens when the connection goes quiet on a Wednesday morning. The architecture of that exchange, queues and retries included, we covered separately in the piece on integrating a B2B store with an ERP.
What must be connected first, and what can wait
The test is simple: without what can a customer not place a correct order, and your team not close the day. The answer comes to five items. Stock levels, with a decision on which figure you show: physical stock, or available to sell after reservations. Customer prices and terms, ideally calculated by the ERP itself, so you do not rebuild its logic in a second system. The customer record together with the credit limit and balance, because without it the decisions from the previous chapter stay on paper. Orders passed to the ERP immediately, with a number and a status returning to the customer. And documents, meaning invoices and delivery notes downloadable from the account.
Documents are the most underrated of the five, and they remove one of the most repetitive tasks in the company from finance and sales: resending invoices on request. What can wait are the things that demo well but get used rarely in the first months: batch and serial number reservations, annual rebate settlements, complaint registers, delivery forecasts, carrier tracking statuses. Each is a separate integration project and each pushes the launch date out. The rule is one: if a process runs on phone and email today and moving it does not block orders, it is not first release scope.
Who owns each type of data
This is the most important architectural decision, and it is taken commercially rather than technically. The rule is one source of truth per data type, named explicitly and written down. In a typical split the ERP owns prices, trading terms, stock, the customer record and documents, because that is where finance and the warehouse work. The platform owns what the ERP does not have and does not need: product content, images, the category structure, user accounts and permissions (an ERP has no concept of a "store user"), carts, and quote requests up to the point of acceptance.
The trouble sits in the contested fields, and those are the ones to settle on paper. Delivery addresses: the customer adds them in the store, but the ERP has to accept them and owns the address printed on the document. Contacts and ordering users: usually owned by the platform, then pushed into the ERP record. Orders: owned by the platform until the ERP accepts them, after which the ERP owns the status and the store only displays it. When two systems can edit the same field, the one that writes last wins, which means chance wins. Locking editing on one side is always cheaper than reconciling conflicts after the fact.
The table below is a template for that agreement. Fill it in for your own company before you talk to a vendor, because the last column defines the scope and the one before it defines the cost.
| Data type | Source of truth | Direction | Sensible frequency | First release |
|---|---|---|---|---|
| Stock levels | ERP | ERP to platform | Live or every few minutes | Yes |
| Customer prices and terms | ERP | ERP to platform | Daily plus a refresh at the cart | Yes |
| Customer record, limit and balance | ERP | ERP to platform | Several times a day, balance more often | Yes |
| Orders | Platform until accepted | Platform to ERP | Immediately on submission | Yes |
| Invoices and delivery notes | ERP | ERP to platform | Daily | Yes |
| Product content and images | Platform | One-off import from ERP | On demand | Yes, once |
| Shipment statuses | ERP or carrier system | ERP to platform | Daily | Can wait |
| Rebates and periodic settlements | ERP | No integration | Not applicable | Can wait |
A template to complete before choosing a vendor. The frequency column is also the cost column: the closer to real time, the more expensive to build and to run.
Real time or scheduled: a cost decision
Live synchronisation sounds like the obvious choice and is one less often than expected. It costs more to build, it needs monitoring, and it loads the ERP, which in older installations does not always tolerate constant querying and is sometimes licensed per interface or per request. Scheduled synchronisation, nightly for example, is cheap and predictable, but it means the store works on data that is hours old. The middle option usually wins: a scheduled baseline plus an on-demand refresh at the critical points, meaning entering the cart and submitting an order.
Do not synchronise everything at the same rate. Set the frequency by the cost of being wrong: a stale stock figure on a fast-moving item costs you a cancelled order and an apologetic phone call, a stale product photo costs nothing. If you decided in the trading terms chapter to display exact unit counts, this is where you pay for that decision.
What to do when the ERP has no API
This happens more often than platform vendor materials suggest, especially with older and local systems. It does not kill the project, it pushes it towards scheduled solutions, which means revisiting some decisions from the previous chapter: with file-based exchange it is hard to promise customers an exact unit count.
There are four variants, ordered from safest. First: the ERP vendor offers its own integration module or connector, usually paid, but maintained and tested against upgrades. Second: file exchange, meaning agreed files swapped on a schedule through a directory or file server. It is cheap, surprisingly durable, and entirely sufficient at daily frequency, but it gives no real-time confirmations. Third: a middleware layer that holds the mappings and translates formats, which makes sense once more than two systems are involved. Fourth: reading straight from the ERP database, the fastest to stand up and the riskiest, because the first ERP upgrade can break it and writing into that database while bypassing application logic is simply a bad idea. Ask the same question of every variant: who maintains this in two years, and what happens when the ERP gets a new version.
A plan for when the integration breaks
The integration will stop working at some point, and that is experience rather than pessimism: a password expires, a field is renamed after an upgrade, a disk fills up, the ERP server goes down for maintenance. The question is not whether, but what the store does then. The sensible default is that it keeps accepting orders and queues them for delivery, and the ERP receives them once the connection returns. The opposite variant, suspending orders, is safe for accounting and expensive for sales, because a customer does not wait, a customer calls a competitor.
Four things remain to be settled. What data the store runs on in fallback mode: the last known prices and stock, and after how long it stops showing availability at all, because two-day-old figures mislead the customer. What happens to deferred payment with no balance available: do you suspend it and switch to prepayment, or allow it and carry the risk, which is a finance decision rather than a developer one. Who is told about the outage and how fast: the alert should reach a named person rather than a shared inbox, and your sales rep should know before the customer does. And what the manual procedure looks like: who re-keys the queued orders and how they know an order has already been re-keyed, so nobody receives the same goods twice.
Questions to ask your ERP vendor before signing
Get these answers in writing before you sign a platform contract, because each of them can change scope and timeline. Does my version of the ERP have a documented API, and what exactly does it expose: stock, the price for a specific customer including their terms, balance and credit limit, order creation. Is an extra module or licence required, and what does it cost annually rather than at implementation. What are the request limits, and is there a test environment where work can happen without touching production data. Who on the vendor side is responsible for integrations, how quickly do they respond, and is that covered by a service agreement. What happens during an ERP upgrade, and are integrations tested as part of it.
One question deserves to be asked separately, because it is the most expensive one to get wrong: can the ERP return a price already calculated for a given customer, with all of their terms applied, or does the platform have to rebuild that logic itself. Rebuilding means two places where the same pricing policy has to be maintained, and a guaranteed divergence the first time terms change. Once you have those answers in writing, data starts flowing both ways and one question remains: who will actually use it. Customers and sales reps have to get into the system and start working there, and that is what the next chapter covers.
Questions
Can a B2B platform run without ERP integration?
It can, but only as a catalog with an order form, where prices and stock are entered by hand and a person re-keys every order. With a few dozen items and a handful of customers that works. With a real wholesale catalog, maintaining stock and prices manually will take more time than the platform saves, and the gap between the store and the invoice will appear in the first week. If integration is being postponed on cost grounds, scheduled file exchange is a more honest option than running two independent systems.
How often do stock levels need to be synchronised?
It depends on what you promised the customer and how fast the goods move. If you show a general availability status, syncing every few hours is usually enough. If you show exact unit counts on items that sell out within a day, you need live updates or at least a stock check at the moment the order is submitted. A cheaper answer than constant synchronisation is often to change the promise: less precise availability information costs less than the architecture required to keep it accurate.
Who should be responsible for the integration: the ERP vendor or the platform vendor?
Responsibility has to sit with one party and be stated in the contract, otherwise the first outage turns into each side pointing at the other. A workable split is usually this: the ERP vendor is responsible for exposing the data and the stability of the interface, the platform vendor for retrieving it, mapping it and handling errors. On your side you need one person who knows whom to call and has the mandate to do it, because an integration with no owner inside the company becomes nobody's.
