KSeF and Stripe: why Polish companies struggle and how Zevio solves it
Stripe is great at collecting payments, but it does not issue invoices in KSeF. Zevio has that bridge built in: the invoice is created at checkout and sent to KSeF automatically.
Stripe is great at collecting payments, but it does not issue invoices in Poland's National e-Invoicing System (KSeF). From 2026, a Polish company selling through Stripe has to build the bridge between payment and KSeF itself - or do it by hand. Zevio has that bridge built in: the invoice is created the moment an order is placed and goes to KSeF automatically.
The Ministry of Finance wants to postpone penalties for KSeF errors until 2028, but the obligation itself does not disappear - it has applied since April 2026, and any B2B invoice issued outside the system is simply defective today. This is a good moment to put invoicing in order before mistakes start to cost money.
KSeF in brief: what already applies and what is ahead
KSeF is the government platform through which every B2B invoice issued by a Polish taxpayer passes. An invoice today is an XML file in the FA(3) structure, which the system validates and stamps with a KSeF number. A PDF sent by email no longer has legal force as a B2B invoice.
| Date | What changes |
|---|---|
| 1 February 2026 | Obligation to issue in KSeF for the largest companies; obligation to receive KSeF invoices for everyone |
| 1 April 2026 | The obligation to issue extends to the remaining businesses |
| 1 January 2027 | End of the transition periods - KSeF mandatory for all, including the smallest; KSeF number in transfers |
| 1 January 2028 | Planned start of financial penalties (draft act, previously 1 January 2027) |
The deferral of penalties is still a draft, not a regulation. The Ministry of Finance stresses that the obligation to use KSeF does not disappear, and the tax administration will act on invoices issued outside the system.
Where Stripe stops
Stripe has no native KSeF integration. Its invoices and receipts are payment documents, not structured invoices in the meaning of Polish VAT law. To sell through Stripe lawfully, a company has to build its own invoicing layer. In practice that means several problems at once:
- No tax ID in the order data. It is the buyer's tax ID (NIP) that decides whether an invoice must go to KSeF. Stripe Checkout can collect it, but that option is disabled by default.
- Translating events into XML. Every payment has to be turned into an FA(3) file, sent to KSeF, assigned a number, and that number saved against the order.
- Refunds and corrections. In Stripe a refund changes the payment state. In KSeF it requires a separate correcting invoice that references the KSeF number of the original - and it cannot be sent before the original receives that number.
- Duplicates on retries. If the invoice number is created at the moment of sending, a retried attempt creates a second invoice for the same order. The only fix is a correction to zero.
- Rejections and offline mode. An invoice rejected by KSeF legally does not exist, even though in the sales system the order looks invoiced. On top of that come offline-mode deadlines and QR codes on the visualization.
- State drift. An invoice may reach KSeF and the payment may later be canceled or refunded. Then every change requires a formal correction, also reported to KSeF.
The market answers this with patches: middleware between Stripe and an invoicing app, separate integrations such as Fakturownia + Stripe, even moving sales to a foreign Merchant of Record. Each of these works, but each adds another tool, another fee, and another place where the data can drift apart.
Why it hurts most in subscriptions
In one-off sales the problem appears once per order. In a subscription - every month, for every customer. A publisher with 2,000 corporate subscribers means 2,000 invoices to KSeF in every billing cycle, plus corrections on every plan change, refund or cancellation.
On top of that comes a mix of customers. Consumer invoices may, but do not have to, go to KSeF; business invoices must. A language school, a fitness club or a publisher serves both groups at once, so the system has to recognize who it is dealing with on every payment.
The third headache is failed payments. A card is declined, the system retries after three days, and the customer changes plan in the meantime. If invoicing lives in a different tool than the subscription logic, every such scenario has to be reconciled with accounting by hand.
How Zevio does it: the invoice at checkout, straight to KSeF
In Zevio, KSeF handling is built into the platform, not bolted on from outside. Stripe moves the money; Zevio makes sure a correct document stands behind every payment. The whole process happens automatically:
- The customer places an order or renews a subscription in Zevio's checkout - by card, BLIK or another channel.
- At the same moment Zevio issues the invoice based on the order data, including the buyer's tax ID.
- The invoice in the FA(3) structure goes to KSeF automatically.
- The KSeF number comes back to Zevio and is assigned to the order and the customer.
- The customer gets their document, and accounting sees a complete set of invoices without re-keying any data.
What this means in practice:
- One source of truth. Subscription, payment and invoice live in the same system, so there is nothing to reconcile between tools.
- Zero manual work each cycle. Renewals, retried payments and new orders invoice themselves.
- No extra middleware. No need to build a Stripe-KSeF bridge or pay for a separate integration.
- Calm before the deadlines. The company is ready for the full KSeF obligation, whatever date the penalties finally start.
Three paths to KSeF compliance when selling through Stripe
| Approach | How many tools | Who handles corrections and refunds | Implementation effort |
|---|---|---|---|
| Your own Stripe → KSeF bridge | Stripe + your own code + invoicing app | Your IT team | High, ongoing maintenance |
| Stripe + external invoicing app | Stripe + integration + invoicing app | Accounting, manual reconciliation | Medium |
| Zevio on Stripe | One platform | Zevio, automatically | Low |
Start now, not in December
The deferral of penalties buys time, but it does not remove the obligation. If you sell on a recurring basis through Stripe and your invoices still arise outside KSeF, or someone re-keys them by hand, Zevio puts this in order from the first order. Book a Zevio demo and see how the invoice goes to KSeF by itself at the moment of payment.
FAQ
Does Stripe issue invoices in KSeF?
No. Stripe collects payments and generates payment documents, but it does not issue structured FA(3) invoices in KSeF. For B2B sales in Poland a company has to build its own invoicing layer or use a platform with KSeF built in.
When does KSeF become mandatory?
The obligation to issue invoices in KSeF starts in stages: from 1 February 2026 for the largest companies, from 1 April 2026 for the remaining businesses, and from 1 January 2027 for everyone. Receiving invoices from KSeF has applied to everyone since 1 February 2026.
Since penalties are deferred to 2028, can I wait?
The deferral of penalties is still a draft, not the disappearance of the obligation. A B2B invoice issued outside KSeF is defective already today, and the tax administration may act. It is better to put invoicing in order before mistakes start to cost money.
How does Zevio send the invoice to KSeF?
At the moment of an order or subscription renewal, Zevio issues the invoice from the order data (including the tax ID), sends it in the FA(3) structure to KSeF, and assigns the returned KSeF number to the order and customer - automatically, with no extra middleware.