Poland

This article was updated on 10 August 2026 to reflect the 20 July 2026 publication of an individual interpretation (0112-KDIL1-3.4012.317.2026.1.ŁW) by the Director of the National Tax Information, which clarifies that supplementary commercial data is permitted on KSeF invoice visualisations without triggering additional VAT liabilities.

Introduction

Poland’s move toward digital invoicing began in the public sector with the 2019 B2G receiving mandate, before expanding into a full Business-to-Business (B2B) clearance model. Originally slated for mandatory adoption as early as 2023 and later postponed from July 2024 following an extensive system architecture and cybersecurity audit, the mandate underwent a complete technical overhaul. Re-engineered to handle massive enterprise data volumes, streamline documentation under the VAT Act, and close the VAT gap, the redesigned KSeF 2.0 platform acts as Poland’s centralised clearance hub for all domestic B2B transactions while integrating with public procurement channels. As a Continuous Transaction Control (CTC) system, KSeF requires that invoices be issued and cleared by the tax authority via a centralised platform before they are delivered to the buyer, ensuring real-time tax transparency. 

After a period of testing and system stabilisation, KSeF 2.0 successfully went live in February 2026 for large taxpayers and expanded to the vast majority of Polish businesses in April 2026. The Ministry of Finance reported a stable technical environment, processing over 50,000 invoices and registering 320,000 users in its first week alone. With millions of transactions now flowing through the central platform daily, maintaining data quality, secure API integrations, and robust fallback workflows remains critical as the remaining transitional buffers expire and full 2027 enforcement approaches.

Compliance timeline

Poland's e-invoicing journey encompasses public procurement (B2G) receiving mandates established in 2019, followed by a phased B2B rollout under KSeF 2.0 based on taxpayer size and transaction volume.

Legal framework

The foundational rules for mandatory structured electronic invoicing in Poland were established through amendments to the VAT Act.

• B2G procurement framework: The Act of 9 November 2018 on electronic invoicing in public procurement, concessions for construction works or services, and public-private partnership transposed EU Directive 2014/55/EU into Polish law. It established the legal basis for public sector receiving obligations and the PEF platform.

• Final KSeF legislation: The final mandate timelines and regulatory adjustments were signed into law on 27 August 2025, confirming the phased 2026/2027 rollout.

• Individual interpretations: The Ministry routinely issues guidance to clarify operational edge cases. Most recently, Individual Interpretation no. 0112-KDIL1-3.4012.317.2026.1.ŁW (published 20 July 2026) provided vital legal protection regarding the inclusion of supplementary data on invoice visualisations.

Authorities

• Ministry of Development and Technology (Ministerstwo Rozwoju i Technologii): Oversees public procurement policy and the operational framework for the Platforma Elektronicznego Fakturowania (PEF) within the OpenPeppol network.

• Ministry of Finance (Ministerstwo Finansów): The primary governmental body overseeing tax policy, the VAT Act, and the phased implementation of KSeF.

• National Tax Information (Krajowa Informacja Skarbowa): Responsible for issuing individual interpretations and official guidance on the practical application of e-invoicing laws.

Scope of the mandate

The KSeF mandate drastically alters the invoicing landscape for entities operating in Poland.

• B2B transactions: Mandatory issuance and receipt of structured e-invoices via KSeF for domestic transactions. Non-resident businesses are subject to KSeF issuance only if they have a Fixed Establishment (FE) for VAT purposes in Poland that actively participates in the supply. Foreign entities operating via direct VAT registration without a Polish FE are excluded from issuing via KSeF.

• B2G transactions: Business-to-Government transactions have been governed by the PEF platform (Platforma Elektronicznego Fakturowania) since 2019. Public entities are required to receive structured e-invoices via this Peppol-based system. While supplier sending via PEF was previously voluntary, the 2026 mandate requires suppliers in scope to issue B2G invoices electronically. With the launch of KSeF, the two systems are integrated, allowing B2G invoices to be processed through either PEF or KSeF. Regardless of the issuance channel, all B2G invoices are assigned a unique KSeF ID, ensuring full tax authority visibility.

• B2C transactions: Consumer (B2C) transactions are formally excluded from mandatory KSeF issuance. However, businesses can voluntarily issue consumer invoices in KSeF system.

E-invoicing requirements

"Technical readiness is nothing without data quality. The move to the FA(3) XML schema brought stricter validation rules, and messy ERP data will result in instant rejection."

To operate within the KSeF ecosystem, businesses must adhere to strict technical and operational guidelines, including the following:

1. Public-sector and local-government structuring: Invoices involving public-sector bodies may require additional identification where the legal buyer, contracting authority, subordinate local-government unit, payer, or operational recipient are different entities. The FA(3) logical structure uses the JST field to indicate whether the invoice concerns a subordinate local-government unit. Where the relevant JST value is selected, the subordinate unit must also be identified in Podmiot3, so that it can also receive and process the invoice in KSeF. The optional Podmiot3 element may also identify other parties connected with the invoice, such as a payer, delivery recipient, factor, branch, or VAT-group member.

2. The FA(3) XML schema: Structured invoices must be generated in the applicable FA(3) structured XML format. The schema includes expanded VAT rate classification codes and allows for structured attachments (e.g., contracts, delivery notes) to be embedded within the XML, provided they respect the 3MB total file size limit.

