KSeF Error Codes: What the System Actually Rejects and How to Fix It

A rejected invoice does not exist. Legally, it never happened. You cannot correct it, cancel it, or reference it in JPK_V7. You fix the error and resend. That distinction sounds trivial until you are staring at a 21401 exception code at 4:55 PM on a Friday with a client waiting for payment.

Grant Thornton's April 2026 survey found that 74% of businesses hit e-invoicing errors in the first month of mandatory KSeF. Twenty percent said those errors disrupted daily operations. The pain is not theoretical. It is the single most common post-launch experience in the Polish invoicing ecosystem.

This article maps every rejection code in the KSeF 2.0 taxonomy to its cause, the failing field, and the exact fix. It also names the fabricated codes circulating in content-farm articles, because acting on a fake rejection taxonomy wastes time and delays resubmission.

KSeF Rejects for Only Two Reasons

The Ministry of Finance confirmed publicly in May 2026 that KSeF validates only two things: FA(3) schema compliance and sender permissions. It does not check VAT arithmetic. It does not verify buyer data against the tax registry. It does not validate the FX rate value. It does not cross-reference invoice amounts against any external database.

A schema-compliant invoice with the wrong VAT rate, the wrong buyer NIP, and a fabricated exchange rate will pass KSeF validation and receive a KSeF number. The state assigns the number, issues the UPO (potwierdzenie przyjęcia), and the invoice enters legal circulation. The substantive error surfaces weeks later during reconciliation, during an audit, or when the buyer discovers they cannot deduct input VAT because the invoice carries someone else's NIP.

This is not a design flaw. It is the architecture. KSeF is a clearance system, not a validation system. Substantive validation is the taxpayer's job, which means it is either a manual checklist or a product feature. Plandesk ships pre-send validation that checks what KSeF does not: NIP checksum and registry lookup, VAT arithmetic, duplicate invoice numbers, NBP rate verification, and GTU code consistency.

Session Statuses: When Your Invoice Actually Exists

Before decoding rejection codes, you need to understand session statuses. The most damaging post-launch mistake is not a rejection. It is a duplicate caused by resending during processing.

Statuses 100 and 150 are not errors. They mean KSeF received the invoice and is processing it. The Ministry's processing time varies from seconds to hours under load. Resending during this window creates a duplicate invoice with a different KSeF number, which is the most common cause of code 440 rejections.

If you are using a tool that auto-polls, let it work. If you are using Aplikacja Podatnika manually, refresh the session status page. Do not click "send" again.

The Real Error-Code Taxonomy

KSeF 2.0 returns an HTTP status plus an exceptionCode in the response body. The codes below are drawn from the official OpenAPI documentation maintained by the Ministry of Finance. They are the codes practitioners actually encounter.

Code 21401: FA(3) Schema Validation Failure

What it means: The XML you submitted does not conform to the FA(3) schema.

Typical root causes:

• Outdated FA(2) template still in use (FA(2) was permanently disabled on 1 February 2026)
• BOM (byte order mark) bytes at the start of the XML file
• Wrong element ordering or missing mandatory elements
• Incorrect namespace declaration

Fix: Regenerate the invoice from a current FA(3) template. If you are using invoicing software, update it to the latest version. Never hand-edit XML. The schema is strict enough that manual edits introduce more errors than they fix.

Scenario: A freelancer's invoice is rejected with 21401 because their invoicing tool was last updated in January 2026 and still generates FA(2) XML. The fix is a software update, not an XML edit.

Code 21405: Input Validation Error

What it means: A field-level format validation failed. The XML is structurally valid but a specific field contains data in the wrong format.

Typical root causes:

• NIP with dashes, spaces, or a "PL" prefix (FA(3) expects 10 digits, no separators)
• Date in the wrong format (FA(3) requires YYYY-MM-DD)
• Numeric field with comma decimal separator instead of dot
• KursWaluty with fewer than 6 decimal places

Fix: Correct the source data in your contractor card or invoice form, then resend. The error response includes the field path, which tells you exactly which element to fix.

Scenario: A sole proprietor's invoice is rejected with 21405 because the contractor card stores the buyer NIP as "PL-123-456-78-90". FA(3) expects "1234567890". Fix the contractor card, regenerate, resend.

Code 21301: Authorization Failure

What it means: The sender does not have permission to issue invoices for the NIP in the invoice header.

Typical root causes:

