A custom integration with KSeF - Poland’s mandatory national e-invoicing system - pays off when invoices are created in your system, not in an accounting package. If your store, customer portal or B2B system is the thing that decides when a document is issued and for how much, then it has to talk to KSeF directly through the API: authenticate, send the invoice in the required format and receive the KSeF number back. In any other situation - when an accountant issues invoices in their own software, or an off-the-shelf plugin does the job - a custom integration is money spent for nothing.
KSeF is already live: mandatory for the largest taxpayers from February 2026, for everyone else from April 2026. So the question is not “whether”, it is “which route”.
What a KSeF API integration is
A KSeF API integration is a direct connection between your system and the national e-invoicing system, with no accounting package in the middle and no manual file uploads. Your system authenticates itself, builds the invoice in the required XML format, sends it, receives the assigned KSeF number and the confirmation of receipt, and then stores both against the order.
The classic setup looks different: the store generates a PDF, someone retypes the data into an accounting package, and the accounting package sends the document to KSeF. With a custom integration that middle link disappears.
When an off-the-shelf solution is enough
An off-the-shelf plugin or an integration on the accounting side is enough for most small and mid-sized companies. If you issue a few dozen invoices a month in one standard variant and your accountant uses an online package that handles KSeF on its own, there is nothing for you to integrate.
The same goes for a store that pushes orders to an ERP or to a platform like Baselinker, the order-management hub most Polish stores run on, and issues invoices there. The route to KSeF then runs through that tool, and your job ends at making sure the order data is complete. What that path looks like in practice I described in the piece on integrating WooCommerce with an ERP and e-invoicing.
When a custom integration makes sense
A custom KSeF integration makes sense when the invoice is part of your process rather than a separate accounting chore. The signals that settle it in practice:
| Situation | Recommendation |
|---|---|
| A few dozen invoices a month, one simple variant | Off-the-shelf plugin or online accounting |
| The store issues invoices automatically once an order is paid | Custom integration |
| Subscriptions, recurring plans, cyclical billing | Custom integration |
| Advance, final and correction invoices generated by the system | Custom integration |
| A B2B customer portal where the buyer downloads documents themselves | Custom integration |
| Several companies or several sales channels in one system | Custom integration |
| The accountant issues invoices and the system knows nothing about them | Do nothing on the system side |
There is one common denominator behind all those “yes” rows: the volume of documents or the complexity of the rules means the manual link in the middle stops keeping up. At two hundred invoices a month, retyping data costs time and guarantees that sooner or later one goes out with the wrong amount.
What such an integration has to handle
A good KSeF integration is not “send the XML and you are done”. It is eight elements, and every one you skip comes back later as an outage:
- Authentication - the system logs into KSeF with the company’s credentials. Credentials live outside the code, in environment variables, never in the repository
- Building the invoice against the current schema - a structured invoice is XML conforming to the published schema; versions do change, so there has to be one place where you swap it
- Mapping data from your system - order lines, VAT rates, units of measure, discounts, shipping cost, buyer details. The most tedious part and the source of most errors
- Sending and receiving confirmation - once the document is accepted, KSeF assigns it a number and issues an official confirmation of receipt. Both get stored against the order, because that is your proof of issue
- A retry queue - a rejection or a temporary outage must never end with an invoice quietly vanishing. Failed sends go back into the queue and you get a notification
- Emergency and offline mode - the regulations allow for situations where an invoice is created outside the system and reaches it later. Such a document has to be flagged and submitted afterwards
- Corrections and cancellations - an invoice once sent to KSeF does not disappear, you fix it with a correction. You handle that scenario from day one, not in a panic at the first mistake
- Archive and preview - you and your customer need a readable version of the document together with the KSeF number, even though the original is XML
On top of that comes something easy to forget when quoting: the test environment. KSeF provides one separately, and the whole rollout goes through it before it touches real invoices.
KSeF and an online store - what breaks most often
In an online store the problem is not the sending itself, it is the quality of the data going into it. The tax system is mercilessly literal: either the data is complete and correct, or the document comes back rejected. The most common stumbles in WooCommerce and similar stores:
- The VAT number in a free-text field with no validation - the customer types it with spaces, with dashes or with a PL prefix, and the integration receives junk
- No distinction between B2B and B2C - not every order should become an invoice; consumer sales follow different rules
- Shipping cost and discounts - in the store they are auxiliary lines, on the invoice they need their own VAT rate and their own place
- Rounding - the store calculates from gross, the invoice often from net; a one-grosz difference blows up the whole document
- Foreign orders - different rates, different markers, sometimes a procedure the store never anticipated
That is why, when rolling this out in a store, I start with a review of the order data rather than with code. If the store collects data sloppily, no integration will fix that - a corrected purchase process will.
The rollout step by step
This is the order I do it in. It matters, because KSeF problems usually start with the data, not with the connection.
- Review of the current state - who issues invoices today, in what, and how many there are. This is often where it turns out a custom integration is not needed
- Data audit - real orders from recent months checked for completeness: VAT numbers, addresses, rates, edge cases. The output is a list of fixes in the store
- Document map - which invoice types the system has to issue and what triggers them (payment, shipment, end of billing period)
- Connecting to the test environment - authentication, the first document, receiving the number and confirmation
- Building the invoice generator - mapping data onto the current schema, with tests on the edge cases from step 2
- Queue, retries, notifications - this decides whether the integration survives its first outage
- Volume testing - a few dozen documents of different types, corrections included, on the test environment
- Switching to production with an observation period - for the first few weeks I watch every rejection and close the gaps
Step 2 is often longer than steps 4-6 combined, and that is normal. Talking to an API is predictable; the data in a store rarely is.
What it costs
I quote the rollout after reviewing the system, because the spread is wide. A simple scenario - one invoice type, one order source, clean data - is a different job from a B2B portal with subscriptions and corrections. Four things drive the price:
| Element | What affects it |
|---|---|
| Range of documents | Plain sales only, or advances, corrections and recurring too |
| Data quality in the system | How much has to be fixed at checkout and in the database |
| Number of sources | One store, or store plus marketplace plus B2B portal |
| Maintenance | Schemas and requirements change, someone has to keep watch |
My fixed-bid projects usually land in the range of around 5,000-10,000 PLN net (Polish market rates), and a KSeF integration for a typical store falls inside those brackets. You get the quote in writing before we start.
Maintenance is a separate line: requirements on the tax system side do get updated, and an integration nobody looks after will start collecting rejections at some point. Which is why for some clients it goes into ongoing technical care - Basic from 1,000, Pro from 2,000, Premium from 3,500 PLN net per month.
The most common rollout mistakes
- Starting from the code, not the data - the integration works on a sample order and falls over on real traffic
- No retry queue - one temporary outage and some invoices simply do not exist, and nobody finds out
- Corrections skipped - because “we will not need them for now”. You will, usually in the first month
- Credentials in the repository - that is not an oversight, that is a leak of company data
How to check this with no commitment
Before we quote anything, I do a free diagnosis: I look at where your invoices come from today, how many there are, what the order data looks like and whether a custom integration is needed at all. Sometimes it ends with the recommendation “leave it as it is, tidy up two fields in the form” - and that is an honest answer too.
If the integration does make sense, you get the scope and the quote in writing before we start, along with the list of fixes on your side. On bigger rollouts the review goes beyond invoices and touches the whole architecture of the company’s B2B system.
Frequently asked questions
Do I need my own KSeF integration? Not if your accountant issues invoices in their own software, or a system you already use does it. A custom integration is only needed once documents are created automatically in your store or portal and there is no sense in retyping them by hand.
How long does a KSeF integration in a store take? With clean data and one invoice type it is a matter of weeks, not months. The biggest unknown is the state of the order data - if the store collects VAT numbers without validation and has inconsistent VAT rates, the fixes take longer than the API connection itself.
Does a KSeF integration work with WooCommerce? Yes. WooCommerce gives full server-side access to order data, so you can send invoices from it directly or through an intermediate layer. The choice depends on whether the store is your only sales source.
What happens when KSeF does not respond? A properly built integration parks the document in a queue, retries the send and tells you something is waiting. The regulations also allow for a mode where an invoice is created outside the system and reaches it later - that has to be handled in the code from the start, not bolted on during an outage.
Running a store where something does not work the way it should? I build and rebuild WooCommerce stores - from a single fix to reworking the whole sales flow. Tell me what you are dealing with and I will send back a scope and a price.