KSeF for WooCommerce: what Polish stores need to prepare

If you run a WooCommerce store that sells in Poland, KSeF is one of the most significant invoicing changes on the horizon. It moves invoicing away from PDFs and email attachments towards structured electronic documents issued through a central government platform. The good news is that almost all of the work you can usefully do today is data hygiene, and data hygiene pays off immediately regardless of when your phase begins. This guide explains what KSeF is, who it affects, what clean invoice data actually looks like, and how Polski for WooCommerce prepares your shop without pretending to be your accounting system.

What KSeF is and why it matters for your store

KSeF (Krajowy System e-Faktur, the National e-Invoicing System) is Poland’s central platform for issuing and receiving invoices. Instead of generating a PDF and emailing it to a customer, a seller submits a structured e-invoice to KSeF. The system validates and registers it, assigns it an official identifier, and makes it available to the buyer. The invoice stops being a document you design and becomes a record the state holds.

The key shift is that the invoice becomes a defined data structure rather than a free-form file. A PDF can hold any layout you like; a structured invoice must contain specific fields in a specific format so the system can read it automatically. There is no room for “the accountant will figure it out” when a missing company name or a malformed tax number causes a rejection at submission.

For a WooCommerce store owner this matters because invoice data can no longer be loosely formatted. The buyer’s tax number, company name, address, line items and VAT rates all need to be captured cleanly and consistently, because they feed directly into the structured document. Anything you collect as messy free text at checkout becomes a problem at invoicing time.

Who is affected and the staged rollout

KSeF is being introduced in phases rather than all at once. As currently scheduled, the largest taxpayers are brought in first, with other businesses following in later stages of the staged rollout. The intent over time is broad coverage of B2B invoicing for businesses operating in Poland.

Because regulatory timelines can shift, treat any specific date you read as provisional. The reliable approach is to verify the current schedule and your own obligation directly with the Ministry of Finance (Ministerstwo Finansow) and, where appropriate, your accountant. What is unlikely to change is the direction of travel: structured e-invoicing through a central system is coming, and preparing your data early costs you very little while leaving you ready whenever your phase arrives. Whether and when KSeF applies to your specific business is a determination only you and your advisor can make.

Warning: Treat any specific KSeF date you read as provisional and confirm the current schedule, and whether it applies to your business, with the Ministry of Finance and your accountant.

What invoice and customer data must be correct

The structured format used by KSeF (commonly referred to as the FA_VAT schema) expects complete and well-formed data. In practice, these are the areas worth tightening in your shop:

• NIP for business buyers. When a customer buys as a company, you need their Polish tax identification number captured at checkout and stored against the order. A NIP with the wrong number of digits or a failed checksum is worth catching at the point of sale, not at submission.
• Complete buyer details. Company name, full address and postal code need to be present and consistent, not partially filled or free-typed in unpredictable ways.
• Correct VAT rates. Each line item must carry the right VAT rate. Inconsistent or missing rates are a common source of invoice errors.
• A clear “is this a business order” signal. You need to know, per order, whether an invoice is expected at all, so business orders do not get treated like anonymous consumer sales.
• Clean, structured data overall. Because the document is machine-read, small gaps that a human would forgive (a missing field, an odd character, a blank company name) become real problems.

Getting these fundamentals right benefits your bookkeeping today, regardless of which KSeF phase you fall into.

Tip: Almost all the useful preparation you can do today is data hygiene, and it pays off immediately for your bookkeeping regardless of when your phase begins.

What a good readiness layer needs

A WooCommerce store does not need a full KSeF gateway built into every plugin. It needs a readiness layer that does a few things well, and gets out of the way of whatever invoicing tool eventually does the submission. Use this as a checklist:

• Capture the NIP cleanly at checkout, with validation, so bad numbers never reach an order.
• Work on both classic and block checkout, because stores run both and the data has to land in the same place either way.
• Identify which orders need an invoice, so you are not eyeballing every order to guess.
• Surface that status where you work, on the orders list, not buried in a meta box.
• Expose hooks, so a dedicated invoicing or accounting integration can act on an order the moment it is ready, without you wiring anything together by hand.

Notice what is not on that list: actually sending invoices to KSeF. A readiness layer that quietly tried to be an accounting system would be overreaching. The job here is to make the data correct and the order state legible; submission stays with a tool built for it.

Note: The free plugin is a readiness layer, not an invoicing engine. It captures the NIP, flags orders and exposes hooks, but generating the invoice and submitting KSeF XML is a separate job handled by PRO or a dedicated invoicing tool.

How Polski handles it

Polski for WooCommerce is a free, modular plugin for Polish shops, and its KSeF support is deliberately scoped as a readiness layer rather than an invoicing engine. Two modules do the work: the B2B checkout fields that capture the data, and the KSeF-ready module that flags and exposes it.

Capturing the data at checkout

The B2B checkout module adds the fields a Polish business order needs. There is an optional “Buying as a company” toggle, a NIP field, and optional REGON and IBAN fields, each off or on depending on what your shop actually wants to collect. The NIP is validated with a proper checksum, so a transposed digit or a number that simply is not a valid NIP is rejected at checkout with a clear notice rather than saved as-is. REGON is checked for the correct 9 or 14 digit length, and IBAN is validated end to end, including the ISO 13616 mod-97 check digit, so a mistyped bank account does not slip through.

Crucially, the fields work on both classic and block checkout. On modern WooCommerce (8.6 and later) Polski registers them through WooCommerce’s unified additional-fields API so they appear natively in the block checkout, and it mirrors the values back to the standard _billing_nip, _billing_regon and _billing_iban order meta. That mirroring matters: it means the KSeF module, an invoice tool or an accounting export all read the same predictable keys no matter which checkout collected the data.

