Subiekt nexo, inFakt or KSeF direct — three routes to invoicing a multichannel seller

A single-channel seller has one source of orders and usually one invoicing tool. The moment a second and a third channel appear, a question nobody asks at the start becomes unavoidable: where should the invoice physically be created, when orders arrive from a marketplace, a second marketplace and the shop at the same time?

There are three real answers, and none of them is universally better. This post describes all three the way they actually work, so you can pick the one that fits what the business already runs.

The specifics here are Polish — KSeF is Poland’s national e-invoicing system and it is already in force — but the shape of the decision is not. Any market moving to a clearance model asks the same question, and if you are an agency delivering multichannel work for Polish clients, this decision lands on your desk early.

Why this is a decision at all

With one channel, the invoice is created wherever the order is created, and that’s the end of it. With three channels, three temptations appear: issue an invoice in the marketplace panel, another in the shop, a third by hand for orders from the second marketplace. That holds up exactly until the first busy month.

Then the unplanned problems start: numbering drifts between tools, one transaction ends up with two documents, a correction issued in one place has no counterpart in the other, and the accountant receives three exports to reconcile manually. On top of that sits KSeF, which is no longer optional — and every additional place that issues invoices is another place that has to be compliant with it.

The fix is structural rather than a tooling choice: one place where invoices are created, fed by orders from every channel. The only open question is which place.

Route one — stay on Subiekt nexo

Subiekt nexo is an ERP from the Polish vendor InsERT, long established in Polish retail and trading companies. For a lot of sellers it is where sales and stock already live — from well before multichannel entered the picture. Replacing an invoicing tool because a second sales channel appeared is often a bigger risk than adding the integration.

In OpenLinker this route runs through the Sfera bridge — a Windows service running on the Subiekt machine that talks to the ERP through Sfera, InsERT’s programmatic API. It issues invoices and receipts, issues corrections, reads back the KSeF status of an issued document, and surfaces a PDF link when the bridge returns one. It was the first adapter built on OpenLinker’s invoicing port, which in practice means it is the longest-proven of the three routes.

It carries one architectural consequence worth naming up front: Sfera is a Windows component, so somewhere in the deployment there has to be a Windows machine running Subiekt, reachable from OpenLinker. If Subiekt already runs on a server or an office machine, that is a description of reality, not a new cost. If the plan was to keep everything in Linux containers, it is a genuine trade-off to weigh.

One detail matters specifically for multichannel: on the automatic path, the document type is derived from the presence of a Polish NIP tax ID on the order — with a NIP it becomes an invoice, without one a receipt. Marketplace orders frequently carry no NIP, so this decides what gets issued before anyone looks at it. On the manual path the operator picks the type.

This route fits when the client already runs Subiekt and has no reason to replace it. Orders from every channel land in the same familiar tool, documents are created where the accounting team already knows to look for them, and nobody learns a new accounting system in the same month a sales channel is added.

Route two — inFakt as an intermediary to KSeF

inFakt is a widely used Polish online invoicing service, popular with sole traders and small companies whether or not they sell on multiple channels. In OpenLinker the inFakt adapter issues documents and reads back the KSeF clearance status for you. inFakt is the intermediary here, so you never handle communication with the government system yourself.

That is the whole point of this route: a company stands between the shop and KSeF whose job is to keep up with changes on the state system’s side. When the schema or the API behaviour shifts, that is their problem to solve rather than yours. You pay for it with a subscription and with one more party inside your sales process.

This route fits when the business wants a single, friendly invoicing tool that absorbs the technical side of KSeF compliance, leaving only the outcome visible — an issued invoice and its status. It fits particularly well when there is no ERP deployed and no appetite to deploy one purely to issue invoices.

Route three — KSeF with no intermediary at all

The third option is a direct connection to the KSeF 2.0 API, with neither Subiekt nor inFakt in between. OpenLinker handles issuing invoices in FA(3) — the structured XML schema KSeF requires — plus the clearance process, the KSeF number, the UPO, and KOR corrections (KSeF’s correction-document type).

One thing is worth understanding regardless of which route you choose: the whole process is asynchronous. It is not a single fire-and-forget call. The document is submitted, the system polls KSeF for status, and only then collects the UPO. That means there is a window between an order being placed and its invoice being confirmed, during which the document exists but is not yet cleared — and the process around it has to account for that. KOR corrections travel the same path: submit, poll, UPO.

This route fits when you would rather have one fewer thing in the chain — one fewer component that could break or change its terms outside your control. There is no intermediary translating KSeF’s technical responses into something simpler. What you see sits closer to the government system itself, with nothing in between. So the question is which matters more: fewer dependencies, or less technical language day to day.

How to choose

	Subiekt nexo	inFakt	KSeF direct
Who talks to KSeF	Subiekt / InsERT	inFakt	your own system
Links in the chain	1	1	0
Extra infrastructure	Windows host running Sfera	none	none
Language of responses	familiar from Subiekt	simplified	technical, API-level
Best fit	Subiekt already deployed	starting fresh / sole trader	wants the fewest dependencies

In three sentences:

If Subiekt nexo is already installed and in use, switching purely because of multichannel rarely pays off — integrating with what exists is usually simpler than migrating accounting.

If the business is starting from scratch, or is a one-person operation, inFakt as an intermediary removes the technical detail of KSeF at the price of one more service in the stack.

If the priority is the least possible uncertainty between the shop and the state system, and technical responses are not a problem, a direct KSeF connection removes the intermediary at the cost of that convenience.

None of the three is worse. They differ in what you already run and how many intermediaries you are willing to maintain between a sale and an invoice.

What is common to all three

Choosing an invoicing route does not solve the problem we started with. An invoice has to be created from an order, and orders arrive from several places at once. So before comparing Subiekt with inFakt, make sure there is a layer collecting orders from every channel into one queue — without it you are still retyping data by hand, just into a nicer tool. We covered how that layer works, and how it breaks, in how order and inventory sync actually works.

In OpenLinker all three invoicing adapters sit behind the same port — InvoicingPort. For a seller, that has one practical consequence: changing invoicing route is not a rebuild. If invoices go through Subiekt today and the business moves to a direct connection in two years, the adapter changes; the way orders reach the system does not.

For an agency the consequence is different and more interesting. The port is part of the plugin SDK, so an invoicing integration a client insists on — a local accounting package, an in-house finance system — is an adapter you write against a stable contract, not a change to the core you then maintain forever. That is the same argument we make about marketplace adapters on the architecture page, applied to the finance side of the stack.

What is not there yet

Fakturownia, iFirma and wFirma are marked as planned on the integrations scorecard — those adapters do not work yet. If a client runs one of them, today that means choosing one of the three routes above or waiting for the next adapter.

The scorecard is a living document, not a fixed roadmap. If a particular invoicing tool is on a client’s requirements list, tell us or open a feature request on the repository — the order adapters get built in follows what sellers and implementation agencies actually ask for.

What to do next

• Find out where invoices are created today. If the answer is more than one place, that is the first problem to fix, before any tool is chosen.
• Check that every place issuing invoices today is KSeF-compliant. KSeF is already in force; confirm the client’s specific position with their accountant and the official KSeF portal.
• Cost the accounting migration before concluding that an existing ERP has to be replaced. Usually it doesn’t.
• See the live demo on sample data to judge how orders from several channels land in one queue, before installing anything.

To be precise about the limits: OpenLinker is alpha, pre-1.0, and self-hosting is a real trade — somebody maintains the server, the updates and the monitoring. You, an implementation partner, or us. In exchange nobody meters your orders, and invoice data stays on your own server.