Subiekt GT vs nexo PRO for E-commerce Integration in Poland

Subiekt GT and nexo PRO integration with e-commerce is usually framed as a software choice. In practice, it is an operations choice. The real question is how much disorder your setup can absorb before warehouse staff, accounting, and support start patching the gaps manually. In Poland, that limit shows up quickly. Once Allegro orders, VAT-sensitive document flows, courier mappings, and stock reservations are part of daily work, a cheap connector stops being a savings move. It becomes postponed rework.

Allegro order flow and VAT document rules are not edge conditions in Poland. They shape the integration from the start. If an Allegro order lands with the wrong payment or delivery mapping, the import may still succeed, but the document path inside insERT becomes unreliable. Reservations, invoices, or receipts start appearing inconsistently, and accounting ends up correcting what the connector was supposed to automate.

My view is not neutral: low-cost packaged connectors are often sold on setup speed, while the real bill arrives later in exception handling. A polished demo tells you almost nothing about whether the integration will survive duplicate events, stock pressure, or month-end document control.

Choose the architecture by operational complexity, not by license price

A direct connector can be enough when the business runs one store, one warehouse, modest order volume, and simple document rules. In that setup, a few minutes of sync delay may be acceptable, and the team can resolve occasional exceptions without turning support into a daily repair desk.

Add Allegro, warehouse-specific stock logic, or channel-specific order handling and the economics change. At that point you are not buying data transfer. You are buying retries, logs, mapping control, and clear ownership when something breaks.

A better buying filter is simple. If you expect to add channels within a year, need support staff to see failed events without a developer, or cannot tolerate duplicate documents, a connector-first decision is usually false economy. The integration patterns described in ERP, WMS, and marketplace integration start mattering earlier than many teams assume.

Here is the debatable part: in Polish multi-channel commerce, most connector-first purchases above trivial scale are not cost optimization. They are deferred rework dressed up as prudence.

Budget needs to be framed honestly. A connector may look cheaper at purchase time, but if the business already runs two channels and non-trivial stock logic, the first thing that breaks is rarely the sync itself. It is support capacity. Someone starts reconciling orders manually, accounting corrects documents, and the business quietly pays for missing architecture through labor.

Where Subiekt GT and nexo PRO differ in real integration work

These systems are often compared as if they were interchangeable ERP endpoints. In live projects, they are not. The difference is less about feature slogans and more about the environment each product usually sits inside.

Subiekt GT is common in Poland and often lives inside older operating habits: desktop workflows, scheduled scripts, long-running add-ons, and undocumented workarounds around stock or document creation. GT can absolutely support e-commerce integration. The risk is that many GT environments carry hidden dependencies that only show up after launch.

nexo PRO is often the cleaner base when the business expects process changes, additional channels, or a more explicit extension model. That is not vendor marketing. It is an implementation judgment. In newer deployments, nexo PRO setups tend to have fewer historical patches and less ambiguity around workflow ownership.

I would not frame the choice as “can GT integrate?” It can. The better question is what you are inheriting. If the GT environment depends on side scripts, manual exports, or one employee who knows which workstation action fixes a stuck order, the integration budget should include discovery and cleanup from day one.

For a new implementation or a major redesign, nexo PRO is often the lower-risk base for long-term e-commerce work. The reason is straightforward: inherited process debt usually causes more failures than the ERP label itself. insERT documentation and version-specific technical resources should be checked before any vendor locks assumptions about methods, editions, or extension options.

Migration is not automatically the right answer. A disciplined GT setup with one or two channels, documented rules, and limited customization can remain a sound platform. But if manual exceptions are already treated as normal process, the logic starts to resemble connecting a legacy system to a new product: isolate interfaces, document hidden rules, and stop pretending that tribal knowledge is architecture.

What to design before launch: stock, documents, mappings, and failure handling

Most teams should keep phase one narrow: catalog, stock, orders, and document or status feedback. Trying to automate every adjacent process at launch usually expands the failure surface without improving commercial outcomes.

Start with product identity. SKU should usually be the cross-system key. Product names, marketplace titles, and promotional labels change too often to carry integration logic safely.

Then audit master data before enabling sync. Duplicate products, reused inactive codes, inconsistent VAT assignments, unit mismatches, and conflicting warehouse mappings are not cosmetic issues. They are launch blockers. If one SKU means different pack sizes across systems, the integration is already unstable.

Document logic matters more in Poland than many storefront-led projects assume. An imported order may need to create a reservation, sales order, receipt, invoice, or wait for payment confirmation. That branch can differ between prepaid orders, cash on delivery, and marketplace flows. If the integration cannot map payment method and channel to the right document path, accounting corrections pile up fast.

Courier and payment mapping is another routine failure point. Labels such as InPost Locker, DPD Courier, PayU, BLIK, or COD are only storefront values. On the ERP side, they must map to shipping dictionaries, payment dictionaries, and document rules in a deterministic way. When a new delivery method appears in the store, the integration should fail visibly, not guess.

• Missing SKU: reject the line and place the order in an exception queue.
• Payment mapping failure: import the order into a pending state without document creation.
• Shipping mapping failure: hold fulfillment until manual classification.
• VAT inconsistency: block document creation and alert support.

