KSeF is not just a new invoicing format. It is a clearance model — which means your invoice does not legally exist until the Polish government validates it. That changes everything. This guide covers what that means in practice for every team involved.
KSeF is live. Large taxpayers (2024 turnover above PLN 200 million) have been issuing invoices through KSeF since 1 February 2026. All other VAT-registered businesses — including foreign companies with Polish VAT registration and a fixed establishment in Poland — must comply from 1 April 2026. Micro-entrepreneurs follow on 1 January 2027, which is also when enforcement penalties begin. During 2026, the Polish tax authority is not imposing financial penalties — but invoices issued outside KSeF are not legally valid for B2B transactions. From 2027, non-compliance means rejected invoices, blocked VAT deductions, and fines.
In this guide
Why KSeF is different from every other mandate The clearance model — what it actually means The five biggest challenges nobody warned you about The FA(3) schema — what changed and why it matters Accounts Payable Accounts Receivable Payments — the team nobody invited ERP complexity and API integration Master data — NIP numbers and the data problem Intercompany invoicing Expenses Tax — JPK_VAT, SAF-T and what changes Authentication, ZAW-FA and access delegation Offline mode and business continuity Stream-by-stream checklistMost e-invoicing mandates are about format. They tell you to stop sending PDFs and start sending structured XML. Your invoice goes from you to your customer in a new format, through a new channel. The obligation is on the output.
KSeF is different. It is a clearance model — the same architecture used by Italy's SDI, which has been running since 2019 and is widely considered the most effective VAT compliance system in Europe. In a clearance model, your invoice does not go directly to your customer. It goes to the government first. The government validates it, assigns it a unique number, and only then makes it available to your buyer. Until that happens, the invoice has no legal force.
This distinction matters enormously. Under a reporting or PEPPOL-based mandate, a technical failure means your invoice arrives late or in the wrong format. Under KSeF, a technical failure means your invoice does not legally exist. Your customer cannot deduct the VAT. You cannot recognise the revenue. The transaction, for all tax purposes, did not happen.
This is why companies that treat KSeF as a simple IT integration project — change the output format, connect to an API, done — consistently underestimate what is actually required. The legal stakes of every technical decision are fundamentally higher than anything finance teams have dealt with before in an e-invoicing context.
02Here is how KSeF works in practice. Your AR system generates an invoice in the FA(3) XML schema. That invoice is submitted to the KSeF platform via API. KSeF validates the data — format, mandatory fields, NIP numbers, schema compliance. If it passes, KSeF assigns a unique KSeF ID number (the KSeF reference) and timestamps the invoice. The invoice is now legally valid. Your buyer retrieves it from KSeF using their own credentials — not from your email, not from a supplier portal, not from any other channel.
The buyer does not receive the invoice. They collect it. That is a meaningful operational difference for every AP team that has built its entire invoice receipt process around email inboxes, supplier portals, and PDF scanning.
If KSeF rejects your invoice — wrong NIP, missing mandatory field, schema error — the invoice is rejected before it exists. You fix it and resubmit. There is no "please ignore the previous invoice, here is a corrected one" process. There is no correction note. From February 2026, correction notes are abolished entirely. All corrections must be issued as corrective invoices through KSeF, using a specific two-step process for common errors like an incorrect buyer NIP.
The KSeF ID assigned to every validated invoice is the reference that links your ERP, your buyer's ERP, the Polish tax authority, and the JPK_VAT reporting system together. It is mandatory in SAF-T filings from February 2026. Your ERP must capture it at the point of invoice submission and store it against the invoice record. Any system that does not capture and propagate the KSeF ID creates a downstream reconciliation problem that will surface in your first JPK_VAT filing.
Challenge 1 — Your buyer does not receive your invoice. They retrieve it. Every process your AR team uses to confirm invoice delivery, chase payment, and handle disputes is built on the assumption that you sent something to the buyer and they received it. Under KSeF, you submit to the government and the buyer collects. If a buyer claims they never received your invoice, the conversation is now about whether they retrieved it from KSeF — a very different situation from resending a PDF.
Challenge 2 — Correction notes are gone. The most common way companies handle invoice errors — a quick correction note from the buyer — is no longer valid from February 2026. All corrections go back through KSeF as corrective invoices issued by the seller. Your AR team needs a completely redesigned correction and dispute process. This is not a minor workflow change; it affects credit control, collections, and month-end close.
Challenge 3 — The NIP number is now a hard dependency. Every invoice must carry the correct NIP number for both the issuer and the buyer. KSeF validates this at submission. A wrong NIP means rejection. A missing NIP means rejection. For a large enterprise with hundreds of Polish customers in their master data, the NIP data quality exercise is a significant project — not a half-day cleanup.
Challenge 4 — Offline is an exception, not a fallback. Companies used to EDI or email invoicing are accustomed to having fallback processes when systems go down. Under KSeF, offline invoicing is permitted only in specific technical circumstances (system unavailability, offline24 mode), requires a QR code, and must be submitted to KSeF by the next business day. It is a contingency mechanism, not a normal operating mode. Your business continuity plan needs to account for this.
Challenge 5 — The ZAW-FA form is a prerequisite most companies miss. Any entity other than a natural person must file a ZAW-FA form with the Polish tax office to authorise individuals or third parties (external accountants, BPO providers, shared service centres) to issue invoices through KSeF on their behalf. Without it, your external accounting firm or SSC cannot issue invoices for you. This form must be filed before your go-live date. It is not a technical step — it is a legal-administrative step that takes time and requires identifying exactly who will have which access levels.
04KSeF 2.0 introduced a new invoice schema — FA(3) — replacing FA(2) from January 2026. The Ministry of Finance published the final FA(3) specification in May 2025, and all invoices submitted to KSeF from February 2026 must conform to it. FA(2) invoices are no longer accepted.
FA(3) introduces new mandatory fields, strengthens validation controls, and improves consistency between invoice data and VAT accounting records. The practical implication for finance teams is that invoices which passed validation under FA(2) may fail under FA(3) if the new mandatory fields are not populated. This is not a theoretical risk — companies that ran their first FA(3) test submissions in late 2025 consistently found fields that their ERP configuration had never populated because they were optional under FA(2) or simply not required at all under PDF invoicing.
The most commonly missed FA(3) fields include: the buyer's NIP in a specific format, the invoice type code distinguishing B2B from B2G transactions, the payment method code, and line-level tax codes using the specific Polish taxonomy rather than generic VAT rate descriptions. Your ERP configuration needs to map each of these from your existing data model — which in many cases means adding new fields to your customer and product master data.
SAP's KSeF integration for S/4HANA uses the SAP Document Compliance framework. The FA(3) content package was released in late 2025. If your S/4HANA system has not applied this content package and the corresponding Customising, it will not generate valid FA(3) XML. Check your SAP Notes and content package version before assuming your integration is ready. For SAP ECC, the situation is more complex — native FA(3) support is limited and typically requires either a middleware solution or a certified third-party connector.
Under KSeF, AP teams no longer receive invoices. They retrieve them. This is not a semantic distinction — it fundamentally changes how AP workflows are structured.
Your Polish suppliers who are large taxpayers have been submitting invoices through KSeF since February 2026. Those invoices are sitting in KSeF, assigned a KSeF ID, waiting for your AP system to collect them. If your AP system is not connected to KSeF — via your own API integration or through an intermediary platform — you are manually logging into the KSeF Taxpayer Application and downloading invoices one by one. For a company receiving hundreds of invoices per month from Polish suppliers, that is not sustainable.
The other critical change for AP is the rejection process. Under KSeF, you cannot reject an invoice the way you used to — by emailing the supplier asking for a correction. If you receive an invoice with an error, you work with the supplier to issue a corrective invoice through KSeF. The original invoice remains in the KSeF system. The correction must follow the new two-step process. Your AP team needs to understand this and your supplier communication process needs to be updated.
AR is where the clearance model creates the most significant process change. Every B2B invoice you issue to a Polish customer must be submitted to KSeF before it has any legal validity. You cannot issue a paper invoice, a PDF, or an unstructured electronic invoice. From your compliance date, those documents do not exist as legal invoices for B2B transactions.
The submission process is: your ERP generates the invoice in FA(3) XML, the XML is submitted to KSeF via API, KSeF validates and returns a KSeF ID, your ERP stores the KSeF ID, and your customer retrieves the invoice from KSeF using their own access. Your customer's payment terms do not start until they have retrieved the invoice — or from the date KSeF accepted it, depending on the agreed payment terms structure. This timing implication matters for DSO and cash flow management.
The abolition of correction notes creates a specific challenge for AR. Many companies use buyer-issued correction notes as a quick way to handle small disputes — a quantity adjustment, a pricing correction, a discount not applied. From February 2026, all such corrections must come back as corrective invoices issued by you, the seller, through KSeF. This means your AR team needs approval workflows for corrective invoices, and your credit control process needs to be redesigned around a seller-issued correction model.
The payments team is not typically invited to e-invoicing projects. Under KSeF, this is a mistake with real consequences.
The KSeF ID assigned to every invoice is a mandatory reference in Polish bank transfer data from 2026. When your company pays an invoice, the payment instruction to the bank should include the KSeF ID as a reference. This links the payment to the specific KSeF-validated invoice in the tax authority's system and simplifies VAT reconciliation for both parties.
More significantly: Poland's VAT split payment mechanism (mechanizm podzielonej płatności — MPP) is affected by KSeF. Invoices above PLN 15,000 for certain goods and services are subject to mandatory split payment — the net amount goes to the supplier's regular account and the VAT amount goes to a dedicated VAT account. The KSeF ID links the MPP payment to the specific invoice. If your payment system cannot include KSeF IDs in payment references, you have a manual reconciliation problem building up from day one.
If your company makes payments to Polish suppliers subject to mandatory split payment (MPP) and your payment instructions do not correctly reference the KSeF ID, the supplier may face VAT account issues and the payment may not be correctly matched to the invoice in the tax authority's system. Both you and your supplier have an interest in getting this right — but it requires your treasury and payments team to understand KSeF, which most of them currently do not.
KSeF requires a real-time API connection between your invoicing system and the Polish government's platform. This is a technical integration, not a format change — and the complexity of that integration depends almost entirely on your ERP landscape.
The KSeF 2.0 API is a REST API with specific authentication requirements. Access methods include a qualified electronic seal, a token (available until end of 2026), or a KSeF certificate. From 2026, KSeF certificates are the recommended authentication method for system-to-system integrations. Your IT team needs to manage certificate lifecycle — issuance, renewal, and revocation — as part of the ongoing KSeF operation, not just the initial implementation.
For SAP S/4HANA, the integration approach depends on whether you use SAP Document Compliance with the Polish content package, a third-party connector (Pagero, Edicom, Sovos, and others offer certified KSeF connectors), or a middleware integration. Each has different implications for your upgrade path, your maintenance burden, and your ability to handle future schema changes when FA(4) eventually arrives.
For SAP ECC, the situation is harder. SAP's native KSeF support is designed for S/4HANA. ECC customers typically need either a third-party certified connector that handles the API submission independently, or a middleware layer. Some ECC customers have used this as the forcing function to accelerate their S/4HANA migration — a decision that requires careful evaluation of timeline and cost against the mandate deadline.
One technical detail that catches teams by surprise: the offline24 mode. KSeF 2.0 allows invoices to be issued offline in specific circumstances — system unavailability, technical failures — provided they are submitted to KSeF by the next business day and carry a QR code. Your integration must handle this contingency flow, not just the standard API submission path. An integration that only handles the happy path will fail your business continuity requirements.
Under KSeF, the NIP number — Poland's tax identification number — is not an optional field. It is the routing key. KSeF validates the buyer's NIP at submission. An incorrect NIP means the invoice is rejected. A missing NIP means the invoice cannot be submitted. There is no workaround.
For a large enterprise with a significant Polish supplier and customer base, the NIP data quality exercise is frequently the most time-consuming part of the entire KSeF implementation. NIPs that were entered years ago and never verified. Suppliers who changed their legal structure and acquired a new NIP. Customers who have multiple Polish entities with different NIPs but are stored as a single record in the ERP. Intercompany counterparties whose NIP was never entered because nobody needed it for PDF invoicing.
The validation is straightforward — the Polish tax authority maintains a public API (the White List, or Biała Lista) that allows you to verify whether a NIP is valid and active, and crucially, whether the bank account associated with it matches what you have on file. This is particularly important for supplier payments — paying a supplier whose bank account does not match the White List record creates VAT deductibility risk.
Intercompany invoices between Polish legal entities — or from a Polish entity to another group entity with Polish VAT registration — must go through KSeF. This catches most multinational groups by surprise, because intercompany invoicing is almost universally run on processes that are entirely incompatible with a real-time API submission model.
Excel spreadsheets. Monthly batch files. Journal entries that substitute for formal invoices. Shared drives. Processes that were designed for internal convenience rather than external compliance. All of these need to be replaced with a KSeF-compatible invoicing process before your compliance date.
The transfer pricing implication is the same as in France — KSeF creates a real-time, validated, government-visible audit trail of every intercompany transaction. If your intercompany pricing and your TP documentation are not fully consistent with what you are submitting through KSeF, you have created an audit risk that is now much easier for the Polish tax authority to detect.
The KSeF scope for expenses follows the same logic as France PPF — the distinction is between B2C receipts and B2B invoices addressed to your company.
Consumer receipts (meals, taxis, retail) are B2C transactions. KSeF is optional for B2C — your employees can still submit paper or PDF receipts for these. The mandate does not change expense reimbursement for personal purchases.
But invoices addressed to your Polish legal entity — hotel bills billed to the company, car rental invoices, professional services, agency fees — are B2B invoices and must come through KSeF from the supplier's compliance date. If an employee submits a PDF invoice from a Polish hotel that has already moved to KSeF, that document is not a valid legal invoice. The valid invoice is sitting in KSeF waiting to be retrieved.
The practical question for your expense team is: how do invoices addressed to the company but submitted through an employee expense process get reconciled with the corresponding KSeF invoice? This requires a defined process — matching the employee's receipt reference to the KSeF ID in the system — that most expense management platforms have not yet fully solved.
KSeF changes Poland's tax reporting landscape significantly — and Tax teams need to own these changes, not just be briefed on them by IT.
The most immediate change is to JPK_VAT (the Polish Standard Audit File for Tax — equivalent to SAF-T). From February 2026, all invoices issued through KSeF must be reported in JPK_VAT with their KSeF ID. New invoice designation codes are introduced — OFF for invoices issued outside KSeF in offline mode, BFK for paper or electronic invoices, DI for other KSeF documents. These codes must be applied correctly in your SAF-T reporting or you face separate compliance penalties.
An important upside: KSeF effectively pre-populates the tax authority's view of your transaction data. The Polish Ministry of Finance has signalled that KSeF data will increasingly be used to pre-fill VAT return data, reducing the reconciliation burden for compliant companies. The flip side is that discrepancies between your KSeF submissions and your JPK_VAT filings become immediately visible. Tax teams that have historically used the lag between filing and audit to manage timing differences need to plan for a much shorter window.
The 10-year KSeF archiving obligation replaces the previous requirement for companies to independently archive invoice XML files. KSeF stores every validated invoice for 10 years from the end of the calendar year in which it was issued. This is a genuine administrative simplification — but Tax needs to confirm that they can retrieve invoices from KSeF for audit purposes and understand the process for doing so.
This is the section most companies skip over in their project planning and then scramble to complete two weeks before go-live.
To issue or retrieve invoices through KSeF, your organisation needs to be authenticated. The methods available are: a qualified electronic seal (for legal entities), a token (available until end of 2026 and then being phased out), or a KSeF certificate (the preferred method from February 2026 onwards). You need to choose your authentication method, obtain the relevant credentials, and configure them in your integration before you can submit a single invoice.
More importantly: any third party who will access KSeF on your behalf — your external accountant, your BPO provider, your shared service centre, even specific employees who will have system-level access — must be formally authorised via the ZAW-FA form, submitted to the Polish tax office. This is not a technical step. It is a legal-administrative process. It requires knowing exactly who needs access, at what level, and filing the form with the correct information. If your external accounting firm has not been authorised via ZAW-FA before your go-live date, they cannot issue invoices for you on day one.
KSeF is a government platform. Government platforms go down. The question is not whether KSeF will experience outages — it is what your business does when it does.
KSeF 2.0 provides two contingency mechanisms. The offline24 mode allows invoices to be issued outside KSeF in specific technical circumstances, with mandatory submission to KSeF by the next business day. These invoices must include a QR code for verification. The emergency mode covers total system outages declared by the Ministry of Finance. Both modes have specific technical requirements that must be built into your integration — they are not automatic fallbacks.
Your business continuity plan for Polish invoicing needs to address: what triggers the switch to offline mode, who authorises it, how QR codes are generated, how the next-day submission is managed, and how you monitor for KSeF outages in real time. This is operational planning, not just a technical capability. The teams involved are AP, AR, IT, and Finance Operations — none of whom should be figuring this out for the first time during an actual outage.
Our Poland KSeF Readiness Assessment covers all six internal streams — AP, AR, Payments, ERP, Master Data, and Tax. 45 minutes. Stream-by-stream readiness score. Prioritised action plan. Built on official Ministry of Finance requirements.
Take the assessment — €89 Book a 30-minute call insteadRead our companion guide: France PPF e-Invoicing Requirements 2026 →
This guide reflects our practical experience working on KSeF implementations and is updated as the Ministry of Finance publishes new technical specifications. For official regulatory text, refer to gov.pl and the KSeF documentation at ksef.mf.gov.pl. This guide does not constitute legal or tax advice. © 2025 Lumara Advisory. All rights reserved.