On 1 February 2026, Poland launched the first large-scale centralized e-invoicing rollout in Europe: every B2B invoice goes through KSeF, the Ministry of Finance’s platform. Nine months on, there is enough hindsight to separate what worked from what stalled, and to see what groups with a Polish subsidiary still need to address before 1 January 2027.
This is a field review as of 9 November 2026, not an explainer. For the basics (FA(3) schema, scope, permanent establishments), see our KSeF Poland 2026 guide. The facts below come from public Polish sources; where a point is not yet settled in law, we say so.
Where the rollout stands
The switchover went according to plan. Since 1 February 2026, taxpayers whose 2024 sales (including VAT) exceeded PLN 200 million issue their invoices through KSeF, and all VAT taxpayers must be able to receive them. On 1 April 2026 the remaining taxpayers followed, except those with monthly sales of up to PLN 10,000, who have a grace period until the end of 2026 (official KSeF portal, scope of the mandate). Consumer invoices and invoices issued by entities with no seat or permanent establishment in Poland remain out of scope.
The Ministry’s figures give a sense of scale: 289.6 million invoices issued between 1 February and 26 May 2026 (WNP, Ministry of Finance data), then 657.4 million and 2.37 million issuers as of 2 September 2026 (Infor.pl, 6 November 2026). Volume more than doubled in a little over three months, driven by the April wave.
Penalties: the postponement to end-2027 is being adopted
This is the most important change since our previous guide, which mentioned penalties from 1 January 2027. On 16 September 2026, the Ministry announced its intention to extend until 31 December 2027 the moratorium on fines for KSeF application errors (Article 106ni of the VAT Act); criminal tax liability is not affected (KPMG Poland alert, 17 September 2026).
On 6 November 2026, the Sejm passed the bill by 437 votes to 1, with entry into force planned for 31 December 2026; it still has to go through the Senate and receive the President’s signature (Bankier.pl). At the time of writing, the law has therefore not yet been enacted. The practical consequence: the obligation to use KSeF still extends to everyone on 1 January 2027, but the risk of a fine for errors moves back by a year. Do not confuse a fine moratorium with a compliance exemption.
What companies actually ran into
The Ministry describes the initial period as stable: it says KSeF suffered no outage in 2026, meaning the emergency procedures were never activated. The difficulties lay elsewhere. Between January and September, the helpline received 318,997 calls and 89,271 emails, mainly about access rights in KSeF, authentication tools (qualified signatures) and issuing and receiving procedures (Infor.pl). In other words, the issue is organizational before it is technical.
ERP integration and formats
FA(3) XML was the part vendors handled best, having had almost seven months since the final schema was published. The friction seen in practice is mostly data mapping: a Polish integrator reports mismatches between the KSeF XML structure and how the ERP displays it, notably around the NIP (tax ID) and the KSeF reference number (Wercom, first-week review). One concrete vendor case: Sage had to publish an X3 hotfix for sending invoices to a non-Polish customer so that the foreign tax ID lands in the NIP field correctly (Sage Community Hub). A similar adjustment was made in Odoo for intra-EU transactions (odoo/odoo fix). The lesson for a group: it is cross-border cases, not the domestic one, that expose the defects.
Permissions and tokens
The most frequent trap is a classic governance problem. The super-administrator declared in the ZAW-FA form does not automatically receive issuing and receiving rights: they must grant them to themselves. Otherwise, the token or certificate they generate for the ERP authenticates nothing (Wercom). Another common mistake is downloading the certificate without its private key. KSeF does not keep the key, and a certificate without it is unusable (same source).
On the future of tokens, the framework is not settled. The current regulation allows them only until 31 December 2026, and Comarch communicates accordingly: the KSeF certificate becomes the only form of authentication on 1 January 2027 (Comarch, KSeF certificates and tokens). But the Ministry has indicated, at the market’s request, that it wants to keep tokens with no expiry date, through a draft regulation published on 27 October 2026 (Rzeczpospolita Pro, Aider Group). Until that text is published, the prudent course is to move the ERP to certificates and treat tokens as an entitlement that is not guaranteed.
Unavailability and offline mode
KSeF distinguishes four situations, and the nuance matters for ERP design (Infor.pl, offline24, offline and emergency modes):
- offline24: on the taxpayer’s side (network or ERP problem); the invoice must be sent to KSeF by the next business day at the latest;
- offline (unavailability announced by the Ministry): sent by the business day after the unavailability ends;
- emergency mode (announced failure): sent within 7 business days after the failure ends;
- total failure: specific procedures apply.
What we wrote in April, presenting offline24 as the answer to platform outages, was therefore incomplete: offline24 first covers your own incidents. Two lessons follow. First, KSeF’s reliability has spared most companies, but offline mode remains useful for your outages, which requires a persistent queue in the ERP. Second, there is an offline certificate, separate from the authentication certificate, which must be requested separately (Comarch, above).
Received invoices and the accounting workflow
Receiving is mandatory for everyone since 1 February, including companies that did not yet issue through KSeF. This changes the nature of accounts payable: a received invoice is no longer a PDF that lands in an inbox but a feed that must be polled. Odoo, for example, fetches vendor bills from KSeF every three hours by default, a frequency you can change (Odoo documentation, Poland localization). Points for IT to watch: matching against purchase orders, handling duplicates when a supplier also sends a PDF, processing credit notes, and storing the KSeF number as evidence.
Gaps between ERP vendors
We limit ourselves here to what vendors and their ecosystems publish themselves. This is not a ranking, and the list is indicative.
| Vendor | What public sources say | Watch point |
|---|---|---|
| SAP | SAP Document and Reporting Compliance covers KSeF 2.0: generation of compliant XML and submission to KSeF, plus import of supplier invoices (SAP Community) | Depends on version and deployment (cloud or add-on); validate per entity |
| Comarch | Polish vendor; announces native compatibility with the KSeF 2.0 API and certificate installation handled within its systems | Validate for the group’s non-Polish entities |
| Microsoft Dynamics 365 | A Polish partner states that D365 Finance & Operations provides native KSeF support (7F, KSeF module), complemented by partner modules | Partner source, not Microsoft: ask the vendor for a version matrix |
| Sage | X3 hotfixes published for Polish legislation (non-Polish customer cases) | Track version updates; cross-border cases are sensitive |
| Odoo | FA(3) generation, certificate authentication, automatic import of vendor bills; the official documentation does not detail offline mode (Odoo documentation) | A Polish company with a valid NIP is required; third-party modules exist for offline24, to be evaluated |
The table mainly shows a dividing line: vendors that treat KSeF as a product compliance case (SAP, Comarch, Dynamics) versus those where part of the functionality comes through modules or hotfixes. For a multi-ERP group, the question is not “which vendor is compliant” but “which functions (offline24, offline certificates, received-invoice import, intra-EU cases) are covered in my version, on what maintenance schedule”.
Lessons for other countries
The Polish model is centralized clearance: the state receives, validates and archives. France chose a network of accredited platforms, Belgium a Peppol network, and Romania a state platform comparable to KSeF. Three lessons stand out.
1. A centralized architecture simplifies the interface, not the organization. A single access point reduces the number of connectors, but moves the difficulty to rights, certificates and governance, as the nature of the Polish helpline calls shows. Groups entering a network model in 2026-2027 (France, Belgium) will find the same issues under other names: authorizations, platform choice, directory.
2. A grace period is a policy instrument, not a given. Poland first planned a year without fines, then extended it. In Belgium, the B2B Peppol mandate took effect on 1 January 2026 with a three-month tolerance period, and fines have applied since 1 April 2026 (Comarch, Belgium, Vertex). Penalty timelines differ from country to country; do not plan from a neighbouring country’s schedule.
3. Cross-border is the test. The Sage and Odoo fixes cited above concern foreign counterparties. For France, where receiving has been mandatory since 1 September 2026 (our D-6 checklist), and for Romania, where RO e-Factura has covered B2B since 2024 (EDICOM), the same finding applies: test your intra-EU flows before your domestic ones.
At EU level, ViDA, adopted by the Council on 11 March 2025, makes EN 16931 e-invoicing mandatory for intra-EU transactions from 1 July 2030 (DLA Piper, PwC Luxembourg). National systems like KSeF will have to converge; an ERP architecture too tightly bound to a local schema will become a liability.
5 Pitfalls to Avoid
- Reading the penalty postponement as a compliance waiver. Pitfall: slowing the project down because fines are pushed back to the end of 2027. Consequence: the obligation still extends to every taxpayer on 1 January 2027, fiscal criminal liability is not covered by the postponement, and the law is not yet promulgated. Countermeasure: keep a compliance plan built on 1 January 2027 and treat the postponement as a margin for error, not a deadline.
- Assuming the super-administrator already holds the rights. Pitfall: generating the ERP token or certificate from an account that never granted itself issuing and receiving rights, or downloading the certificate without its private key. Consequence: the ERP authenticates nothing and invoices stop going out. Countermeasure: review rights entity by entity in KSeF, and store the private key in a vault at the moment the certificate is created.
- Betting on the token extension. Pitfall: leaving the ERP integration on tokens because the Ministry has announced it wants to keep them. Consequence: if the draft regulation is not published in time, token authentication ends on 31 December 2026 and sending stops overnight. Countermeasure: move the ERP to certificates now and monitor expiry dates.
- Treating offline24 as an answer to KSeF outages only. Pitfall: designing nothing for your own network or ERP incidents, since the platform has had no failure in 2026. Consequence: no persistent queue, no offline certificate, and invoices that cannot be issued within the next-business-day deadline. Countermeasure: request the offline certificate separately and test an offline24 issuance end to end.
- Testing the domestic flow only. Pitfall: signing off the integration on Polish customers and suppliers. Consequence: defects show up on foreign counterparties, as the Sage X3 and Odoo fixes for non-Polish tax identifiers illustrate. Countermeasure: replay EU and non-EU customer cases before go-live and confirm the applicable versions and hotfixes with the vendor in writing.
Checklist for a Polish subsidiary that is non-compliant or still stabilizing
- Check rights in KSeF. Has the super-administrator granted themselves issuing and receiving rights? Who can issue for which entity?
- Move the ERP to certificates. Do not count on token extension until the regulation is published. Keep the private key in a vault.
- Request the offline certificate, separate from the authentication certificate, and test an offline24 issuance end to end.
- Test receiving. Polling frequency, de-duplication against PDFs, credit notes, linking to orders, storage of the KSeF number.
- Monitor expiry dates of certificates and tokens: a frequent cause of abrupt stops in sending.
- Replay cross-border cases: EU customer, non-EU customer, foreign tax IDs in the expected fields.
- Get written confirmation from the vendor of the versions and hotfixes that apply to your deployment.
- Track the fine calendar. The postponement to end-2027 has passed the Sejm but is not yet enacted; keep a compliance plan based on 1 January 2027.
- Prepare for the 1 January 2027 widening: your smallest suppliers and customers enter the flow, which increases received volumes.
Further reading
KSeF is part of a wider timeline than Poland alone. To place all upcoming deadlines in context, read our ERP regulatory calendar for 1 January 2027 and our analysis of the ERP market in Poland and the Czech Republic. To follow the next developments (enactment of the fine postponement, the token regulation), subscribe to the ERP regulatory watch newsletter.