• Token expired (KSeF tokens have a validity period that depends on the grant type)
• Token issued for a different NIP than the one in the invoice
• Administrator granted issuing rights but the grant has not propagated
• Using a personal login (Profil Zaufany) instead of a token or certificate

Fix: Regenerate the token with the correct scopes for the issuing NIP. If using a personal login, switch to token-based authentication. Token-based auth was the recommended method before launch and became the de facto standard after the Profil Zaufany collapse on 2-3 February 2026.

Scenario: An accounting office tries to issue an invoice for a new client but receives 21301. The biuro's token was issued before the client was added to their KSeF permissions. The fix is to grant issuing rights for the client's NIP, then regenerate the token.

Code 440: Duplicate Invoice

What it means: An invoice with the same number from the same issuer already exists in KSeF.

Typical root causes:

• Blind resend after a timeout (the most common cause)
• Parallel issuance through both an invoicing app and Aplikacja Podatnika
• Session status not checked before resending

Fix: Query KSeF by your own invoice number before resending. If the first submission succeeded (status 200), adopt the existing invoice. Do not create a duplicate. If the first submission genuinely failed, fix the error and resend with the same invoice number.

Scenario: A user submits an invoice, receives a timeout, and resubmits. The first submission actually succeeded but the response was delayed. The second submission hits 440. The correct action is to check the first session's status, find the 200, and use that KSeF number.

HTTP 500, 503, 429: Server-Side Errors

What it means: The KSeF platform is overloaded or rate-limiting requests.

Typical root causes:

• Launch-period traffic waves (February and April 2026)
• Rate limiting after too many requests in a short window
• Transient infrastructure issues

Fix: Implement retry-with-backoff. If the error persists, switch to offline24 mode (issue the invoice locally, submit by the next working day). The P_1 issue date is preserved in offline mode, so the invoice's legal date does not shift.

Ghost Invoices: Accepted but Invisible

A pattern that does not produce a rejection code but causes equal pain: the invoice is accepted (status 200, KSeF number assigned, UPO issued), yet the buyer cannot see it in their KSeF inbox. Their VAT deduction is blocked. Experts attribute this to ERP-to-KSeF integration bugs and unclear sent/accepted/rejected status semantics.

The invoice exists. It is in legal circulation. The buyer's accountant just cannot access it. The workaround is for the seller to share the KSeF number and UPO directly with the buyer, who can then query KSeF manually. The structural fix is better status synchronization between KSeF and commercial accounting systems, which is one of the problems the Ministry's announced "7 improvements" package for 1 January 2027 is supposed to address.

Fabricated Error Codes to Ignore

Content farms have invented error codes that do not exist in the KSeF API documentation. If you search for KSeF error codes, you will find articles referencing codes like "TOTAL_MISMATCH", "NIP_REGISTRY_REJECTION", or "VAT_RATE_INVALID". These are fabricated. They do not correspond to any exceptionCode in the official OpenAPI specification.

The Ministry of Finance has stated publicly that KSeF does not validate arithmetic, buyer data, or VAT rates. Any article claiming KSeF rejects invoices for wrong VAT amounts or unregistered buyer NIPs is wrong. Those errors pass KSeF. They surface later as corrections, audits, or lost input-VAT deductions.

If you encounter an error code not listed in the official documentation, check the source. The authoritative reference is the OpenAPI specification published by the Ministry of Finance and mirrored in the KSeF API documentation repository.

Seven Checks Before Every Submission

Run these before sending any invoice to KSeF. They catch the errors KSeF will not.

1. NIP format: 10 digits, no dashes, no spaces, no "PL" prefix.
2. NIP checksum: Validate the control digit. KSeF does not check this.
3. NIP registry lookup: Verify the buyer exists on the biała lista podatników VAT.
4. VAT arithmetic: Net times rate equals VAT. Net plus VAT equals gross. Check every line.
5. Invoice number uniqueness: Query KSeF for your own invoice number before sending.
6. Date consistency: Issue date (P_1) is today or within the offline24 window. No backdating.
7. Currency fields: KodWaluty is a valid ISO 4217 code. KursWaluty has 6 decimal places. The rate matches the NBP table for the correct day.

These checks take seconds in software and eliminate the majority of post-launch errors. Doing them manually is possible but error-prone, which is why pre-send validation exists as a product feature rather than a documentation exercise.

This material is information of a general nature and does not constitute legal or tax advice. For a specific situation, verify the current rules or consult a qualified adviser.