B2B store and ERP integration: an architecture that does not hurt

Integrating a B2B store with an ERP means the ERP remains the single source of truth for products, stock and prices, the store reads that data on a set rhythm, and orders flow back into the ERP as ready sales documents. Done well, the integration eliminates manual retyping entirely. Done badly, it creates a second, contradictory stock state and generates the very work it was meant to remove. This article describes the architecture that works, at the level of specifics: what to sync, on what rhythm, and what to do with errors.

Rule number one: the ERP is the source of truth

Most failed integrations break a single rule: they allow the same data to be edited in two places. When a price or a stock level can change both in the store and in the ERP, the two systems will eventually diverge and the team will stop trusting either. So we design the store as a view of the data and a channel for taking orders, never as a second database. Everything concerning products, stock, prices and settlements has one owner: the ERP. This one architectural decision eliminates an entire class of future problems.

What we sync and in which direction

Read direction, ERP to store: products with attributes, stock levels (with a safety buffer), contract price lists per customer, payment terms and credit limits. Write direction, store to ERP: the order as a sales document with correct indexes, the right counterparty and the right prices, with fulfilment statuses flowing back. Plus invoices generated in the ERP and exposed in the customer account. Every flow has one direction and one owner, so when data differs you always know which side is right.

Every element has one direction and one owner, as the table shows:

The store is a view of the data and a channel for orders, never a second database.

Everything is held together by a sync layer that isolates the store from the dialect of any particular ERP.

A sync layer instead of spaghetti

The worst possible design is a store that calls the ERP API directly from ten places in the codebase. Instead we build a separate synchronisation module: field mappings in one place, operation queues, schedules and a log of every exchange. The store does not know whether Comarch, Subiekt or SAP sits on the other side, because it talks to the layer, not the system. This costs slightly more upfront and pays back at the first change: an ERP update, a new field, or in the extreme case a full ERP replacement, which then means swapping an adapter rather than rebuilding the store.

Sync rhythms: what must be instant and what can wait

Not everything needs to be realtime, and that is good, because realtime is expensive. We set the typical rhythms like this:

• Stock levels: every few minutes, with a buffer that prevents selling the last unit twice.
• Contract price lists: daily, plus on demand after a change in the ERP.
• Orders: immediately, because logistics is waiting for them.
• Product catalog: usually hourly.

Choosing rhythms is always a trade: more often means more cost and more load on the ERP, less often means more drift risk. We make these decisions consciously during analysis instead of discovering them in production.

Error handling: a queue instead of drama

ERPs go down: restarts, updates, record locks. An integration that loses an order in that moment is worse than no integration, because it destroys trust. So every operation is idempotent (safe to repeat), and every failure lands in a queue with its reason attached. The system retries automatically and only alerts a human after retries are exhausted. The health metric of an integration is an empty error queue, not the absence of errors, because errors always happen.

This simple flow saves hours of late-night phone calls: nothing disappears silently and it is always clear what awaits a decision.

Comarch, Subiekt, enova: the Polish specifics

The systems popular in Poland differ in access models: from modern APIs, through licensed exchange services, to working on staging tables. Add custom fields that accounting has used to describe its world for years, and document numbering rules that are better left untouched. That is why we audit ERP objects before quoting: which entities, which fields, which permissions and which exchange route is actually available. Discovering these things in week six of a project is a classic of budget disasters, and the audit removes it.

No API? File-based integration works too

Some ERP installations expose no API at all, and that is no reason to stay with retyping. Scheduled file exchange or staging tables give the same correctness guarantees at a slower sync rhythm. Stock every half hour instead of every five minutes is still a chasm away from stock checked over the phone. The mechanics stay identical: one source of truth, queues, retries, a log.

What the integration changes in numbers

The cost of handling a single order drops from tens of złoty in office time to pennies, because the document creates itself. Retyping errors, index typos and stale prices fall to practically zero, and with them the corrections and returns they used to generate. Sales outside office hours start to exist, because the portal takes orders at night and on weekends. Sales reps stop being retyping machines and return to the conversations that bring new customers.

Where to start

The sequence that works: first an inventory of ERP objects and a decision on the exchange route, then a read-only integration (products and stock visible in the store), then order writing for a pilot group of customers, and only after things settle, a full rollout. This plan minimises risk and builds the team’s trust in the system. The full playbook, in the rhythm of a 90-day rollout, lives on our B2B store with ERP integration service page.

Wholesale does not need a revolution or buzzwords. It needs the human API removed from the middle of the process: the person retyping data between screens. The architecture in this article does exactly that and nothing more. The rest is consistent execution.