KSeF Kit

Rejections & troubleshooting

KSeF is never a dead end. A known code gets a calm explanation and a concrete next step; an unknown code routes to us. The invoice is held safely — you can always resubmit.

Rejected, held, or queued

First tell three situations apart — they look similar but have completely different causes:

  • Rejected — KSeF actively refused: it didn't accept the invoice and returned a code. Something in the data or the connection needs fixing. See Rejections.
  • Held — we deliberately did not send it, because it isn't a KSeF document or it's a shape we don't file yet. Nothing failed — KSeF simply doesn't apply here, or that invoice shape is on the way. See Held.
  • Queued / blocked — it's waiting to be sent because the free quota is used up or the company profile is incomplete. It's not a KSeF error. See Plans & billing.

In all cases the invoice waits safely and you can resubmit it once the cause is cleared.

Held

Held is a deliberate non-filing — nothing failed. Nothing went to KSeF because either the sale isn't a KSeF document at all, or it's an invoice in a shape we don't file yet. There's no error code, no email alert, and nothing turns red. Each reason below explains what it means, why nothing was filed, and what to do next.

Out of KSeF scope

What it means: a consumer (B2C) sale, or there's no buyer tax ID. KSeF covers business-to-business (B2B) invoices with a Polish NIP — this sale doesn't fall under it.

Why nothing was filed: it simply isn't a KSeF document, so there's nothing to send.

What to do: handle the sale through your usual process (receipt / VAT records). If it was meant to be a business invoice, add the buyer's NIP in Stripe and resubmit.

Out of KSeF scope (EU OSS)

What it means: the sale looks like a digital service to a consumer in another EU country. Those are settled through VAT-OSS (One Stop Shop), not KSeF.

Why nothing was filed: KSeF covers domestic B2B invoices, not EU B2C — that's a different settlement path.

What to do: account for the VAT in your OSS return. There's nothing to do on the KSeF side.

Unsupported domestic rate

What it means: this is a domestic business invoice, but at a 0% or exempt VAT rate. Today we file invoices at 23%, 8% and 5%.

Why nothing was filed: we don't build that rate into FA(3) yet, so we'd rather file nothing than file it wrong. This rate is on the way.

What to do: if the invoice is due now, file it manually in the KSeF taxpayer app for now. Once we add the rate, future invoices like it will file automatically.

Self-invoice

What it means: the buyer's NIP is the same as your own. KSeF won't accept an invoice you issue to yourself (in the schema: Podmiot1 = Podmiot2).

Why nothing was filed: KSeF would reject it anyway — we stop it earlier, before it reaches the authority.

What to do: check the customer's tax ID on the Stripe invoice. If it's a typo, correct the buyer NIP and resubmit.

Multi-rate invoice

What it means: the invoice mixes more than one VAT rate (for example 23% and 8% line items on one document). Today we file single-rate invoices.

Why nothing was filed: we don't build a multi-rate document yet, and we won't file one incorrectly.

What to do: split the sale in Stripe into separate invoices — one per rate — and resubmit them, or file this invoice manually for now. Multi-rate support is on the way.

Foreign-currency correction

What it means: this is a correction (KOR) in a foreign currency carrying Polish VAT. That correction needs the VAT restated in PLN, which we don't file yet.

Why nothing was filed: we don't build this particular correction shape yet. Ordinary PLN corrections and foreign-currency invoices file normally — see Corrections and Currency & NBP.

What to do: if the correction is due, file it manually for now. Support for this case is on the way.

Buyer address missing

What it means: the invoice has an identified buyer — one carrying a tax ID (a Polish NIP, an EU VAT number, or a foreign tax ID) — but no address. Once a buyer is identified, Polish law requires their address on a full invoice (art. 106e ust. 1 pkt 3); the tax ID alone isn't enough.

Why nothing was filed: KSeF's schema would accept it, but the faktura would be legally non-compliant — so we hold it rather than silently file an invalid invoice.

