KSEF-001:KSeF NIP validation failed — bad format or wrong identifier field
Fix: Strip any country prefix, spaces and separators so the NIP is 10 bare digits, then verify the check digit before submission. Make sure a Polish counterparty's NIP lives in DaneIdentyfikacyjne/NIP — reserve NrVatUE for the EU VAT identifiers of foreign trading partners. Invoice Navigator removes a PL prefix and formatting characters and re-runs the checksum deterministically; a number that still fails the check digit, or an empty NIP field, is surfaced to the caller because the correct value cannot be guessed from the document. Provide the required value in the free validator.
KSEF-001 fires when a Polish tax identification number (NIP) on a KSeF e-invoice is malformed or placed in the wrong identifier element. A NIP must be exactly 10 digits and pass the official weighted check-digit test; the KSeF schema field that carries it (Podmiot1/Podmiot2 → DaneIdentyfikacyjne → NIP) accepts digits only — no PL prefix, no spaces, no dashes. A second, very common variant is putting a domestic NIP in the EU VAT field (NrVatUE) or a generic identifier (NrID) instead of the NIP element, which both fails validation and breaks routing of the invoice to the correct party inside KSeF.
Engine Classification
Business data required · Explicit input workflow · No assumptions made
Required input: Polish NIP (Tax ID)
What is KSEF-001?
KSEF-001 is a fatal validation rule defined in the KSeF specification (POL national rules). It validates the NIP empty. KSeF uses the NIP in Podmiot2 to deliver the invoice, so a misplaced number can fail validation or misdeliver. element in the UBL invoice XML.
When this rule fires, the invoice is rejected by Peppol access points and never reaches the buyer.
Target path: Three patterns cause almost every KSEF-001. (1) Formatting: the NIP is exported with a country prefix (PL1234567890) or separators (123-456-78-90); the NIP element is digits-only so the prefix and punctuation are rejected. (2) Check digit: a transposed or mistyped digit makes the number fail the weighted checksum (weights 6,5,7,2,3,4,5,6,7 mod 11). (3) Wrong field: a Polish buyer's NIP is written to NrVatUE or NrID, leaving DaneIdentyfikacyjne/NIP empty. KSeF uses the NIP in Podmiot2 to deliver the invoice, so a misplaced number can fail validation or misdeliver.
Why This Error Matters
The NIP in Podmiot2 is how KSeF routes the invoice to the buyer. A malformed or misplaced NIP both fails validation and can misdeliver the document inside the platform.
KSEF-001 is a hard failure — the invoice must be corrected and re-sent before it can reach the recipient.
Validator Behavior
- ·Causes invoice rejection
- ·Error returned: KSEF-001
- ·Specification: KSeF
How to Fix It
Before / After
<Podmiot2>
<DaneIdentyfikacyjne>
<NrVatUE>PL123-456-78-90</NrVatUE>
</DaneIdentyfikacyjne>
</Podmiot2><Podmiot2>
<DaneIdentyfikacyjne>
<NIP>1234567890</NIP>
</DaneIdentyfikacyjne>
</Podmiot2>Technical Reference
Three patterns cause almost every KSEF-001. (1) Formatting: the NIP is exported with a country prefix (PL1234567890) or separators (123-456-78-90); the NIP element is digits-only so the prefix and punctuation are rejected. (2) Check digit: a transposed or mistyped digit makes the number fail the weighted checksum (weights 6,5,7,2,3,4,5,6,7 mod 11). (3) Wrong field: a Polish buyer's NIP is written to NrVatUE or NrID, leaving DaneIdentyfikacyjne/NIP empty. KSeF uses the NIP in Podmiot2 to deliver the invoice, so a misplaced number can fail validation or misdeliver.Code Example
A Polish buyer's identifier belongs in DaneIdentyfikacyjne/NIP as 10 bare digits. The PL prefix and dashes are removed, and the value is moved out of NrVatUE (for foreign EU VAT IDs) into the NIP element KSeF uses for delivery.Common Causes
- ·Formatting (PL prefix or separators), a failed check digit, or the NIP placed in NrVatUE/NrID instead of DaneIdentyfikacyjne/NIP.
Seeing this in production? The API handles KSEF-001 automatically. See the fix response →
Frequently Asked Questions
Either the NIP is not 10 plain digits (it carries a PL prefix, spaces or dashes), it fails the weighted check-digit test, or it was placed in NrVatUE/NrID instead of DaneIdentyfikacyjne/NIP.
No. The NIP element is digits-only. Use 1234567890, not PL1234567890. The PL prefix only belongs on EU VAT identifiers in NrVatUE for foreign counterparties.
The first nine digits are multiplied by the weights 6, 5, 7, 2, 3, 4, 5, 6, 7, summed, and taken modulo 11; the result must equal the tenth digit. A modulo result of 10 means the number is invalid.
In NrVatUE (with its country prefix) for EU counterparties — not in the NIP element, which is reserved for Polish tax numbers.
The formatting cases yes — it strips the PL prefix and separators and re-validates the checksum (confidence ~0.65). A genuine check-digit failure or a missing NIP is flagged for input.
Related Errors
Related Content
Last updated: 16 June 2026
Validate your invoice
Drop your XML here to check for KSEF-001
Fix KSEF-001 with guided input
Upload your invoice and we'll ask for the missing data, then apply a safe, auditable fix.