Subiekt GT and Nexo PRO in multichannel selling
Subiekt knows your warehouse and your documents but not your marketplaces. What should happen between them, and where the boundary of responsibility runs.
In many Polish companies Subiekt is the system everything else is organised around: the warehouse is there, the documents are there, that is where accounting looks. The problem starts where its world ends — because Subiekt knows nothing about offers, marketplace orders or shipment statuses.
Subiekt and Allegro: where the boundary runs
A sensible split looks like this: Subiekt stays the source of truth for goods and documents, and the sales system handles the channels. Neither tries to do the other's job.
In practice, selling on Allegro, that means four flows:
- Goods and stock from Subiekt out to the channels — Subiekt says how much you have.
- Orders from Allegro and the other channels into Subiekt, as documents that become sales.
- Prices — usually base prices from Subiekt, recalculated by rule per channel, because commission and delivery cost differ in each.
- Sales documents issued in Subiekt, not alongside it.
The four flows in practice
The list above is tidy, but each of those four flows has its own rhythm and its own place where it breaks.
It is worth knowing them separately, because "the integration is not working" almost always means one of them is not.
Products from Subiekt to the channels
A one-off at launch and incremental afterwards — new records and description changes travel onward.
What breaks here is usually invisible: a product added in Subiekt with no symbol or no price has no way to reach the channel.
Get into the habit of checking how many records were skipped, not just how many went.
Stock from Subiekt to the channels
Continuous, and the most time-sensitive of the four. This is the flow that decides whether you sell something you do not have.
Its quality is measured in latency rather than correctness — the stock level always arrives eventually; the question is how many orders get in first.
Orders from the channels to Subiekt
The reverse direction, and the one most exposed to missing data. An order has to find both a contractor and the products in Subiekt.
A missing contractor is usually solved by creating the record automatically; a missing product is not. Which is why products go first and orders second.
Documents stay inside Subiekt
An internal flow: the order produces a sales document in Subiekt, under its own numbering.
The common problem here is not technical but deciding which document should be created and when — an accounting decision that has to be made before configuration, not during it.
When Subiekt should not be the source of truth for stock
The "Subiekt knows the stock" rule has exceptions, and it is better to spot them early than to fight a model that does not fit your situation.
Dropshipping
If goods never pass through your warehouse, Subiekt has nothing to track — availability sits with the supplier.
Here the source of truth is the supplier's file or API, and Subiekt handles documents rather than stock.
Several warehouses, different purposes
A shop-floor warehouse and a dispatch warehouse are two separate pools.
Sending the channels the sum of both ends with selling an item that is sitting on a shelf in the shop and was never meant to ship.
You have to name which warehouse feeds online sales.
Goods in production or assembled to order
Bundles and assembled products have availability derived from their components rather than their own stock level.
That needs its own rule, because naively reading the bundle's stock shows either zero or infinity depending on how it is kept.
The common conclusion: before setting the directions, answer the question of where the goods physically sit and who decides about them. The configuration is easy.
That answer is sometimes hard, and it determines everything else.
Stock levels: who is right when they diverge
This is the first question to settle and the only one that genuinely must have a single answer.
If Subiekt is the source of truth for goods, then the channel's stock is a reflection of Subiekt's, never the other way round.
That sounds obvious until three situations arrive where it is tempting to do otherwise.
First: a sale outside the system. Someone released goods from the warehouse against a document raised by hand in Subiekt.
The level dropped in Subiekt and that is correct — the channel will learn at the next sync. There is nothing to fix here.
Second: reserving against an order. An Allegro order has arrived but the goods have not left the warehouse.
If stock only drops on release, then for a few hours you are selling an item that already belongs to someone.
So an order should reduce availability immediately, whenever the warehouse document happens to be created.
Third: the buffer. On fast-moving goods it is worth holding less in the channel than you actually have.
A buffer is not a deception but an acknowledgement that synchronisation has latency and buyers click faster. One or two units of difference per line eliminates most out-of-stock cancellations.
The test is simple and worth running at the start: change a stock level in Subiekt and time how long it takes to appear in the channel. That interval is your window of risk, and it decides how large a buffer makes sense.
If you do not know what it is, you are picking a buffer by feel.
Prices: why one base price is not enough
In Subiekt you have a price. On Allegro you have a price, a commission, a delivery cost and competitors.
Those are two different worlds, and copying the price across one-to-one is the most common reason sales grow while margin does not.
A sensible model looks like this: the base price comes from Subiekt, and the channel price is derived from it by a rule. The rule accounts for what is channel-specific:
- Commission — different per category, and sometimes different for the same product on two platforms.
- Delivery cost, if you sell with free shipping — then delivery is part of the price rather than a separate line.
- A margin floor below which the price does not go, whatever competitors do.
The key principle: the margin floor is calculated from the purchase cost in Subiekt, not from the selling price. That is the only way automated pricing does not eat your margin in a high-commission category.
Without that link a discount looks reasonable in the channel and rather less so in the accounts.
Never run a second warehouse. If stock exists in two places and both can be edited, sooner or later they diverge.
You will not learn it from a report — you will learn it from the buyer whose order you had to cancel.
What not to do
Do not run a second warehouse. If stock exists in two places and both are editable, sooner or later they diverge — and you will not learn about it from a report, but from a buyer whose order you cancelled.
Do not issue documents outside Subiekt. An invoice issued elsewhere is a document someone has to enter manually later. That is moving the work, not automating it.
Do not synchronise everything. Goods you do not sell in a given channel do not need to be there. Narrowing scope at the start saves tidying up later.
Two practical things worth asking before rollout.
The Subiekt database has to be reachable whenever synchronisation should run. In practice that means a server or a machine that is up during those hours — not a workstation somebody switches off on the way out.
When Subiekt is briefly unavailable, orders still arrive into the system from the channels and nothing is lost. They reach Subiekt when the connection returns. Channel stock updates simply wait for data.
The second is which document the order should produce. That is an accounting decision rather than a technical one — settle it with whoever works on those documents before configuring anything.
Returns and corrections: where Subiekt has a limit
One thing worth knowing in advance, because it only surfaces on the first partial return.
Subiekt GT and Subiekt Nexo PRO handle corrections against the whole order. When a buyer returns an entire order, everything works without your involvement.
When they return one item out of five, the correcting document has to be finished by hand in Subiekt.
By comparison, some accounting programs — Fakturownia, wFirma, iFirma — accept a correction issued against a specific return, and so handle partial returns automatically.
That does not make them better in general: Subiekt is built for entirely different things and is usually chosen because the company runs its warehouse and all its documentation there, not because of how it issues invoices.
The practical conclusion: if you sell in a category with many partial returns, plan time for it. Clothing and footwear are the classic case — the buyer orders two sizes and sends one back.
At several hundred orders a month that is a real line in the schedule of whoever keeps your documentation, and better known upfront than discovered in January.
First run: what to expect
The first synchronisation behaves differently from daily work, and it helps to know what is normal.
It starts with narrowing
After years of use, a Subiekt product file holds withdrawn goods, services, packaging and test records.
Sending all of that to a channel means hours of cleanup later. Decide at the outset which product groups take part in online sales at all.
Matching runs on the symbol
A product in Subiekt and a product in the system are linked by symbol — for most companies that is the same thing as the channel SKU.
If symbols were assigned inconsistently over several years, this is where it shows.
That is good news, even though it does not look like it: better to see the mismatch in a matching report than in an order.
The first pass is slower. A few thousand records is not a one-minute operation. Schedule it outside selling hours, and do not draw conclusions about performance from the first run.
Orders go last
Products and stock one way first, confirmation that the numbers agree, and only then orders the other way.
Switching both directions on at once means that at the first discrepancy you cannot tell which one caused it.
Allegro integration: GT or Nexo PRO
From an integration point of view the difference comes down to how the system talks to the database, not to what is possible.
Both variants support the same set of flows. If you are choosing, decide on your accounting needs and your scale, not on which one "integrates better".
What is genuinely worth weighing in that choice:
- Document volume. How many documents you issue monthly and how many people work in the system at once affect day-to-day comfort more than anything integration-related.
- What you already have. If the company has run on Subiekt for years, migrating records, contractors and history is a project of its own — and it, not the integration, sets the timeline.
- The view of whoever keeps the documentation. They spend hours a day in that program. A choice that suits the integration and not them is the wrong choice.
What is not worth weighing: the claim that one version "integrates better".
The set of flows is the same, the boundary between Subiekt and the channels runs in the same place, and the differences concern how the connection is made rather than what can be achieved.
If someone offers integration as an argument for a particular version of Subiekt, it is worth asking which of the four flows the difference is supposed to affect.
Launch one channel, not all of them. The first is where you settle scope, prices and documents.
The second and subsequent ones repeat a working pattern — and if something diverges with two channels launched at once, you cannot tell which caused it.
One test
The test that settles it in five minutes
Sell one unit on Allegro and check whether stock in Subiekt changed without your involvement.
Then the reverse: change stock in Subiekt and check the channel.
If both directions work, the rest is configuration. If only one does — you have an export, not an integration.
The Subiekt GT integration · the Subiekt Nexo PRO integration
