SolEx B2B vs Endora Commerce — which one to pick for B2B

SolEx B2B solves one problem and solves it very well: “my regular customers should place their own orders, at any hour, on data from my ERP, and I do not want to retype any of it”. The platform syncs both ways with Subiekt GT, nexo, Navireo, Comarch ERP Optima and XL, WF-Mag, enova and Symplex. It pulls product records together with photos, descriptions, stock levels, price tiers and attributes, along with trading partners, their discounts and settlement history. Submitted orders go straight into the trading system as an order, a proforma or a VAT invoice. The customer logs in and sees their own post-discount prices: the same ones they have in the ERP. A sales rep can log into the customer’s account, check their turnover and outstanding debt, and place an order on their behalf.

That is a very specific value at a very specific price: PLN 6,490 upfront and PLN 499–2,499 a month depending on order volume. For a large share of Polish wholesalers and manufacturers that is exactly what they need, and there is no point looking further.

This article is not about SolEx B2B being worse. It is about these being two different classes of product. SolEx is an ordering portal: a self-service layer over an ERP in which the ERP remains the source of truth. Endora Commerce is a commerce platform with its own data model: catalog, content, SEO, marketing, several sales channels, negotiation and its own order process. It integrates with an ERP but is not a skin over it. If you only need the first of those, Endora will be overpaying. I will say so plainly in the cost section, with the arithmetic done.

The short version

If you only read three sentences: pick SolEx B2B when your ERP already holds everything the customer is meant to see, and the only thing missing is customers typing their own orders instead of phoning the office. Pick Endora when the platform has to be more than a mirror of the ERP: its own content and SEO, negotiation, several sales channels, its own order lifecycle and data that is not in the ERP and never will be. Over a three-year horizon SolEx on a typical tier costs several times less than an Endora rollout. So if both cover your requirements, the choice is obvious and it is not Endora.

What each platform actually is

SolEx B2B

SolEx B2B is a hosted B2B ordering platform sold on a subscription with a one-off upfront licence fee. The vendor runs its own infrastructure: two independent sites over 350 km apart, linked by encrypted VPN tunnels, with three fibre links from different operators, three power lines and backups in both locations. On your side there is no server, no upgrades and no on-call rota.

The operating principle is single and consistently carried through: the ERP remains the source of truth. The platform pulls product records from it (name, symbol, code, photos, descriptions, stock levels, minimum stock, price tiers, attributes, groups, bulk packaging) and trading partners (name, tax ID, address details, discounts, invoice, order and settlement history), and in the other direction writes submitted orders back as a document in the trading system. The customer does not see a “platform price list”, only their own price after the discounts defined in the ERP.

The feature set is shaped around that job: a cart with memory and file import (CSV, Excel, EPP), product variants, families and accessories, price tiers, minimum order quantities and bulk packaging with packaging-dependent discounts. Then there is multi-language and multi-currency support with VAT configured for exports and intra-EU supply, hiding products from selected customers and groups, a public pre-login catalog (without prices and stock), a sales rep panel, announcements and a newsletter, plus, as the vendor puts it, over a thousand settings for tailoring the portal to an industry. The WMS module is bought separately, with picking, verification, courier integration and a mobile app for warehouse staff and drivers.

Endora Commerce

Endora Commerce is a B2B platform written in TypeScript: a Fastify backend with MikroORM and Zod contracts, a server-rendered Next.js storefront, a React admin panel. Data in PostgreSQL, cache and queues in Redis, search in Meilisearch. Over 60 modules as standard: from catalog and price lists to KSeF, product feeds and an AI assistant in the admin panel.

The key conceptual difference: Endora has its own data model and does not assume that everything the customer should see is already in the ERP. The catalog can carry content the trading system does not have and never will: marketing copy, technical attributes for filtering, downloadable files, blog articles, pages built with the Page Builder, a mega menu and an SEO structure. The ERP delivers what it should: records, stock, base prices and sales documents. The rest belongs to the platform.

The second difference is the delivery model. You do not buy a subscription; you get a platform rolled out around your processes, with the code in your Git repository and the data in your database. There are no licence fees, nothing per seat and nothing tied to revenue. The first working prototype takes four weeks, and an average rollout sits roughly in the PLN 60–80k range, excluding integrations with external systems, which are quoted separately.

Performance

This criterion is worth splitting into two questions, because the bottleneck sits in a different place on each platform.

The performance of the portal itself. SolEx runs on the vendor’s infrastructure, specialised around a single product: no third-party software shares the server room, and the hardware is replaced every four years. From the customer’s point of view that is an advantage you cannot argue with. No monitoring, no upgrades, no backups and no phone call at night.

