A B2B platform can be wired into Subiekt, Comarch or enova so that stock, prices and documents flow on their own - on one condition: the ERP stays the source of truth and the platform only displays it. A quick note for readers outside Poland: Subiekt (from InsERT), Comarch ERP and enova365 are the three ERP systems most Polish small and mid-sized businesses run their warehouse and accounting on. Your customer logs into their account, sees their prices and their credit limit, places an order - and it lands in the ERP as a document nobody retypes by hand. The whole difficulty of integration is not “can it be done”, it is agreeing what lives on which side and what wins in a conflict.
Below I lay it out the way I run these projects: from the decisions, through the way data is exchanged, to the places where projects come off the rails.
What “wiring a B2B platform into an ERP” actually means
Integrating a B2B platform with an ERP is a permanent, automatic flow of data between the warehouse and accounting system and the site your business customers buy on. It is not a one-off product import, it is a cycle that runs without you - including at 11pm on a Sunday. In practice the same things always get exchanged:
| What | Direction | How often |
|---|---|---|
| Product records (name, code, unit, VAT) | ERP → platform | once a day or on change |
| Stock levels | ERP → platform | every few minutes to an hour |
| Prices and discounts per customer | ERP → platform | once a day, or live on entering the cart |
| Customer records, credit limits | ERP → platform | once a day |
| Orders | platform → ERP | immediately on placement |
| Documents (invoices, delivery notes, balances) | ERP → platform | once a day |
The rule I never depart from: one direction per field. If the price is created in the ERP, the platform never overwrites it - even when somebody badly wants to “just quickly fix it on the site”. Breaking that rule is the single most common cause of chaos.
Three ways to exchange data - which to pick
There are three ways to connect, and they differ mainly in how fast the data arrives and how much upkeep costs.
| Method | How it works | When it makes sense |
|---|---|---|
| Direct API / the ERP’s developer layer | The platform queries the system and writes documents into it | The end-state solution for a custom platform, when current stock and prices matter |
| A ready-made connector or middleware | An external service watches over the sync | Starting without a big budget, standard needs, delays acceptable |
| File exchange (XML, CSV, EDI) | Scheduled export and import of data packages | When the ERP sits inside a closed network or API access is blocked |
File exchange looks archaic, but it is often the most sensible option when the sales team works in daily cycles anyway. You just have to tell customers plainly: the stock figure on the site is “as of yesterday”, and the warehouse is what confirms the order.
Subiekt GT and Subiekt nexo
Subiekt connects to a B2B platform through the vendor’s developer add-on, which exposes the system’s functions to the outside world - in the GT line that is Sfera, in nexo its equivalent. It is a separately purchased licence, so the first phone call in a project like this goes not to a developer but to whoever manages your licences. What else is worth knowing:
- Subiekt is a local application - for a platform on the internet to talk to it, you need a piece of middleware running inside your network or on the server hosting the database. That is a normal part of the rollout, but it has to be planned and maintained.
- Prices in Subiekt are price levels and discounts assigned to a customer - the platform should read them rather than calculate its own. Home-grown “discount logic” on the site will sooner or later drift away from the invoice.
- The item code is the key, not the name. Where the product records are a mess (duplicates, empty codes), cleaning up the data takes longer than the integration itself.
- An order from the platform usually lands as a customer order document, which the warehouse fulfils through its normal route - the platform does not issue invoices on its own.
Comarch ERP Optima and XL
Comarch offers several routes at once, and that is both an advantage and a trap. There is a ready-made B2B store from the vendor, there is an integration layer for partners, and in the server editions there is access to the database. The choice depends on how unusual your commercial process is:
- The vendor’s ready-made B2B store - the fastest start and a predictable integration, but the look and the ordering logic stay within what the vendor anticipated. With case quantities, negotiated price lists and per-branch limits it starts to chafe quickly.
- A custom platform wired into Comarch - complete freedom in how ordering works, at the cost of real work on the ERP side. The system version decides, as does whether you run Optima in the vendor’s cloud or on your own server - in the cloud, data access can be narrower and that has to be checked before the quote, not after.
- Comarch ERP XL - a bigger organism with more ready-made commercial mechanics (price lists, promotions, limits), so more is worth leaving in the ERP instead of recreating it on the site.
A practical rule for both lines: the more commercial logic stays in Comarch, the cheaper the platform is to maintain over the following years.
enova365
enova365 exposes data through a programming interface available within the relevant modules and licence variant - that is the first thing to confirm with your implementation partner. enova is often more convenient than its competitors, because it more frequently sits on a server reachable remotely, which simplifies connecting the platform. What to look at:
- Whether you have the trade module in a version that exposes the data you need.
- Whether customer price lists and discounts are calculated on the ERP side - if so, the platform should ask for the price for a specific customer and a specific quantity, rather than keeping its own tables.
- Whether orders should come back as commercial documents or as requisitions awaiting a sales rep’s approval. That is a business decision, not a technical one, and it is better made before the rollout.
Prices, credit limits and the things that break projects
The hardest piece of a B2B platform is not the design, it is the price for a specific customer at a specific moment. In wholesale there is almost never a single price: there is a base price list, the customer’s discount, a discount on a product group, a time-limited promotion, a quantity tier and an individual agreement for the largest accounts. Hence four decisions at the start:
- Who calculates the price - the ERP live (more accurate, slower) or the platform from downloaded price lists (faster, with a risk of drift).
- What happens when the credit limit is exceeded - the cart is blocked, the order goes for approval, or it is only a warning.
- What the customer sees when stock runs out - the exact figure, bands (“in stock”, “low”), or the date of the next delivery. Plenty of wholesalers do not want to show exact numbers to competitors.
- Who creates the accounts - the customer themselves with verification, or only a sales rep. That decision settles whether you need registration and verification of trade customers on the site side, or whether importing records from the ERP is enough.
Then come documents. Business customers expect to see their invoices, delivery notes and outstanding payments in the portal - and that is usually the feature which takes the most load off the office, because it ends the “please send me the March invoice again” calls. Numbering and sending the invoices themselves stays in the ERP and in the KSeF flow - KSeF being Poland’s mandatory e-invoicing system, which now applies to every business - and the platform only displays them. What a portal like that looks like from the customer’s side, I described in the piece on the B2B ordering portal.
What if I already have a store on PrestaShop, Shoper or WooCommerce
Then you usually do not build a new platform, you add a B2B layer to the existing store: login, per-customer prices, limits, quick ordering by item code and orders from a file. A B2B platform on PrestaShop or a B2B store on Shoper (a popular Polish hosted store platform) works as long as it stays inside what the plugins and the platform allow - the limit only shows up with unusual price lists and two-way integration.
If you sell wholesale and retail at the same time, it is almost always cheaper to run B2B and retail in one store than two separate systems wired into the same ERP twice. I most often work on WooCommerce with a layer of custom code wherever the commercial logic goes beyond the standard - that gives control over prices and integration without rewriting the store from scratch.
How long it takes and where to start
Honestly: the technical connection itself is usually the smaller part of the work. The larger part is cleaning up the data and writing down the commercial rules nobody has ever written down, because “the sales rep knows”. So I start every project like this with a free diagnosis: I look at your ERP, its version and licence, at the state of the product records, at how orders are created today and where people retype data by hand. Out of that comes an integration map and a list of decisions.
Only then does a written quote appear, with scope and stages - so there are no surprises halfway through. I split larger rollouts so that the first working piece (login, catalogue with customer prices, orders into the ERP) reaches production quickly and the rest follows later. The brackets, and what moves them, I set out in the piece on what a B2B platform costs.
Frequently asked questions
Can a B2B platform work with Subiekt GT? Yes, through the vendor’s developer add-on (Sfera), which you have to have purchased. Because Subiekt runs locally, you also need middleware on your side of the network to talk to the platform on the internet. Before I quote anything, I check with you exactly which version and licence you have.
Will stock levels be live? Usually not to the second, and that is fine. The standard is refreshing stock every few to fifteen minutes, and prices and records once a day. Truly live queries go to the ERP only in the cart and at order placement - where a mistake costs the most.
Is a ready-made B2B store from the ERP vendor better, or a custom platform? The ready-made one is faster and cheaper at the start, as long as your commercial process fits its assumptions. A custom platform makes sense when you have unusual price lists, case quantities, several buyers within one company or credit limits with approval. The answer comes out of your list of exceptions, not out of a general ranking.
What if my ERP sits in the vendor’s cloud? We check the scope of data access before quoting - in cloud editions it is sometimes narrower than on your own server and occasionally needs an extra service from the vendor. Where access is limited, the alternative is file exchange on a daily cycle, with the freshness of the data clearly communicated to customers.
Running a store where something does not work the way it should? I build and rebuild WooCommerce stores - from a single fix to reworking the whole sales flow. Tell me what you are dealing with and I will send back a scope and a price.