KSeF in a Shopware Store: Automated E-Invoicing (B2B and B2C)

KSeF (Krajowy System e-Faktur, Poland's National e-Invoicing System) is no longer a "later" problem. In 2026, issuing structured invoices became mandatory, and merchants who used to generate invoices by hand or in a spreadsheet now have to automate the whole process. For a store built on Shopware 6 that means one thing: orders, buyer data, and invoice lines have to reach KSeF with no human in the loop - correctly, on time, and with corrections handled. This guide explains how to set that up.

The short answer

Shopware is not accounting software and should not send invoices to KSeF on its own. In practice the architecture that works is the one where Shopware captures the right data (invoice vs receipt, tax ID, VAT rates), and the actual structured invoice is issued and sent to KSeF by your ERP or accounting system (for example enova365, Comarch, or dedicated middleware). The KSeF number and acceptance confirmation then flow back to the order and can be shown to the customer. The store owns data quality and the trigger point - not the conversation with the tax authority's API.

What KSeF is and what changes for the store

KSeF is a central, government platform that all structured invoices pass through - documents in a defined XML format (the FA schema), not PDFs. Once sent, each invoice receives a unique KSeF number, and the issuer gets an official acceptance confirmation (UPO). That number and confirmation are the proof the invoice was effectively issued. There are two consequences for a store: invoices must follow a strict data structure, and "issuing" no longer ends when a PDF is generated - it ends only once the document is accepted by the system.

Who must issue e-invoices and from when

Under the rollout schedule, the obligation came into force in stages during 2026: first for the largest companies (above the statutory prior-year turnover threshold), then for the remaining active VAT payers. The smallest entities and special cases have separate, later deadlines. Dates and thresholds have been adjusted before, so confirm your exact obligation date with your accountant or tax advisor - it is a tax decision, not a technical one. From a build perspective the takeaway is simple: if you sell to businesses, KSeF integration is not a "future" item, it is a condition for the store to operate.

B2B vs B2C - what the store actually has to handle

This distinction drives how you design checkout:

• B2B sales - invoices between businesses go through KSeF. The store has to reliably collect the buyer's data, above all a valid tax ID (NIP), and clearly flag that the order requires an invoice.
• B2C sales - consumer invoices follow separate rules, and receipts and simplified invoices have their own path. Some merchants still want to issue consumer invoices consistently with the rest of the flow. Decide how to treat them with your accountant and mirror that decision in the store's logic.

The key design point: checkout must clearly separate "I want an invoice" from "a receipt is enough", and validate the tax ID at purchase time, not later in the ERP.

Where the invoice is created in the architecture

The most common mistake is trying to issue invoices straight from Shopware. An invoice is an accounting document - its numbering, archiving, and submission to KSeF belong in the system that already runs your books. The proven split of responsibilities looks like this:

• Shopware - source of the order and buyer data, the place where "invoice vs receipt" is decided, and where status is shown to the customer.
• ERP or accounting system - assigns the number, generates the structured invoice and sends it to KSeF, then receives the KSeF number and UPO.
• KSeF - accepts the document, assigns a number, and returns a confirmation.

If you already run a Polish ERP, it most likely supports KSeF natively - in which case the integration's job is to deliver orders reliably. See our guides to integrating with enova365 and Comarch ERP, because it is the same data channel that will carry invoicing.

How the integration works, step by step

• 1. Order in Shopware - the customer chooses an invoice, enters a tax ID, and places the order.
• 2. Handover to the ERP - the order plus invoice data is passed to the ERP through the API, ideally event-driven (webhook), with a guarantee that every order arrives exactly once.
• 3. Issue and send to KSeF - the ERP builds the structured invoice and sends it to KSeF, authenticating with a token or certificate.
• 4. KSeF number and UPO returned - once accepted, the document receives a KSeF number; the ERP stores it together with the confirmation.
• 5. Sync back to the store - the invoice number and status flow back to the order in Shopware, so the customer sees them in their account and in an email.

The KSeF test environment lets you run this whole path without issuing real documents - use it for end-to-end testing before you switch the store to production.

What a Shopware store must collect and pass on

Invoice quality starts in the cart. The store should take care of:

• Tax ID (NIP) validation at checkout, ideally with a format and contractor-status check.
• An explicit document choice - invoice or receipt - stored with the order.
• Correct VAT rates and amounts consistent with what the ERP expects, including B2B contractor pricing.
• Complete buyer and address data required by the invoice schema.

The cleaner the data leaving Shopware, the fewer rejections and corrections on the KSeF side.

Corrections, errors, and failure cases

A real implementation is more than the happy path. Plan up front for: correcting invoices (returns, quantity changes, post-transaction discounts), retrying submission when KSeF is temporarily unavailable, idempotency so a failure does not issue the same invoice twice, and clear handling of rejections when data fails validation. Also archive the KSeF numbers and UPO - they are your proof of issuance.

Common implementation pitfalls

• Invoicing straight from Shopware instead of from the accounting system - this breaks numbering and archiving.
• No tax ID validation at checkout - a wrong number only blocks the invoice later, in the ERP.
• Skipping the test environment - the first errors then surface in production.
• No idempotency or retries - duplicates or "lost" invoices when there is a brief outage.
• Inconsistent VAT mapping between the store and the ERP - the single most common cause of rejections.

Where to start

The best first step is to get the order flow into the ERP right - because that is the channel invoice data will travel on. If the integration with your accounting system already runs reliably, adding KSeF is a natural extension, not a brand-new project. Explore our Shopware development service and our enova365 and Comarch ERP integrations, or contact us to discuss KSeF for your store.