Endora runs on your VPS: a minimum of 4 vCPU and 8 GB RAM, 8 vCPU and 16 GB recommended. Core Web Vitals targets are written directly into the platform requirements (LCP under 2.5 s, INP under 200 ms, CLS under 0.1), as is search under 200 ms at the 95th percentile. The demo runs on a catalog of over 120k SKUs, and generating a product feed for 100,000 products produces a 38 MB file with peak memory usage under 20 MB, because serialisation is streamed. The target scale is hundreds of thousands of SKUs and hundreds of orders and quote requests a month. But it is still a server somebody has to look after.

The performance of the sync. Here the bottleneck of a portal built as a layer is structural. If the ERP is the source of truth, how current the portal’s data is depends on the sync cycle, and catalog performance depends on how many records have to be copied across and how fast the trading system does it. Comarch ERP Optima or Subiekt GT are not fast APIs at a few hundred thousand records. Endora holds the data itself and indexes it in Meilisearch, so catalog speed does not depend on the health of the ERP; the price is resolved by the pricing engine on every request, from the group price list, the contract, the quantity break and the time window. The dependency on the ERP stays only where it genuinely has to be: stock levels and documents.

A caveat: SolEx has run this model in production for years and has rollouts behind it in which the sync bottlenecks are well understood and handled. Endora’s numbers are architectural targets confirmed by tests and by the scale of the demo, not a decade of production peak seasons.

Cost of rollout and running

This is the section where the difference is largest. It goes SolEx’s way.

Let us put numbers on it. A company places 400 orders a month, which lands on the STANDARD 0–500 orders tier at PLN 599 a month. Horizon: three years.

• SolEx B2B: PLN 6,490 upfront + 36 × PLN 599 = PLN 28,054 net. With an SSL certificate (PLN 19/mo) and the vendor’s branding removed from the footer (PLN 100/mo) the bill rises to PLN 32,338.
• Endora Commerce: PLN 60–80k for the rollout + infrastructure of PLN 5–10k a year = PLN 75,000 to 110,000 over the same period, excluding integrations with external systems.

The gap is more than threefold and no amount of negotiating on either side makes it go away. If SolEx covers your requirements, paying three times as much for Endora has no justification, even if Endora does more things you do not need.

The arithmetic starts to even out in three situations.

First, at high order volume. The “up to 2,000 orders” tier is PLN 1,799 a month, which is PLN 71,254 over three years, already inside Endora’s rollout range. The unlimited-orders tier is PLN 2,499 a month, which is PLN 96,454 over three years and PLN 156,430 over five, while Endora over five years comes to PLN 85–130k. The point where the three-year total matches the bottom of Endora’s range (PLN 75,000) falls at a subscription of about PLN 1,903 a month.

Second, with modifications. Work outside the standard is PLN 300 an hour, cheaper in packages: 100 hours costs PLN 15,000, an effective PLN 150 an hour. Forty hours of changes a year is PLN 12,000 at the list rate. If your wish list is long and comes back every quarter, this item can grow faster than the subscription.

Third, with features an ordering portal simply does not have. A retail store alongside the wholesale one, a blog and SEO, a distributor portal as a separate channel, price negotiation. These are not things you order in an hours package; they are a different class of product. At that point you are not comparing “SolEx versus Endora” but “SolEx plus a second platform versus Endora”, which is a different sum altogether.

A caveat on Endora’s side: no licence fees does not mean cheap. That PLN 60–80k is a starting point, not a ceiling. Integrations with an ERP, WMS or OMS are quoted separately, development after launch costs money, and somebody has to look after the server. The difference is in the nature of the spend: the budget goes into your platform and does not rise automatically with order volume.

Ease of extending the platform

The best way to test this is on concrete tasks that come up regularly in B2B.

There is one pattern here, and it follows from the design rather than from the quality of the work. If the ERP is the source of truth, then whatever is not in the ERP is not in the portal. A marketing product description, a technical attribute for filtering, a field that comes from a framework agreement, your own “in production” status: if the trading system has no room for it, neither does the portal, because the portal is a reflection. That simplifies life (one place of truth, no data drift) and at the same time sets a ceiling.

In Endora, order statuses and the transitions between them are configurable, with a business event attachable to each transition, and custom fields are added to orders, organizations, customers, categories, products and quote requests as data, with no database migration and no code deployment. The same Page Builder composes CMS pages, transactional email content and invoice templates. The admin panel has an AI assistant: you describe in plain language what should happen, and it shows a plan and executes it once you confirm, within your permissions and with an entry in the audit log.