Stock publication should usually be based on available stock after reservations and operational buffer, not raw physical stock. That sounds obvious, yet it remains one of the more expensive mistakes in Polish multi-channel commerce. On a store-only setup, scheduled sync may be enough. On Allegro plus store sales for fast-moving SKUs, stock updates should react to order creation, cancellation, and warehouse receipt events, with scheduled reconciliation as a safety layer.

One Polish retail setup selling through its own store and Allegro, with around 8,000 SKUs, initially looked like a performance problem because order import felt slow. The commercially important issue was elsewhere. The storefront published stock from a field that ignored reservations, so sellable stock was overstated during peak periods. Orders imported correctly, but support absorbed the damage through cancellations, customer messages, and manual document cleanup. After the mapping changed to available stock with a small operational buffer and event-driven updates on order creation, the pressure moved out of support and back into the system where it belonged.

Exception handling should be treated as a normal operating condition. ERP locks, duplicate webhooks, delayed payment confirmations, and renamed shipping methods are routine. The integration should queue events, retry transient failures with backoff, and enforce idempotency using a stable external order ID plus channel identifier. If the same event arrives twice, the second one should update or be ignored by rule, never create a second sales document.

Data flow that usually survives real order traffic

The safest pattern is not the most glamorous one. Keep the storefront and marketplace channels as event sources, pass those events through a controllable integration layer, validate mappings there, and only then create or update records in Subiekt GT or nexo PRO. That middle layer does not need to be heavy enterprise middleware, but it does need memory, logs, and rules.

A durable order flow often looks like this:

1. Order created in store or marketplace.
2. Integration layer receives the event and assigns a unique external reference.
3. Validation checks SKU, warehouse, payment, shipping, VAT, and customer rules.
4. If validation passes, the ERP document path is selected by channel and payment state.
5. If validation fails, the order is parked in an exception queue with a readable reason.
6. Stock and status updates are returned to the selling channel after the ERP action succeeds.

That sequence matters because many failed projects reverse it. They create ERP documents too early, then try to repair bad mappings after the fact. Once accounting-sensitive documents exist, cleanup becomes slower, riskier, and more political.

For teams building a custom integration layer, even a simple idempotent handler is better than blind document creation:

def import_order(event):
    key = f"{event.channel}:{event.external_order_id}"

    if already_processed(key):
        return {"status": "ignored_duplicate", "key": key}

    validation = validate(event)
    if not validation.ok:
        queue_exception(key, validation.errors)
        return {"status": "queued", "errors": validation.errors}

    document_type = resolve_document_path(
        channel=event.channel,
        payment_method=event.payment_method,
        payment_status=event.payment_status,
        delivery_method=event.delivery_method
    )

    result = create_erp_document(event, document_type)
    mark_processed(key, result.document_id)
    return {"status": "imported", "document_id": result.document_id}

The code is not the point. The operating rule is. Never let duplicate events or unmapped values create accounting-side artifacts silently.

Validation rules that deserve explicit ownership

Teams often talk about “sync” as if all fields were equal. They are not. Some fields are informational. Others decide whether the warehouse ships the right goods and whether accounting closes the month without manual repair.

At minimum, validate these before document creation:

• SKU identity: one external SKU must resolve to one ERP product and one unit logic.
• Warehouse routing: the order must know which stock pool it is allowed to consume.
• Payment mapping: storefront and marketplace methods must map to ERP dictionaries without fallback guessing.
• Delivery mapping: courier and pickup methods must resolve to known fulfillment rules.
• VAT path: tax treatment must align with document type and customer context.
• Customer deduplication: repeated orders should not create fragmented customer records unless the business explicitly wants that behavior.

If a vendor cannot explain where those rules live, who changes them, and how failures are surfaced, the integration is underdesigned. I have seen teams spend more time debating API access than deciding who owns the payment dictionary. The second problem causes more real damage.

Go-live and ownership: keep the first release narrow

Testing should follow the real commercial path, not the clean demo path. One successful prepaid order proves almost nothing. You need prepaid and COD, marketplace orders, duplicate events, missing SKU, changed VAT mapping, partial cancellation, and return handling. If bundles or customer-specific prices exist, test them before launch, not after the first complaint.

Go-live should be blocked unless three conditions are true: failed events are visible, duplicate documents are prevented, and support can trace what happened without asking a developer to read raw logs. If that visibility is missing, the integration is not production-ready.

Keep the first release narrow. Catalog sync, stock sync, order import, and document or status feedback are enough for phase one. Older environments benefit from staged rollout discipline similar to de-risking a legacy migration, even when the ERP itself is staying in place.

Post-launch ownership should be explicit before the switch is flipped. The store team should own storefront configuration. The ERP partner should own ERP-side settings and document logic. The integration owner should own mappings, retries, queues, and monitoring. Without a coordinator, incidents bounce between vendors while the business absorbs the delay.

The first month needs a short KPI set, not a giant dashboard: rejected order rate, stock mismatch incidents, duplicate customer creation, sync delay for stock-critical events, and mean time to resolve exceptions. If those indicators worsen while order volume grows, the integration is commercially unstable even if the connector still appears to be working.

If you need a partner for that layer rather than another plugin, our Integrations & APIs services page shows the scope involved in building reliable ERP-commerce flows.

Subiekt GT and nexo PRO integration with e-commerce works when the architecture matches the operating model and the failure paths are designed as carefully as the happy path. The wrong design often looks acceptable for the first few weeks, then breaks in a very specific way: duplicate or misclassified orders start generating the wrong document flow during peak sales, and support teams become the retry mechanism the software never had.