Flagging orders for KSeF

With the KSeF-ready module enabled, Polski inspects each order as it is placed and decides whether it looks like it needs a KSeF invoice, based on whether a NIP is present. It writes that decision to the order and exposes a KSeF column on the WooCommerce orders list, working on both legacy storage and HPOS (High-Performance Order Storage). An order that needs an invoice shows a coloured status marker; one that does not shows a neutral dash. The admin order screen also shows the KSeF status in the billing section. You can see, at a glance across a whole screen of orders, which ones are business invoices waiting to be handled.

The hooks an integration plugs into

This is where the readiness layer earns its name. The “is this required” decision runs through the polski/ksef/is_required filter, so an integration or your own code can override the rule (for example, to also flag orders without a NIP that carry a “needs invoice” checkbox). When an order is determined to need an invoice, Polski fires the polski/ksef/invoice_ready action, passing the order. An invoicing plugin, an accounting sync or a custom script can listen on that single hook and start its own process the moment an order is ready, with the NIP and billing data already validated and stored on known meta keys. You get the wiring without writing the glue.

Setting it up

Getting the readiness layer live takes a few minutes:

1. Install Polski for WooCommerce from Plugins > Add New, then activate it. WooCommerce must be installed and active.
2. Open the Polski menu and go to Modules.
3. Enable the B2B checkout fields so the NIP (and, if you want them, REGON and IBAN) are collected at checkout. Choose which fields to show.
4. Enable the KSeF-ready module so orders are flagged and the KSeF column appears on the orders list.
5. Confirm your WooCommerce VAT rates are correct, since line-item VAT is part of any structured invoice.
6. Place a test order with a company NIP and check that it is flagged on the orders list and shows a KSeF status on the order screen.

Because Polski is HPOS-compatible and supports both the classic and block cart and checkout, it sits cleanly on a modern WooCommerce install. The modules are independent, so you can run only the KSeF and B2B pieces and leave the rest of the plugin switched off.

Practical tips for getting ready now

A plugin gives you the mechanism; the discipline is yours. A few practical pointers:

• Turn on NIP validation before you need it. Catching a malformed tax number at checkout is far cheaper than discovering it when an invoice is rejected. The validation is already there once the field is enabled.
• Reconcile existing customer records. Review business accounts and fill in missing tax numbers and addresses now, while it is routine rather than urgent.
• Standardise how company data is collected. A single, validated NIP field beats letting customers paste their tax number into the notes box, where no tool can read it reliably.
• Decide your invoicing tool early. The free readiness layer flags and exposes orders; something has to generate the document and submit it. Knowing whether that is an accounting integration or a dedicated invoice plugin shapes how you use the hooks.
• Treat dates as provisional. Build the data discipline now so the eventual switch is a configuration step, not a scramble.

KSeF readiness versus default WooCommerce

WooCommerce can take an order and refund it, but it has no concept of a NIP, no idea which orders are business invoices, and no hook for an invoicing system to latch onto. Here is the difference for KSeF readiness specifically:

Capability	Default WooCommerce	Polski for WooCommerce
NIP field at checkout	None built in	Validated NIP field, classic and block checkout
REGON / IBAN capture	None	Optional, with length and mod-97 validation
NIP checksum validation	None	Yes, rejected at checkout if invalid
”Business order” signal	None	Buying-as-company toggle and per-order flag
Which orders need a KSeF invoice	Manual guesswork	Auto-flagged on order placement
KSeF status on the orders list	None	Column on legacy and HPOS order lists
Integration hooks	None	is_required filter, invoice_ready action
Generating the invoice / KSeF XML	None	Manual / external (PRO adds it)
Cost	Free (no KSeF awareness)	Free; PRO adds invoices and KSeF XML

Free versus PRO

The free edition is a genuine readiness layer, not a teaser: validated NIP, REGON and IBAN capture on classic and block checkout, automatic flagging of orders that need a KSeF invoice, a KSeF status column on the orders list, and the filter and action an integration plugs into. For most stores preparing ahead of their phase, that is the work that needs doing now.

Polski PRO builds the invoicing engine on top. It adds PDF invoices (Faktura VAT) with autonumbering and KSeF XML export, full NIP validation with the GUS/REGON API plus a checkout “fetch data from GUS” button that auto-fills company name, address and REGON from the official registry, a Tax Rules engine that assigns GTU and JPK_V7 codes, and accounting sync to wFirma, Fakturownia and iFirma. There is also an invoice Markdown endpoint so accounting and customer-service tools can read invoice data, including the KSeF reference and status, without parsing a PDF. The free layer captures and flags; PRO produces and submits.

A standing caveat applies to all of it: Polski provides technical modules, not legal advice, and no plugin can guarantee compliance. Confirming whether your store meets KSeF requirements remains your responsibility, ideally with your accountant and the official Ministry of Finance guidance.

The short version

KSeF turns the invoice from a PDF you design into a structured record the state validates, which means your invoice data has to be clean, complete and machine-readable before your phase arrives. Default WooCommerce has no awareness of any of this. The free Polski for WooCommerce closes the readiness gap: it captures a validated NIP (plus optional REGON and IBAN) on classic and block checkout, flags which orders need a KSeF invoice, shows that status on the orders list, and exposes hooks an invoicing tool can act on. PRO adds the engine that generates Faktura VAT PDFs, exports KSeF XML, validates against GUS and syncs to your accounting system when you are ready to automate the rest.