There is a flip side to the same coin, though. With SolEx you do not have to develop anything for it to work, and changes are ordered from the vendor and paid for by the hour. With Endora the limit is your time and budget, but somebody has to have that time: a technology partner or your own TypeScript team. For a company with no IT function and no appetite for developing a platform, the hourly model is simply more convenient.

There is a number behind that, because “fast” on its own means nothing: a less complex module takes 1-3 days in Endora, a larger one up to a week. That excludes integrations with an ERP, WMS, CRM, PIM or OMS: those are always heavily bespoke, and writing one takes up to two weeks. Those are always heavily bespoke and can take considerably longer. The difference against a subscription model is not really about the days, though. It is that there is somebody to ask at all: on SaaS a missing feature joins the vendor’s wish list and arrives when they decide, not when you do.

Integrations with external systems

Where SolEx B2B wins

Ready integrations with Polish ERPs come as standard, and this is the platform’s strongest card. InsERT Subiekt GT, Subiekt nexo, Navireo, Comarch ERP Optima and XL, WF-Mag, enova, Symplex: seven families of systems that between them cover most of the Polish SME market. Two-way syncing of product records, trading partners, discounts, stock, settlement history and sales documents is part of the product rather than a project to be quoted. On top of that there is file-based integration for the awkward cases, a Web API open to new systems, and a custom-file directory where the vendor places modifications for a specific client.

This deserves to be stated without hedging: with Endora, integrating with your ERP is a separate line in the quote, whereas with SolEx, provided your system is on the list, it is simply there. For a company that wants a portal running on Optima within a few weeks and does not want to run an integration project, that is the deciding argument.

The second thing is the WMS module, which Endora does not have. Goods receipt, picking with a calculated route through the warehouse, verification with video monitoring assigned to the order, integration with couriers and parcel lockers, dropshipping and own-transport support with a driver app. That is a complete warehouse product on the same invoice as the portal, not a feature bolted on.

Where Endora wins

The off-the-shelf list is shorter, but the integration contract is stronger and open-ended.

The important part is that there is no list of “supported ERPs”, there is a documented contract: a partner API with live OpenAPI generated from the contracts in code, signed webhooks and encrypted provider configurations. As a result any ERP, CRM, WMS or OMS connects as an adapter module: Comarch, SAP, IFS, an in-house system written twenty years ago, or a product that appears on nobody’s partner list. The adapter registers itself with the platform, gets its own settings and permissions, and the core stays untouched.

The specifics this layer rests on:

• Comarch ERP Optima and Subiekt GT: adapters as standard for records, stock, prices and sales documents.
• KSeF in the platform core: invoices and corrections in the FA(3) format sent through a durable queue, the KSeF number on the document, the official confirmation available for download and a verification QR code on the PDF. I found no mention of KSeF in SolEx’s published documentation; with e-invoicing mandatory in 2026 it is worth asking the vendor directly which side handles that obligation.
• An API key pinned to an organization and a channel: the integration sees the prices and limits of exactly that company and can do no more than its own buyer.
• Idempotent orders: a repeated request returns the same order, never a second one. That holds for concurrent repeats too.
• Webhooks signed with HMAC-SHA-256, up to eight attempts with growing intervals, a separate view of failed deliveries with manual retry.
• Bulk quoting: a single request prices up to 200 line items for a specific organization, matching the cart to the last grosz.
• Credentials encrypted with AES-256-GCM, tested on save and masked on read.
• Payments and marketing natively: Stripe, PayU, tpay, GA4, Google Tag Manager with Consent Mode v2, Meta Ads, LinkedIn Ads, Google Merchant Center and Meta product feeds.

The difference comes down to the direction of the dependency. With SolEx the integration is the vendor’s product: you get it ready-made, but in the shape the vendor anticipated, and changes are ordered by the hour. With Endora the integration is your code in your repository: you have to write it or commission it, but after that nobody changes or withdraws it on you.

B2B: where Endora Commerce genuinely stands out

Let me start with what SolEx does well in B2B, because the list is real. Post-discount customer prices straight from the ERP: no second place to maintain them and no risk of the portal showing a price different from the invoice. A separate product set for every customer and group, hiding a range a given buyer has no business seeing. Price tiers, logistical minimums and bulk packaging with packaging-dependent discounts.

Cart import from CSV, Excel and EPP files plus a cart with memory. A sales rep panel with login into the customer’s account, a view of turnover and outstanding debt, and ordering on the customer’s behalf. Multi-language and multi-currency with VAT configured for exports and intra-EU supply. That is a complete set for a wholesaler selling to regular buyers from a price list.

