Poland's Krajowy System e-Faktur (KSeF) is the government's mandatory e-invoicing platform, and it fundamentally changes how every B2B invoice in the country is created, transmitted, and stored. Under KSeF, all B2B invoices must be submitted as structured XML documents that pass through the government's centralized system for validation before they carry any legal force. This is a clearance model: an invoice does not legally exist until KSeF has accepted it.
The mandate rolls out in three phases. Large taxpayers with annual turnover exceeding PLN 200 million must issue invoices through KSeF starting February 1, 2026. All other VAT-registered businesses follow on April 1, 2026. Micro-entrepreneurs face their compliance deadline on January 1, 2027, which is also when enforcement penalties take effect. From that date, non-compliance carries penalties of up to 100% of the invoice's VAT amount.
Once KSeF is fully in force, PDFs and paper invoices lose their legal validity for B2B transactions. A PDF attached to an email or a printed document mailed to a supplier will no longer constitute a valid invoice under Polish law. Only invoices conforming to the FA(3) XML schema and validated by the KSeF platform will be recognized as legally binding.
KSeF Compliance Timeline: Three Phases of Mandatory Adoption
Poland's push toward mandatory structured e-invoicing didn't emerge in a vacuum. The country has invested heavily in digital tax infrastructure over the past several years, and the results speak for themselves. According to the European Commission's VAT Gap report, Poland achieved one of the largest VAT compliance improvements in the EU, with its national VAT gap decreasing by 7.8 percentage points between 2020 and 2021 — a reduction attributed to the digitalisation of tax systems, real-time reporting of transactions, and e-invoicing. KSeF is the next step in that trajectory. The Polish Ministry of Finance expects it to recover an additional PLN 200 million annually in tax revenue.
To manage the scale of this transition, Poland is rolling out KSeF obligations in three distinct phases based on business size, plus several interim milestones that affect all taxpayers.
Phase 1: February 1, 2026
The first wave targets large taxpayers — specifically, entities whose turnover exceeded PLN 200 million in 2024. This covers approximately 4,200 companies and represents the highest-volume invoice issuers in the Polish economy.
Here is the critical detail that catches many businesses off guard: every VAT-registered entity in Poland must be ready to receive KSeF invoices from this date, regardless of their own issuing obligation. Even if your company falls into Phase 2 or Phase 3, your Polish suppliers in the large-taxpayer category will begin sending structured invoices through KSeF on February 1. Your AP team needs the infrastructure to retrieve and process those invoices from day one.
Phase 2: April 1, 2026
Just two months later, the mandate expands to all remaining VAT-registered businesses. This includes:
- Mid-sized and smaller Polish companies not captured in Phase 1
- Foreign entities with Polish VAT registration, provided they have a fixed establishment in Poland
- Partnerships, sole proprietorships, and other legal forms registered for VAT
Foreign companies that hold a Polish VAT number but have no fixed establishment in the country are excluded from this phase. However, if you operate a branch, subsidiary, or permanent establishment in Poland, your KSeF issuing obligation begins here.
Phase 3: January 1, 2027
The final phase covers micro-entrepreneurs whose monthly invoicing volume stays below PLN 10,000. These are typically sole traders and very small businesses that issue a limited number of invoices — though even before KSeF applies, JDG sole traders must meet Poland's existing invoicing requirements covering mandatory fields under Art. 106e, VAT thresholds, and corrective invoice rules. Until this date, they may continue using their current invoicing methods.
Key Interim Milestones
Between the phased rollout and full enforcement, several transitional dates affect compliance planning:
August 1, 2026 — KSeF reference numbers in payments. From this date, the KSeF-assigned invoice reference number must be included in bank transfer payment titles, including split payment mechanism transfers. This means your payment processes and ERP systems need to capture and pass through KSeF reference data, not just your invoicing systems.
Transition provisions for simplified and cash register invoices:
- Cash register invoices (paragony fiskalne with NIP) can continue to be issued in their current form until December 31, 2026.
- Simplified invoices for transactions under PLN 450 can use the existing format until September 30, 2026, after which they must conform to KSeF requirements.
2026 grace period — zero penalties. Throughout the entirety of 2026, the Ministry of Finance will not impose financial penalties for KSeF-related violations. This grace period gives businesses a compliance runway to resolve technical issues, train staff, and stabilize integrations without the immediate threat of fines. Penalties take effect starting January 1, 2027.
One notable exclusion from the entire timeline: B2C transactions remain voluntary. There is no planned mandatory date for consumer-facing invoices to pass through KSeF, so sellers still need to handle Poland's e-commerce receipt, NIP, and consumer invoice-request rules separately from the KSeF rollout. The system is designed exclusively for B2B and B2G invoicing.
For finance teams building their implementation roadmap: receiving capability must be live by February 2026 regardless of company size. Issuing capability depends on which phase applies to you. And payment systems need KSeF reference number support by August 2026.
FA(3) XML Schema: What the New Invoice Format Requires
KSeF does not accept PDFs. Every invoice submitted to the system must conform to the FA(3) XML schema, a structured data format that replaced the earlier FA(2) version as of January 2026. Where a PDF invoice is essentially a digital image with text layered on top, FA(3) is a machine-readable data structure containing over 300 defined fields — mandatory, optional, and conditional — that capture invoice information at a granularity no PDF ever achieved.
The schema covers far more than header-level data. Line items, tax breakdowns by rate, payment terms, delivery details, buyer and seller identifiers (including NIP tax numbers), currency codes, and transaction-specific annotations all have designated fields with strict validation rules. Conditional fields activate based on invoice type: a corrective invoice triggers different required elements than a standard sales invoice, and intra-community supplies require fields that domestic transactions do not. The result is that every invoice entering KSeF conforms to the same schema, uses the same field definitions, and passes the same validation rules, giving downstream systems a predictable data structure to work with.
Dual numbering is one of the most operationally significant aspects of FA(3). When a seller submits an invoice to KSeF, the system validates the XML against the schema and, upon acceptance, assigns a KSeF system identification number. This number — not the seller's own invoice number — becomes the invoice's unique legal identifier within the Polish tax system. The seller's original number is preserved in the XML, but both numbers must be tracked going forward. For AP teams, this means invoice matching and reconciliation workflows need to accommodate two reference numbers per document. Purchase orders, payment records, and accounting entries must map to both the seller's number (which your vendor communicates) and the KSeF number (which the tax authority recognizes).
Authentication and Authorization
Accessing KSeF — whether to submit invoices, retrieve them, or manage permissions — requires authentication through one of several methods:
- Qualified electronic signature or qualified electronic seal, the most common method for ongoing production use
- Authorization tokens, which provide programmatic access for automated systems (available through the end of 2026)
- KSeF certificates issued for machine-to-machine integration
Organizations that rely on external accountants or need to delegate invoice issuance to specific employees must submit a ZAW-FA form to the tax office. This form formally authorizes designated individuals or entities to operate within KSeF on behalf of the taxpayer. Without a filed ZAW-FA, an external accounting firm cannot issue invoices through your KSeF account, regardless of their contractual relationship with your business.
Government Archiving and Its Limits
KSeF stores every validated invoice for 10 years from the end of the year in which the invoice was issued — double the standard 5-year statutory retention period under Polish tax law. This eliminates the need for businesses to independently archive invoice XML files for compliance purposes. However, KSeF does not store attachments. Contracts, delivery confirmations, purchase orders, and any other supporting documentation referenced by an invoice remain the business's responsibility to archive separately.
Financial Incentive: Accelerated VAT Refunds
Beyond compliance, KSeF participation comes with a concrete financial benefit. The standard VAT refund period drops from 60 days to 40 days for businesses that issue invoices exclusively through KSeF. For companies with significant input VAT to recover, this 20-day acceleration improves cash flow in a measurable, recurring way.
Where FA(3) Fits in Poland's Digital Tax Infrastructure
KSeF does not operate in isolation. It is part of a broader ecosystem that includes JPK_VAT (Jednolity Plik Kontrolny), Poland's Standard Audit File for tax reporting. JPK_VAT requires businesses to submit structured monthly or quarterly files detailing all VAT transactions. Together, KSeF and JPK_VAT create a comprehensive digital tax infrastructure where the Ministry of Finance receives both the source documents (invoices via KSeF) and the aggregated reporting data (transaction summaries via JPK_VAT). For finance teams, this means the structured data flowing into KSeF must be consistent with what appears in JPK_VAT filings — discrepancies between the two will be visible to tax authorities automatically.
Penalties for Non-Compliance After January 2027
Poland's approach to KSeF enforcement follows a deliberate two-stage model: a full calendar year of grace, followed by penalties severe enough to make non-compliance genuinely costly.
Throughout 2026, no penalties apply for KSeF-related violations. This grace period gives businesses time to integrate their systems, test XML submissions, and resolve technical issues without financial risk. But that window closes on December 31, 2026.
Starting January 1, 2027, the Ministry of Finance enforces two distinct penalty tiers based on the type of invoice issued outside the KSeF system:
For VAT invoices issued outside KSeF: Penalties of up to 100% of the VAT amount shown on the invoice. This effectively doubles the tax cost of every non-compliant invoice. A standard 23% VAT invoice for 50,000 PLN carries 11,500 PLN in VAT — and an equal 11,500 PLN penalty if issued outside KSeF when the mandate requires submission. Scale that across hundreds of invoices per month, and the cumulative exposure becomes a material financial risk.
For non-VAT invoices (certain VAT-exempt transactions, for example): Penalties of up to 18.7% of the gross invoice value. While lower in percentage terms, this still represents a significant cost on high-value exempt transactions.
These penalties target a specific action: issuing invoices outside the KSeF system when the mandate requires KSeF submission. The obligation falls squarely on the invoice issuer. Recipients are not penalized in the same way for receiving invoices outside the system — the enforcement mechanism is designed to compel sellers and service providers to route their invoices through the national platform.
Businesses that wait until January 2027 to begin their KSeF integration face a compressed timeline where any technical failure, API misconfiguration, or process gap immediately triggers financial penalties. Organizations that treat the 2026 grace period as an implementation runway rather than a delay gain operational stability before enforcement begins — and avoid the scenario where a single month of system issues generates penalty exposure exceeding the cost of the integration itself.
Cross-Border Invoicing Under KSeF
KSeF's reach does not stop at Poland's borders. If your company is VAT-registered in Poland and sells goods or services to foreign buyers — whether intra-EU or export — those invoices must be submitted to KSeF. The domestic clearance obligation applies regardless of where the buyer is located.
This creates a practical challenge: foreign buyers cannot access the KSeF platform. A German purchasing department or a U.S. accounts payable team has no KSeF login and no way to retrieve invoices from the system. Polish sellers must therefore maintain a dual-delivery process. The structured FA(3) XML goes to KSeF to satisfy the legal mandate, while a human-readable copy — typically a PDF sent via email — goes directly to the foreign buyer for their own records and processing. Both represent the same invoice; KSeF treats the XML as the legally binding version, but the buyer needs something they can actually work with.
Who is exempt? Foreign companies without a fixed establishment in Poland are not required to use KSeF, even if they hold a Polish VAT registration number. This distinction is critical for businesses registered for Polish VAT solely to handle cross-border transactions (distance selling thresholds, for example). If your company has no physical presence, employees, or permanent infrastructure in Poland, you fall outside the KSeF obligation — your Polish VAT registration alone does not trigger it.
What changes for companies receiving invoices from Polish suppliers? In practical terms, not much on the surface. Your Polish suppliers will still send you invoices in whatever format you currently receive — PDF, email attachment, EDI. But there is a structural shift happening underneath. The invoice your AP team processes is now a derivative of structured XML data that already exists in KSeF. The source document is machine-readable from the moment of issuance. For organizations investing in automated invoice processing, this means the data quality of invoices originating from Poland will increasingly be standardized and predictable, since every Polish supplier is working from the same FA(3) schema.
Businesses that supply both Polish government entities and private-sector clients face an additional consideration. The PEF (Platforma Elektronicznego Fakturowania) handles public procurement invoicing using Peppol standards, while KSeF uses its own FA(3) schema. These are separate systems with different formats and submission processes. Companies operating in both spheres need workflows — or tools — that can handle both Peppol-based PEF submissions and KSeF's XML requirements without duplicating manual effort.
Poland is not acting in isolation. Italy has operated mandatory e-invoicing since 2019, Spain's VeriFactu and SII system adds another EU clearance model, and India's GST e-invoicing mandate follows a strikingly similar government-portal clearance approach using JSON rather than XML. For multinational companies, the architectural patterns you build for KSeF — API integration with a government clearance platform, structured XML generation, dual-numbering support — will inform your approach to similar mandates elsewhere, even though each country's specific schema and submission process differs.
Invoice Corrections and Corrective Invoices in KSeF
One of the most operationally significant changes KSeF introduces is the elimination of correction notes (noty korygujące). As of February 1, 2026, correction notes are no longer a valid mechanism for fixing invoice errors. Previously, either the buyer or the seller could issue a correction note to amend minor details. Under KSeF, the only accepted method for correcting an invoice is a corrective invoice (faktura korygująca) submitted through the system.
This matters for every AP team and accounting department that regularly processes corrections. The workflow is fundamentally different.
Corrective invoices must reference the original invoice's KSeF identification number — the system-assigned identifier, not the seller's own internal invoice number. This requirement creates a traceable, system-enforced chain of corrections. Each corrective invoice is permanently linked to the document it modifies within KSeF, giving tax authorities and both trading parties a clear audit trail without manual cross-referencing.
Correcting NIP (Tax ID) Errors
When an invoice is issued to the wrong entity — a common scenario in organizations with multiple subsidiaries or related companies — KSeF requires a two-step correction process:
- Issue a zeroing corrective invoice to the incorrect NIP. This effectively cancels the original invoice within the system by reducing all amounts to zero against the wrong recipient.
- Issue a new original invoice with the correct NIP. This is treated as a fresh document in KSeF, not a modification of the previous one.
There is no shortcut. You cannot simply edit the NIP on the original invoice. The two-step approach ensures that both the incorrect and correct recipients have properly structured documents in their KSeF accounts.
Difference-Only Format
Corrective invoices under KSeF use a difference-only format. Rather than restating the full original values alongside the corrected values (the before/after layout many AP teams are accustomed to), the corrective invoice shows only what changed — the delta between the original and corrected amounts. The notable exception is advance invoice corrections, which follow a separate format structure within the FA(3) schema.
For AP teams, this shift requires adjustments to reconciliation workflows. Matching a corrective invoice to its original now depends on the KSeF identification number reference rather than visually comparing line items. Automated systems that previously parsed before/after columns need reconfiguration to handle difference-only data.
The broader operational impact is straightforward: suppliers can no longer send informal correction notes, and your AP team cannot issue them either. Every correction flows through KSeF as structured XML, which creates consistency and a reliable audit trail — but it also means existing correction handling processes built around correction notes need to be retired and replaced before the mandate takes effect.
KSeF Offline and Contingency Modes
Because KSeF is a centralized government platform, every invoice your business issues in Poland will flow through it. That creates an obvious operational question: what happens when the system is unavailable, or when your own internet connection drops?
Poland's Ministry of Finance anticipated this dependency and designed three distinct offline contingency modes, each triggered by different circumstances and governed by its own upload deadline.
Offline24 — seller connectivity issues. This mode applies when KSeF itself is functioning normally but your organization cannot reach it, whether due to a local internet outage, network misconfiguration, or internal system failure. You generate the invoice locally and must upload it to KSeF by the next business day after your connectivity is restored. The responsibility to monitor restoration and act promptly sits with the seller.
Offline (system unavailability) — KSeF is down. When the Ministry of Finance confirms that KSeF itself is experiencing an outage, this mode activates. All taxpayers are affected simultaneously, and the government publishes official notifications of both the outage start and restoration. Invoices issued during the downtime must be uploaded within 1 business day of the system coming back online.
Emergency mode — extended or exceptional outages. Reserved for prolonged disruptions or extraordinary circumstances, this mode provides a longer buffer. The upload deadline extends to 7 business days, giving organizations time to process potentially large backlogs of invoices that accumulated during the extended downtime.
Across all three modes, one requirement is constant: every invoice issued offline must include a QR code. This code serves as a verification bridge. The buyer can scan it to confirm the invoice's authenticity even before it appears in KSeF, and once the invoice is uploaded, the QR code allows the system to match the offline-issued document to its official KSeF record.
Your invoicing systems need a local fallback capability that can generate FA(3)-compliant invoices with embedded QR codes, queue them reliably, and batch-upload them once KSeF connectivity returns. Treating offline mode as an edge case rather than a planned capability is a risk — network disruptions and system outages are not hypothetical, and the upload deadlines leave little room for manual workarounds.
How KSeF Transforms Invoice Processing and AP Workflows
With domestic B2B invoices now arriving as government-validated FA(3) XML rather than PDFs, scanned images, or paper, the data extraction problem that has defined AP workflows for decades disappears for Polish-origin invoices. Invoice numbers, NIP identifiers, line-item descriptions, unit prices, VAT rate breakdowns, and payment terms all sit in predictable, machine-readable positions. The data is not just digital — it is structured, validated at source, and consistent across every supplier. For AP teams processing domestic Polish invoices, the core problem shifts from "extract data from an unpredictable document" to "map standardized fields into your ERP or accounting system." That is a fundamentally different engineering and workflow challenge.
Dual-numbering and invoice matching introduce a new layer of complexity. Every invoice transmitted through KSeF receives a unique system identification number (numer KSeF) alongside the seller's own invoice number. AP teams must track both references when matching purchase orders, scheduling payments, and reconciling accounts. Starting August 2026, the KSeF reference number becomes mandatory in bank payment titles, which directly ties payment execution to the KSeF ecosystem. For organizations already navigating Poland's split payment mechanism for VAT transactions, this adds another required data point to every payment instruction. Accounting systems and payment workflows need updating to capture, store, and transmit both identifiers reliably.
The transition period creates a mixed-format processing challenge that will persist well beyond the mandate dates. Even after full domestic KSeF adoption, cross-border invoices from EU and non-EU suppliers continue arriving as traditional PDFs, often in foreign languages with varying layouts. Historical invoice archives remain in unstructured formats. The result is a dual-track AP environment: structured XML for Polish domestic transactions, unstructured documents for everything else. Businesses need processing capabilities that handle both formats within the same workflow rather than maintaining separate pipelines. For teams running Comarch ERP Optima, handling foreign-supplier PDFs in Optima after KSeF is a concrete example of that remaining capture workload. Tools built for AI-powered invoice data extraction address exactly this duality — processing batches of mixed-format files (PDFs, scans, and images across languages) and outputting standardized structured data regardless of input format. During the KSeF rollout, that capability bridges the gap between the structured domestic channel and the unstructured international one.
Corrective invoice handling follows the structured chain described in the corrections section above — every adjustment references a specific original via its KSeF ID, replacing free-form correction notes entirely. For AP teams, this creates a clear, machine-traceable correction chain where reconciliation and audit trail construction become straightforward.
Self-billing arrangements (samofakturowanie) require explicit procedural changes. When the buyer issues invoices on behalf of the seller, the seller must first grant authorization within the KSeF platform. Every self-billed invoice must carry the "samofakturowanie" annotation and pass through KSeF validation like any other invoice. Organizations using self-billing — common in recurring supply relationships and logistics — need to establish these authorizations before the mandate takes effect and update their document generation workflows to include the required annotation and KSeF submission step. The full scope of Poland's samofakturowanie agreement and compliance requirements extends well beyond KSeF authorization, covering the written agreement terms, VAT obligations, and cross-border complications that apply regardless of the e-invoicing mandate.
Organizations that treat KSeF purely as a compliance checkbox — uploading invoices to the government portal without rethinking their data extraction and AP workflows — will find themselves maintaining two parallel processes indefinitely. Those that recognize KSeF as a structural shift in how invoice data is created and transmitted can use it as the foundation for faster three-way matching, automated reconciliation, and real-time cash flow visibility across their Polish operations.
Related Articles
Explore adjacent guides and reference articles on this topic.
Poland Freelancer Invoice Requirements: JDG Invoicing Guide
Polish freelancer invoice requirements: mandatory fields (Art. 106e), VAT threshold, timing rules, corrective invoices, and KSeF 2027 for JDG sole traders.
Poland Self-Billing Invoice Requirements (Samofakturowanie)
Complete guide to samofakturowanie in Poland: legal framework, agreement requirements, KSeF authorization workflow, and cross-border complications.
Slovakia E-Invoicing Requirements: 2027 Guide
Slovakia's e-invoicing rules become legally valid in 2026 and start for domestic B2B/B2G in 2027. Learn the XML, Peppol, and prep steps.
Extract invoice data to Excel with natural language prompts
Upload your invoices, describe what you need in plain language, and download clean, structured spreadsheets. No templates, no complex configuration.