KSeF Errors: Why Your Invoice Got Rejected and How to Fix It
You hit "send," and instead of a KSeF number you get a rejection message. Or worse — the invoice goes through, but with wrong data that can no longer be "cancelled." These are two fundamentally different problems, and each has a different fix.
If you run a business in Poland, the stakes are rising. KSeF (Krajowy System e-Faktur — Poland's national e-invoicing system) became mandatory for large taxpayers on 1 February 2026 and for virtually everyone else on 1 April 2026. The penalty-free transition period ends on 31 December 2026; from 1 January 2027, tax authorities can impose financial penalties for KSeF violations (biznes.gov.pl).
This guide walks through the six most common submission errors — from rejected XML files to duplicate error 440 — and shows when you simply fix and resend, and when a correction invoice is unavoidable.
Rule #1: a rejected file is not an issued invoice
Before we get into specific errors, one principle saves a lot of stress: if KSeF rejected your file, the invoice was never legally issued. You don't need a correction invoice — you fix the data and submit again. Think of it as a clean second attempt.
A correction invoice (faktura korygująca) is only required when the invoice passed validation, received its KSeF number, and contains a substantive error — wrong buyer, wrong amount, wrong VAT rate. There is no "cancel" button in KSeF: every accepted invoice with a mistake can only be repaired through a correction.
Error 1: file doesn't match the FA(3) schema
Since 1 February 2026, every structured invoice must comply with the FA(3) logical structure. KSeF doesn't care how your invoice looks — it checks whether the XML matches the schema: all mandatory fields present, dates in YYYY-MM-DD format, the Polish tax ID (NIP) written as 10 digits with no hyphens and no PL prefix, UTF-8 encoding throughout.
Typical rejection causes:
a missing mandatory field (e.g. issue date
P_1or sale dateP_6),NIP formatted as
123-456-78-90instead of1234567890,a file generated against the older FA(2) schema instead of FA(3),
disallowed characters or wrong encoding in text fields.
How to fix it: read the error message. The KSeF 2.0 API returns a specific code (exceptionCode) and a description in the Details field. The full list of codes is published in the integrator documentation at ksef.podatki.gov.pl and in the official CIRFMF/ksef-docs repository. Correct the flagged field and resend. If you use invoicing software rather than hand-built XML, a good system validates the file before submission and never lets a rejection happen.
Error 2: duplicate invoice (code 440)
KSeF 2.0 flags an invoice as a duplicate when three parameters match an invoice already in the system: the seller's NIP, the invoice type, and the invoice number (field P_2). The amount and the buyer don't matter. Uniqueness is checked globally across the entire system — and enforced for 10 years.
The most common scenario: your system doesn't receive a confirmation (timeout, dropped connection), someone clicks "send" again — but the first submission actually went through.
How to fix it: before retrying, check the status of the original session — the invoice may already have a KSeF number. If error 440 comes from genuinely duplicated numbering (e.g. two systems issuing from the same series), change the invoice number and enforce a single source of numbering.
Error 3: issue date in the future
A future date in field P_1 — later than the moment the file is submitted — means guaranteed rejection. The reverse is legal: if P_1 holds an earlier date than the submission day, KSeF accepts the invoice as issued in offline24 mode, and the issue date is the date from P_1.
How to fix it: correct the date and resend. If your workflow involves preparing invoices in advance, hold the submission until the right day — or configure your system to queue documents.
Error 4: authorization problems — token, certificate, permissions
The second large group of errors has nothing to do with invoice content. It's about access: an expired token, an invalid KSeF certificate, or missing permissions to issue invoices on behalf of the entity. This hits foreign-owned companies particularly often — permissions for a Polish subsidiary may require a prior notification to the tax office (e.g. via the ZAW-FA form), and accounting firms issuing as proxies need explicitly granted rights.
How to fix it: refresh or generate a new token/certificate and verify permissions in the KSeF permissions module. The Ministry of Finance publishes a step-by-step access guide at ksef.podatki.gov.pl. Important: a document submitted by an unauthorized person is rejected, so the invoice doesn't exist — once access is sorted, you submit it normally.
Error 5: invoice accepted — but substantively wrong
Here the real trouble begins, because KSeF does not validate invoices on the merits. The system doesn't check whether VAT is calculated correctly, whether the rate is right, or whether the buyer's NIP belongs to the company you actually sold to. A schema-compliant file passes — errors included — and you still get a KSeF number.
The two most frequent cases from the first months of mandatory KSeF:
Wrong buyer — typically after using a "clone invoice" function and forgetting to swap the counterparty. The only path: a correction invoice down to zero, plus a new invoice with the correct data. Catch the mistake within the month of sale and you avoid settling "double" VAT.
Calculation error or wrong VAT rate — fixed with a standard upward or downward correction, no need to zero out the whole invoice.
The systemic fix: move validation upstream, before submission — verify the counterparty's NIP against the official VAT whitelist, cross-check line totals, block submission when data is incomplete. KSeF won't do any of this for you.
Error 6: no status monitoring and system downtime
No rejection message does not mean the invoice was accepted — sometimes it only means your system never received the response. An invoice without a confirmed status and without a UPO (Urzędowe Poświadczenie Odbioru — the official acknowledgement of receipt) is an invoice in limbo.
A separate case is downtime on KSeF's side. Polish regulations provide for offline and emergency modes: you issue the invoice outside the system and upload it to KSeF within the statutory deadline once availability is restored.
How to fix it: monitor submission statuses (ideally automatically), download UPOs, and follow the Ministry of Finance availability announcements. API-integrated systems should include a retry mechanism with duplicate control — see error 2.
Checklist: before you hit "send to KSeF"
[ ] File generated against the current FA(3) schema, not FA(2)
[ ] All NIPs written as 10 digits — no hyphens, no
PLprefix[ ] Issue date (
P_1) is not in the future[ ] Invoice number unique — one numbering source across all issuing channels
[ ] Buyer data verified (especially after cloning a previous invoice)
[ ] KSeF token/certificate valid, permissions granted and confirmed
[ ] After submission: status checked and UPO downloaded — only then is the job done
Get it right the first time
Most KSeF errors fall into two buckets: technical (fix and resend) and substantive (a correction awaits). Both are best caught before submission — because from 1 January 2027, mistakes stop being merely annoying and start costing money.
Biurko validates every invoice against the FA(3) schema, verifies counterparty NIPs, guards your numbering, and automatically retrieves UPOs — before anything reaches KSeF. Try Biurko free for 14 days at biurko.io and stop fighting error codes.
FAQ
What should I do when KSeF rejects my invoice?
A rejected invoice was never legally issued, so no correction invoice is needed. Read the error code in the response, fix the flagged data — usually the FA(3) schema, NIP format, a missing field, or the date — and resubmit the document to KSeF.
What does KSeF error 440 mean?
Code 440 means a duplicate invoice. KSeF 2.0 detects duplicates by three fields: seller's NIP, invoice type, and invoice number (P_2). Check whether the original submission was already accepted and whether your invoice numbering overlaps between systems.
Can I cancel an invoice already sent to KSeF?
No. An invoice that received a KSeF number is legally issued and cannot be cancelled or edited. Any substantive error — wrong buyer, amount, or VAT rate — can only be fixed with a correction invoice, in the worst case a correction to zero plus a new invoice.
Does KSeF verify amounts and VAT rates?
No. KSeF only validates XML compliance with the FA(3) structure, plus permissions and duplicates. The issuer is responsible for amounts, rates, and counterparty data — which is why substantive validation belongs in your invoicing software, before submission.
When do penalties for KSeF errors start in Poland?
Financial penalties for KSeF violations can be imposed from 1 January 2027. Until 31 December 2026 a penalty-free transition period applies, but the obligation to issue invoices in KSeF has been in force since 1 February 2026 (large taxpayers) and 1 April 2026 (everyone else).