The difference shows up where selling stops being a reflection of what is already in the ERP.

1. Quote requests as a full negotiation loop. SolEx’s published feature documentation contains no RFQ or price negotiation module. The model assumes the customer buys at the discounts they hold in the trading system. In Endora negotiation is in the core: the customer submits a request, the sales rep prices it with a lead time and a validity period, both sides can amend the terms, and an accepted quote turns into an order without any line items being retyped. On top of that there is the none price display mode, which hides every pricing element and routes purchase intent into a quote request. That is for a range that is not sold from a price list in the first place.

2. An organization hierarchy with inherited terms. An ordering portal works with the ERP’s notion of a trading partner, which is a flat list. In Endora the head office and its branches form a tree: order visibility flows down, and the price list and credit limit are inherited from the nearest ancestor. A group with twenty branches needs neither twenty parallel configurations nor twenty partner records.

3. A credit limit enforced by the platform. A view of the customer’s outstanding debt in the sales rep panel is information. Endora gives you a mechanism: the limit granted to an organization is reserved atomically at the moment the order is placed and released once the invoice is paid or the order cancelled, and once the limit is exhausted the platform filters the available payment methods. Alongside that, cart approval can be switched on per organization, with a full submission path and a decision with justification.

4. Your own data model above the ERP. Custom fields on orders, organizations, customers, categories, products and quote requests are added as data, with no database migration and no code deployment. Order statuses and transitions are configurable, with a business event attachable to each one. You do not have to ask your ERP vendor for a field its model never anticipated.

5. The sales channel as a first-class dimension. Storefront, marketplace, distributor portal, PWA and POS are separate channels of the same installation, with separate products, prices, promotions, content, settings, analytics and search index. A distributor portal is not a second installation and a second subscription, it is an entry on the channel list.

6. The sales and marketing layer an ordering portal does not have. A full CMS with a Page Builder, blog, mega menu, SEO structure, product feeds to Google Merchant Center and Meta, a newsletter, GA4 and Tag Manager with Consent Mode v2, Meta Ads and LinkedIn Ads. Plus B2C on the same installation and the same data model: an individual customer gets a one-person organization behind the scenes, and the retail channel is switched on separately. An ordering portal is designed to serve the customers you already have; this layer is for winning new ones.

There is also something that does not show up on a feature list: every sensitive operation lands in the audit log with the state before and after the change, and a sales rep can step into a customer’s context and see their prices through their eyes, with a visible banner and a log entry.

Where SolEx B2B has the advantage: data consistency with no effort. Because prices, discounts, stock and settlements are a single copy inside the ERP, a whole class of problems does not arise: price list drift, editing a record twice, the question of which version of a description is current. A platform with its own model has to solve those deliberately. On top of that, an order lands in the trading system as a finished document, with no transfer step. For a company that wants one place of truth and does not want to manage a second, that is a genuine strength rather than a limitation.

When SolEx B2B will be the better choice

1. Your ERP already holds everything the customer is meant to see. Descriptions, photos, attributes and discounts live in Optima or Subiekt and nobody plans to build a second catalog. The portal is there to display them, not to enrich them.

2. You sell to regular buyers from a price list, without negotiation. The customer knows what they pay because they have an assigned discount. The order is repeatable, and the only thing that should change is that they type it themselves instead of phoning.

3. The starting budget is a hard constraint. PLN 6,490 and PLN 499–599 a month is a different league from a rollout in the tens of thousands. If the decision reads “let us find out whether customers will start ordering by themselves at all”, it does not get cheaper than this.

4. You have no technical function and do not want one. The server, backups, upgrades and certificates sit with the vendor, in its two data centres, under its monitoring. Taking the whole operational layer off your plate is real value, not a false economy.

5. You need a WMS alongside the portal. Picking with a route through the warehouse, verification on video, couriers, parcel lockers, a driver app. Endora does not have this, and you would have to buy a separate system and integrate it through an adapter.

6. Your list of changes is short and finite. A few modifications at launch, then quiet. An hours package with the vendor will be cheaper and faster than maintaining a repository of your own.

7. You do not run marketing through the platform. You win customers through sales reps, trade fairs and referrals. A blog, SEO, product feeds and campaigns are not something you want to pay for, because you would not use them anyway.

When Endora Commerce will be the better choice

1. Selling runs through negotiation. Quote requests are the main path rather than an add-on. Part of the range carries no displayed price at all, because it is priced individually.