3. Authentication and tokens: Legacy tokens generated under KSeF 1.0 (before February 2026) are invalid. Businesses must generate new production tokens via the Taxpayer Application 2.0 to establish a secure API connection.

4. Invoice visualisations and supplementary data: A major operational question for businesses has been how to handle internal data that does not fit neatly into the FA(3) schema. On 20 July 2026, the Director of the National Tax Information confirmed via individual interpretation (0112-KDIL1-3.4012.317.2026.1.ŁW) that human-readable visualisations of a structured KSeF invoice may contain supplementary information not included in the underlying XML file.

   • Permitted data: This may include items such as internal customer or order references, commercial discounts, country of origin, and Incoterms delivery terms.

   • Conditions: The supplementary data must be informational, must not alter the substance of the transaction, and must not contradict the official KSeF XML.

   • Liability: Provided these conditions are met, the visualisation is not treated as a separate invoice, and does not trigger additional VAT liability. This interpretation protects the applicant but provides crucial insight into the tax authority's current stance.

5. The "Offline24" fallback mode: During taxpayer-side technical issues, businesses may issue invoices offline in the FA(3) schema and include the required mandatory QR codes, including one based on the KSeF certificate. These invoices must subsequently be transmitted to KSeF no later than the end of the next business day after issuance to receive a KSeF number. Separately, officially announced system unavailability and formal failure modes are governed by their own statutory fallback rules and deadlines.

E-reporting requirements

In a clearance model such as KSeF, e-invoicing and e-reporting are closely intertwined. By transmitting all structured FA(3) XML invoices to the central hub, the tax authority receives near-real-time transactional data.

Furthermore, standard VAT reporting (such as the SAF-T / JPK_VAT files) remains a legal requirement. Businesses should ensure that their accounting systems are updated to accurately map KSeF numbers to their periodic tax returns, supporting full traceability and compliance with Polish tax laws.

Technical architecture

Poland operates a centralised clearance model for domestic B2B transactions while integrating its Peppol-based B2G platform (PEF) directly into the KSeF clearance engine.

• Suppliers submit the FA(3) XML invoice directly to the central KSeF hub via API.

• The system validates the schema, assigns a unique KSeF ID, and makes the invoice available for the buyer to download.

• Integrated B2G / PEF flow for B2G transactions: the PEF platform acts as a Peppol Access Point, processing Peppol BIS 3.0 documents. In the 2026 integrated model, a B2G invoice submitted via PEF is passed directly into KSeF. KSeF validates the tax schema and assigns a unique KSeF number; only after this clearance step is the invoice made available to the public sector counterparty as an official structured invoice.

• All electronic invoices must be archived for a minimum of 10 years.

Penalties

Recognising the technical complexity of the transition, the Ministry of Finance has instituted a grace period.

• No financial penalties in 2026: The Ministry confirmed that errors made during the 2026 rollout are treated as learning opportunities, with the period without penalties officially extended until the end of 2026.

• 2027 enforcement: The penalty relief expires at the end of 2026, meaning strict enforcement and financial sanctions will commence on 1 January 2027. Under Article 106ni of the VAT Act, tax authorities may impose administrative fines for KSeF non-compliance, including where invoices are issued outside the required system or without the required identifiers.

How businesses can prepare

While the penalty-free grace period allows for a phased transition, delaying KSeF integration creates a hidden tax risk. Under current VAT rules, buyers can still deduct VAT from non-KSeF invoices, but these documents lack the system’s protective digital audit trail. During a tax audit, a non-KSeF invoice may result in a higher evidentiary burden for the buyer, potentially causing delays in VAT refunds or requiring the submission of additional, time-consuming documentation. Early adoption is, therefore, a strategic step to reduce the risk of tax authority scrutiny.

As your business may become subject to KSeF requirements at different points, such as upon new tax registration or market entry, taking proactive action is essential to ensure KSeF compliance and avoid operational bottlenecks.

• Audit master data: Map your ERP fields precisely to the FA(3) schema. Ensure NIP (VAT) numbers are clean and address fields are split exactly as the XML requires to avoid rejection.

• Establish KSeF 2.0 credentials: Delete legacy KSeF 1.0 tokens and generate new API keys through the Taxpayer Application 2.0 to avoid 48-hour issuance delays.

• Set up qualified seals: For high-volume automated processing, implement a qualified electronic seal to allow for "hands-off" batch signing without needing an individual's Trusted Profile for every transmission.

• Review Accounts Payable: Remember that the obligation to receive KSeF invoices is already active for all in-scope taxpayers. Ensure your AP team knows how to fetch and process incoming XML files from any supplier operating within the mandate.

• Update payment vouchers: Begin recording the long KSeF ID on accepted invoices now to avoid a massive data-entry backlog when it becomes mandatory for bank payments on 1 January 2027.

Conclusion

Poland's KSeF 2.0 framework represents a definitive shift toward real-time tax transparency and operational digitalisation. While the Ministry has provided a penalty-free grace period throughout 2026, the technical strictness of the FA(3) schema and the massive, real-time volume of transactions flowing through the platform mean that businesses cannot afford to delay their integration efforts. By auditing master data, securing correct API tokens, and leveraging the new guidance on invoice visualisations, businesses can transform this regulatory hurdle into a strategic operational advantage.