KSeF integration for your own sales system in Poland: what to plan

If your company invoices in Poland, KSeF integration for your own sales system is in practice two separate obligations that are easy to confuse: sending the invoices you issue, and receiving the ones that come to you. KSeF — the National e-Invoice System (Krajowy System e-Faktur) run by Poland’s Ministry of Finance — is the state platform that structured invoices pass through in both directions. Receiving invoices from KSeF has covered every taxpayer receiving invoices since 1 February 2026. Issuing started in stages: from 1 February 2026 for taxpayers whose sales including tax exceeded PLN 200 million in 2024, and from 1 April 2026 for the remaining taxpayers required to issue structured invoices. This article is information, not legal or tax advice — confirm the scope of your own obligations with your accountant or tax adviser.

When does KSeF apply to your company, and what is still ahead

This is Polish national law, not an EU-wide rule: it binds taxpayers issuing and receiving invoices in Poland. Splitting the two duties apart is the most common misunderstanding — readiness to receive was required earlier than the duty to issue for most companies. A company with no duty to issue in February 2026 still had to be able to pull a purchase invoice out of the system.

Several deadlines are still open. Below is exactly what expires and when.

The legal bases indicated by the Ministry of Finance are the act of 5 August 2025 introducing the phased timetable, the regulation of 12 December 2025 on the use of KSeF (Dz. U. 2025 item 1815), and the regulation of 7 December 2025 on exclusions (Dz. U. 2025 item 1742).

Three places where KSeF touches your sales system

KSeF hooks into a custom system at three points: the moment a sales document comes into existence, the flow of purchase invoices, and document archiving and numbering. If sales are created in a shop, a B2B portal, a booking system or a field app, that is where you have to name the specific event after which the invoice should travel to KSeF.

Issuing. Pick one event in the process: order approval, goods release, service completion, or payment posting. That event becomes the send trigger. If an invoice can come into existence three different ways in your system, the integration will have three paths and three sets of errors to handle.

Receiving. Purchase invoices pulled from KSeF arrive as a stream of documents with no context — no reference to your purchase order and no indication of who ordered. Design a matching rule: by supplier tax ID, amount, date and the order number carried in the invoice body, with a manual queue for whatever is left. This is the classic problem of system integration inside a company, where you have to decide up front which system is the source of truth for each piece of information.

Archiving and the KSeF number. Every document that passes through the system gets a number assigned by KSeF. Store it next to the invoice in your own database and surface it where people actually need it: on the order record, on the warehouse document, in the customer service panel, and in the export to accounting. Without that, every “we never got the invoice” complaint turns into a manual search.

Design the offline24 mode up front, not as an exception

The offline24 mode is the situation where an invoice is created without a connection to KSeF and must be sent to the system by the next business day at the latest. If you own a sales system, this is not an edge case but a normal operating state — it affects anyone issuing documents in the field, at trade fairs, in a warehouse with poor coverage, or during a link outage.

From a project point of view that means four things to build: a queue of documents waiting to be sent, automatic retries with a growing interval, a visible invoice status (“sent”, “pending”, “rejected”), and an alert for a named person when a document still has not gone through. The retry mechanism itself is cheaper than reconstructing after the fact which invoices never arrived.

Your own API integration, accounting software, or an intermediary provider

There is no single right answer — the choice depends on where the invoice really comes into existence and how many documents pass through the company each month. The criteria below help you rule out options that cannot work in your process.

The same build-or-buy question returns for every other flow in the company, where the line runs between a ready-made automation platform and a custom integration.

There are four decision criteria: where the sales document is created, how many invoices a month go through the company, whether you need the invoice status back inside your own system, and who maintains this after go-live. If what you actually want is an answer to “what will it cost”, start with how many issuing paths your system has — the same mechanism drives mobile app development cost and every other build priced by scope.

What to scope in a KSeF integration project for your own system

The scope covers five areas that quotes tend to skip and that later generate the most work: environments, permissions, errors, logs, and the process owner.

• Environments. KSeF provides a test and a pre-production (Demo) environment alongside production. Plan testing on both before you move traffic — including correction invoices and the unusual cases in your own sales.
• Permissions and authentication. Establish who authenticates with what, and who grants permissions inside the company. Take the technical detail of authentication and the invoice schema structure from the current Ministry of Finance documentation, not from articles online — this layer changes most often.
• Error and retry handling. A rejected document needs a defined path: who gets notified, where the reason is visible, and what a re-send after a fix looks like.
• Logs and replayability. Record what was sent and when, with what result and what KSeF number. Without that, every audit and every complaint becomes an investigation.
• Process owner. Name one person on your side who owns KSeF day to day. An integration with no owner quietly stops working.

Before you order changes from the vendor of your existing system, ask a few questions that immediately show how much work stays on your side. The same set later feeds the document you use to write a software project brief.

The answers settle whether configuration is enough or you need a separate integration layer — and along the way they tidy up the rest of the data exchange between systems in your company, because an invoice is rarely the only document circulating between the shop, the warehouse and accounting. Stock is usually the flow worth settling next, since one stock figure shared by the shop and the ERP rests on the same source-of-truth rule as the KSeF number. If you would rather work this out with someone from outside, describe your document flow and get in touch with us — that is enough to start the conversation with specifics instead of guesswork.