CHECK-KSEF-NUMBER-MALFORMED
InvoiceIn checks · validation rule
InvoiceIn checksWarning
The KSeF number supplied with this invoice does not have the shape KSeF issues. An invoice number reads NNNNNNNNNN-RRRRMMDD-FFFFFFFFFFFF-FF and a collective identifier NNNNNNNNNN-IZRRRRMM-FFFFFFFFFFFF-FF: exactly 35 characters in both — the issuing party's 10-digit NIP, the acceptance date (or IZ plus year and month), 12 hexadecimal characters, and a two-character checksum, joined by hyphens. The usual causes are a truncated copy, hyphens lost in a spreadsheet, and the seller's own invoice number (P_2, BT-1) passed by mistake. The mask, the NIP check digit and the date are checked here; the trailing checksum is computed by the tax administration with an algorithm it does not publish, so the number is carried and shape-checked, never recomputed — only KSeF itself can confirm that a number exists.
- Field
payment.ksef_number (PL national, not an EN 16931 term)- Rule set
- InvoiceIn checks
- Who has to fix it
- The receiver
This one is on the receiving side: the document itself is fine, but something the payment run needs is missing or does not match — it is fixed in your own integration, not by the supplier.
Check your own invoice
Drop the file that failed. We parse it, run the official rule sets against it and list every finding with a fix — 20 invoices per day, no key, nothing stored.
Open the live demoSame explanation over the API: GET /v1/rules/CHECK-KSEF-NUMBER-MALFORMED?lang=en