What to do: open the customer in Stripe and add their billing address, so their next invoices file cleanly. This invoice keeps the address it was finalized with and a refile won't change that, so file this one manually. (A consumer / simplified invoice with no tax ID doesn't need an address and isn't held here.)

Tip: prevent this for good by having Stripe collect a billing address on every invoice — see Prepare Stripe to capture invoice data. With required address collection turned on, this hold stops happening.

Invoice lines truncated

What it means: the invoice has more line items than Stripe fits into a single webhook event. Stripe paginates the line list (10 per page) and marks the payload as incomplete. Normally we then ask Stripe for the whole list and file the invoice with every position on it — this hold means that request couldn't be made.

A brief Stripe outage doesn't get you here. A dropped connection, a rate limit or a Stripe 5xx is retried automatically, with backoff, for a few minutes — and because that read happens before we open a KSeF session, retrying it is free of any risk of filing twice. So this hold means one of two things: the retries ran out (Stripe was down longer than that), or Stripe refused the request outright — the app was uninstalled, or the restricted key was revoked or lacks the invoice read permission.

Why nothing was filed: we could file what we can see and the invoice totals would still balance, because the totals come from the invoice-level amounts rather than the lines. The result would be an invoice KSeF accepts but with line items missing. We hold it rather than silently file an incomplete document.

What to do: check in settings that the Stripe connection is still active (the app hasn't been uninstalled, the key hasn't been revoked), then refile — every attempt fetches the line list from Stripe again. If the hold keeps coming back with a healthy connection, get in touch.

Line net mismatch

What it means: the line items don't add up to the invoice net, by more than ordinary rounding would explain. The usual cause is a discount or coupon that Stripe didn't attribute to specific lines; an invoice-level adjustment does the same thing. (A shipping cost no longer lands here — we file it as its own "Koszt dostawy" position.)

Why nothing was filed: we could push the difference onto the last line and the invoice totals would still balance — but the line breakdown would be untrue (with a large discount the last line could even go negative). KSeF would accept that document, so the error would only surface in an audit. We hold rather than guess.

What to do: file this one manually. Refiling won't help: a finalized Stripe invoice can't be restructured, and the amounts come from the event Stripe already sent. For future invoices, apply discounts as ordinary Stripe Billing coupons — those are allocated per line automatically and file normally — rather than as an invoice-level adjustment.

Rejections

From here on these are rejections — cases where KSeF actively refused the invoice and returned a code. Unlike a held invoice, something here needs fixing, on your side or in the connection.

Where the fix lives

Every rejection has a fix target:

  • Stripe — correct the data on the invoice in Stripe and resubmit.
  • KSeF — a connection / token problem; reconnect. See Connecting KSeF.
  • Auto — a transient transmission- or KSeF-side issue; we retry automatically, or you just resubmit.
  • Support — contact us.

Most common codes

Code Meaning Fix
21401 Invoice failed FA(3) schema validation Stripe — check seller/buyer details (NIP, address, country)
21402 Submitted invoice size mismatch Auto — resubmit
21403 Invoice hash mismatch Auto — resubmit with fresh data
21405 Invalid invoice date Stripe — fix the issue date
21407 VAT totals don't add up Stripe — fix amounts / VAT rates
21408 Duplicate — invoice already in KSeF Support — already filed, no action
21301 Invalid NIP number Stripe — fix the buyer NIP
21304 Required NIP is missing Stripe — add the buyer NIP
21478 NIP is not an active VAT payer Stripe — verify the buyer NIP
21440 KSeF session was closed Auto — resubmit
440 Session canceled Auto — resubmit
21470 KSeF key / token is stale KSeF — generate a fresh token and reconnect
450 Authentication failed — invalid token KSeF — see below
401 / 403 / 415 / 425 / 460 Authentication / permission problem KSeF — check the connection and permissions
429 Too many requests to KSeF Auto — wait, we retry
500 / 550 KSeF server error Auto — temporary KSeF issue, we retry

A code not listed here falls through to the generic handler: the invoice waits, and we'll help resolve it.

Authentication failed (450)

