Baselinker will not guess how you invoice - but once you set it up, issuing and sending invoices to KSeF stops being your job. KSeF is Poland’s National e-Invoice System, a government inbox that receives every sales invoice in structured XML form; it has applied to the largest companies since February 2026 and to everyone else since April 2026. In Baselinker you have two routes: either Baselinker issues the invoices and sends them to KSeF itself, or Baselinker passes the order to an accounting program and that program does the rest. Picking one of them is the single most important decision in the whole setup - and you have to make it before you click anything.
Below is the order I use with clients: first the decision, then the data and the token, then numbering, and the automation last. The reverse order ends in duplicate invoice numbers.
Two routes for issuing invoices - which to pick
Baselinker can be either the place where the invoice is created, or just a relay to accounting. Both work, but not equally well for everyone.
| Route | For whom | What to watch |
|---|---|---|
| Invoices in Baselinker | A store with a single VAT rate that wants everything in one dashboard | Baselinker is the source of numbering - accounting follows its numbers, not the other way round |
| An accounting program (wFirma, iFirma, Fakturownia, Subiekt, Comarch - the common Polish options) | A company with a permanent bookkeeper, B2B sales, credit notes, prepayments, foreign sales | Baselinker passes order data, but the accounting program owns the structure and the send to KSeF |
The rule I apply: if you have a bookkeeper who already works in a particular program - invoice there. Issuing in two places is the simplest way to get two invoices for one order. I laid that second route out in the piece on connecting an accounting program to KSeF.
What to prepare before you open the settings
Gather this on one sheet of paper - it turns the configuration into a single session instead of a week:
- Full seller details - a name matching the register, VAT number, address, bank account
- The series and numbering format you use today, plus the last number from the old system
- VAT rates for all product groups, including exempt and foreign sales
- KSeF access - permission to issue invoices on behalf of the company and a way to authenticate
If your orders themselves are a mess - some not pulling in from marketplaces, some arriving without invoice details - fix that first. An invoice is only a reflection of the order, and the causes of missing data I covered in the piece on orders that do not reach Baselinker.
The KSeF token - where to get it
A KSeF token is a long string that replaces a signature on every invoice send - the integration identifies itself with it instead of asking you for a qualified electronic signature every time. You generate it once, on the Ministry of Finance side, not in Baselinker.
- Log into the KSeF taxpayer application as the company - with a qualified signature, a company seal or the owner’s trusted profile
- Check that you hold permission to issue invoices on behalf of that VAT number; if somebody else invoices, grant it to them separately
- Generate a token with issuing permission (a narrower one is enough for downloads only)
- Copy it immediately - once the window closes the token is shown only once and you have to generate a new one
- Do the same in the test environment if you want to rehearse without legal consequences
What helps: keep the token where you keep company passwords, not in an email and not in a note on your desktop. Whoever holds the token can issue invoices on behalf of your company - this is not an ordinary integration key.
Baselinker settings step by step
You do the configuration in the invoicing module in the Baselinker dashboard. Tab names change between dashboard revisions, so go by meaning rather than by exact labels:
- Issuer details - fill in the full company data; this is what goes into the XML structure and there is no room there for shortcuts like a company name with no address
- Numbering series - set the format and the starting number, more on that in a moment
- The KSeF section - paste in the VAT number and the token, pick the environment (test first)
- Issue one trial invoice from a real, completed order
- Check the send status - an invoice accepted correctly gets a KSeF number and an UPO, the official confirmation of receipt
- When the trial passes - switch to the production environment and repeat the test on one real order
The KSeF number and the UPO are the only proof an invoice reached the system. As long as a document sits in a sending status or in an error, it has formally not been issued - that is the one thing worth checking daily during the first week.
Invoice numbering - where most of the mess comes from
Numbering has to be continuous and unique across the company, not across a tool. If Baselinker issues invoices in parallel with your accounting program and both start at one, you get two documents with the same number - and a breakdown at month-end close.
- One source of numbering. Choose the system that assigns numbers and set the other one to read or import only
- Separate series where the flow is separate - one for marketplaces, one for B2B, one for credit notes
- Continuity when moving - starting mid-year, set the initial number higher than the last one from the previous system
Invoices for marketplace orders have their own traps with buyer details - I gathered those in the piece on invoices for Allegro orders.
Automatic issuing - when to turn it on, when not
Baselinker can issue an invoice by itself once an order enters a chosen status - and that is where the entire time saving in this integration lives. You set it in automatic actions: the condition is a status change, the action is issuing the invoice.
The right moment for automation is the status after payment and after the order is picked - not “new”. An invoice for an order the customer will still cancel means a credit note, and in KSeF a credit note is a separate document, not an edit.
Do not turn the automation on straight away if:
- you sell at several VAT rates and are still tidying them up
- you have a lot of foreign or foreign-currency orders
- some customers ask for an invoice after the fact and the rest get a receipt
- orders are missing VAT numbers on business sales
In those cases it is better to issue manually for the first few weeks and watch what breaks. More scenarios in the piece on automation via the Baselinker API.
The invoice fails validation - what that means
Structure validation is a check that the XML file matches the schema KSeF requires. A rejection almost always means one field is missing or in the wrong form, not that the integration is broken. The most common cases:
| Symptom | What is wrong | What to do |
|---|---|---|
| Authentication error on send | The token expired, comes from a different environment or lacks issuing permission | Generate a new token in the environment you are working in |
| Rejection over buyer details | VAT number in the wrong format, missing country code, missing address on a business sale | Fix the data in the order, issue the document again |
| Error on document line items | VAT rate as text instead of a code, zero price, a discount entered as a negative line | Standardise rates in the product catalogue, show discounts in the line price |
| Date error | Sale date earlier than allowed or in the future | Set the sale date to the day the order was fulfilled |
| Document “sending” for several hours | The send went out but the confirmation did not come back | Do not issue a second invoice - check the status by number, a duplicate has to be corrected later |
The rule on every rejection: fix the source in the order or the product record first, only then reissue. Patching the invoice alone means the next order like it will break in exactly the same way.
What KSeF in Baselinker does not solve
A few things stay on your side no matter how well you configure the integration:
- Receipts do not go to KSeF - retail sales have their own fiscal flow, and an invoice issued against a receipt is a separate case, described in the piece on receipts and JPK reporting in a store
- Sending the invoice to the customer is still your business - a document being in KSeF does not mean the customer has seen it
- Credit notes and prepayments need an accounting decision, not a technical one
- Foreign sales follow separate rules and are usually the reason invoicing stays in the accounting program
If your store runs on WooCommerce, it is worth looking at the whole chain - from order to accounting - instead of patching one segment; I described that in WooCommerce, ERP and e-invoicing. With an unusual document flow, a custom integration with the KSeF API sometimes works out better than bending a ready-made module into shape.
When it is worth outsourcing
If you have one store, one VAT rate and one numbering series - you will do this yourself in an afternoon and this article is enough. It is worth handing over when several sales sources are involved, product data needs tidying up, or invoices have to line up with stock and an ERP.
With me it starts with a free diagnosis: I look at the order flow, the product catalogue and how you invoice today, then say plainly whether configuration is enough or whether something has to be closed off on the store side. For bigger work - integrations, optimization - you get a written quote before the start, and projects like that usually fit in the 5,000-10,000 PLN net range.
Frequently asked questions
Does Baselinker send invoices to KSeF automatically? Yes, once the invoicing module is configured and the token is in place, sending can happen automatically after an order status change. For the first week, though, it is better to issue manually and check that every document gets a KSeF number and an UPO.
Do I need a KSeF token to issue invoices in Baselinker? Not to create the invoice in the dashboard. The token is needed to send it to KSeF, because that is what authenticates the integration in place of a qualified signature. Without a token the document exists in Baselinker but has formally not been issued in the system.
What do I do when an invoice fails structure validation? Read the rejection message - it points to a specific field. Most often it is the buyer’s VAT number, a missing address, a VAT rate or the sale date. Fix the data in the order and reissue the document; do not issue a second invoice “just in case”.
Is it better to invoice in Baselinker or in an accounting program? If you have a bookkeeper working in a particular program, invoice there and use Baselinker to pass orders across. With simplified bookkeeping the invoicing module in Baselinker is enough. The worst option is issuing in both places at once.
Sitting on this yourself and unsure where to start? I speed up and repair existing sites and stores - Core Web Vitals, outages, the features that are missing. Tell me what is happening and you will get a concrete quote with a date.