2. The catalog has to be more than a reflection of the ERP. Sales copy, technical attributes for filtering, downloadable files, category content, articles. Data that has no place in the trading system and should not have one.

3. The platform has to win customers, not just serve the ones you have. A blog, mega menu, SEO structure, landing pages built with the Page Builder, feeds to Google Merchant Center and Meta, GA4 with Consent Mode v2, campaigns in Meta Ads and LinkedIn Ads.

4. You need several channels at once. A distributor portal alongside the storefront, a marketplace, PWA, POS. Each with its own range, prices, content and analytics, from one admin panel and one installation.

5. Your customer structure is complex. Capital groups, branches inheriting the price list and credit limit from head office, order visibility down the tree, cart approval on the buyer’s side.

6. You want to enforce credit limits, not just observe them. A limit reserved atomically when the order is placed, released once the invoice is paid, with payment methods filtered once it is exhausted.

7. Your order process has steps of its own. Technical review, buyer-side approval, production, partial releases. You configure statuses and transitions in the admin panel and add contract-driven fields as data.

8. You sell retail as well. B2C runs on the same installation and the same data model, switched on separately per channel, with no second system and no watering down of the B2B model.

9. You want the code and the data in your hands. A Git repository on your side, a database on your side, no subscription rising with order volume and no dependency on whether the vendor keeps a given feature.

What Endora Commerce does not have

This section is here so that the article supports a decision, not just a feeling of having been convinced.

• A low entry point. A rollout in the PLN 60–80k range is an entirely different financial decision from PLN 6,490 upfront and a few hundred zloty a month. For a straightforward use case SolEx wins that sum without argument.
• A WMS module with a warehouse app. There is multi-warehouse support with reservations and backorder, but no picking with a route through the warehouse, no video verification and no driver app. SolEx has that as a separate, mature product.
• Upkeep bundled into a single price. Somebody has to maintain the VPS, the backups and the upgrades. In a hosted model that problem does not exist. You can run that yourself, or contract it to us or to a partner firm under an SLA.
• Ready integrations with seven families of Polish ERPs. Comarch ERP Optima and Subiekt GT are native; nexo, Navireo, WF-Mag, enova and Symplex are an adapter to be written and quoted.
• An extension marketplace. You cannot bolt on a feature in five minutes. Anything unusual is development work.
• A deep market of specialists. The platform is developed with a partner or your own TypeScript team, which has to learn it.
• A decade of references at extreme scale.
• Full API integrations with marketplaces. Allegro, Amazon and eBay are served by feed templates rather than two-way integration.

A short checklist

Answer these questions. The answers usually line up on one side.

1. Is everything the customer should see in the catalog already in your ERP?
2. Do your customers ask about the price before ordering, or do they buy at discounts they already hold?
3. How many orders a month will realistically go through the platform: closer to a hundred or closer to two thousand?
4. Is the platform meant to win new customers (SEO, content, campaigns) or only to serve the ones you have?
5. How many sales channels do you need: one portal, or a portal, a store and a marketplace at once?
6. Does your order process fit within the statuses your trading system offers?
7. Do you have somebody to look after the server and the development, or does that have to be the vendor’s problem?
8. Do you need a WMS with picking and a warehouse app?

A majority of “it is all in the ERP”, “they buy from a price list”, “one channel”, “existing customers”, “no IT function” and “I need a WMS” points to SolEx B2B. With that profile it will also be the distinctly cheaper choice. A majority of “we negotiate”, “our own content and SEO”, “several channels”, “unusual process” and “we want to own the code” points to Endora.

In summary

SolEx B2B and Endora Commerce are not competing for the same place in a company. SolEx is an ordering portal: a self-service layer over an ERP that takes order retyping off the sales office. It costs PLN 6,490 to start and a few hundred zloty a month, ships with ready integrations for seven families of Polish trading systems and a WMS module on the same invoice. Endora Commerce is a commerce platform with its own data model, negotiation, an organization hierarchy, sales channels, a full CMS and the code in your repository, for a rollout in the PLN 60–80k range and with no licence fees.

The simplest test: if the platform is meant to be a mirror of your ERP, SolEx will do it cheaper, faster and with no server on your side. If it has to carry its own content, its own process and several channels, a mirror will not do and the second option is worth costing.

Endora’s admin panel and storefront run online, so the fastest route is to click through the demo yourself or book a free workshop where we walk through your processes and systems, then put a number on the first rollout, integrations included.

And if the conversation points to an ordering portal being the better fit, we will say so plainly. A failed rollout is not a good reference for anyone.