This is the most common first-time blocker, and it's not an invoice problem — KSeF couldn't accept your token. Codes 450, 415, 425, 460, 401, 403, 21111 and 21115 all land here.

450 ("invalid token") almost always means one of these:

  1. The token is for the wrong environment. A token generated in the KSeF PROD/DEMO taxpayer app will always fail on TEST (and vice versa). This is the #1 cause for a first TEST filing.
  2. It's an old KSeF 1.0 token. KSeF 1.0 was retired in September 2025 — legacy tokens no longer authenticate.
  3. The token expired, was revoked, or is inactive.
  4. NIP / context mismatch — the token wasn't issued for the company NIP you're filing under.

Fix:

  1. Open the KSeF taxpayer app for the right environment — TEST: https://ap-test.ksef.mf.gov.pl, production: https://ap.ksef.mf.gov.pl. Confirm you're not in PROD/DEMO by mistake.
  2. Generate a fresh KSeF 2.0 token for the company NIP, with the invoice-sending permission.
  3. In Connecting KSeF, confirm the environment selector matches (TEST vs PROD), then paste the new token. The secret fields are write-only — leaving one blank keeps the old value, so actually paste it.
  4. Click Test connection — wait for success before resubmitting.

Codes 415 / 403 mean the token authenticated but lacks the invoice-sending permission — grant it in the taxpayer app, then reconnect. Code 460 is an XAdES certificate problem — check the certificate and private key (PEM) haven't expired and match the environment. Code 21111 is a single-use challenge that expired — just try again.

Authentication blocked (480)

KSeF blocked authentication because it suspects a security incident (code 480), or an attempt used a deceased person's authorization methods (code 470). These are rare and need a manual report to the Ministry of Finance — contact us and we'll help you raise it. The invoice waits safely.

Token expired (21470)

The KSeF token expired or was revoked. Generate a fresh token in the taxpayer app and paste it again in Connecting KSeF. The fix is the same family as Authentication failed (450).

Schema validation (21401)

The invoice structure doesn't match the required FA(3) schema — usually a missing or wrongly-formatted required field. Check the seller/buyer details (NIP, address, country) on the Stripe invoice, correct them, and resubmit.

NIP issues

Covers a missing buyer NIP (21304), an invalid NIP (21301 — wrong checksum or format), and a NIP that isn't an active VAT payer (21478 — the white list). All are fixed on the Stripe invoice: add or correct the customer's Tax ID (type pl_nip), then resubmit. For 21478, confirm the party is genuinely an active VAT payer.

Invoice data issues

The invoice date is invalid (21405) or the VAT totals don't reconcile (21407). Fix the issue date or the line-item amounts / VAT rates on the Stripe invoice and resubmit.

Duplicate invoice

An invoice with this number is already registered in KSeF (21408) or was already sent within the same session (21176). Check whether it was already filed — if so, no action is needed. If you meant to issue a correction, use a credit note (KOR). See Corrections.

Session issues

The submission session was closed (21440), cancelled or timed out (440), accepted no valid invoices (445), is in a state that doesn't allow the operation (21180), or the upload timed out (21208). These are session-level — just resubmit and we'll open a fresh session.

Transmission issues

The uploaded document's size (21402) or hash (21403) didn't match what was declared — usually a transient transmission glitch. Resubmit with fresh data pulled from Stripe.

KSeF-side issues

Rate limiting (429), a server error (500), or an operation cancelled by KSeF for an internal reason (550). These are on the authority's side, not your invoice — we retry automatically. If it persists, we'll look into it for you.

No test filing on production

If you connected a production account and expected a "test filing" or "send a sample" button, it isn't there — on purpose. On production there's no practice mode: any document you send is a real invoice (art. 108 of the VAT Act), so a "test" would be a live faktura with real legal weight. To rehearse, connect the TEST environment instead — see Connecting KSeF. On production you don't need to do anything: the first real Stripe invoice files automatically.

Unknown codes

If KSeF returns a code we haven't mapped yet, the invoice isn't lost — it waits safely and you can resubmit. We route you to us so we can explain it and, if needed, add it to this list. You never hit a dead end.