How to generate test NIP values for form validation

Disconnect tests from real services

Use a separate test application disconnected from invoicing, payments, real account registration and government services. Calling an environment “test” is insufficient if submissions or integrations still reach production. Check configuration before generating a batch.

Do not copy NIPs from customer databases, invoices or logs. The generator does not confirm that values are unassigned and does not use a reserved pool. Do not look generated values up in real services merely to see whether they “work”.

Choose a batch size and test objective

Confirm isolated-test use, select 1–20 values and choose the checksum mode. The default unconfirmed selection prevents generation. Passing mode supports a positive technical test; intentionally failing mode targets rejection by the last-digit check.

Both modes retain the generator’s length and format. Failing mode changes only the final digit, so it does not replace tests for blank entries, letters, a PL prefix, short strings or rejected format. Create separate cases with an explicit expected message.

Understand what the generator guarantees

Positive values pass the local format and checksum used by the validator. The generator skips bodies with remainder 10. Negative mode changes the check digit by 1 modulo 10 without changing other fields.

Values differ within a batch, but separate batches can repeat. An in-memory random seed is created in the browser on submission; it is not an interface field. This is neither a global uniqueness service, a secret-token generator nor an official identifier issuer.

Source: Ministry of Finance / CIRFMF — KSeF SDK NIP checksum (code reviewed 30 September 2026); Ministry of Finance / CIRFMF — KSeF SDK NIP format (code reviewed 30 September 2026).

Illustrative positive and negative cases

Test body 101000000 has weighted sum 13 and remainder 2. Therefore 1010000002 passes the local check, while 1010000003 has an intentionally wrong final digit. The table is a fixed illustration; your next generator submission need not return these values.

In an automated test, keep the objective alongside each string and assert the validation message, not merely successful submission. If a positive case is rejected, compare your application’s rules with this generator’s scope. Every example can coincide with an issued identifier.

Copying, reset and reusing a batch

Choose “Copy” deliberately. Copied output includes the test-data label, mode, warning and one value per line. If your test requires digit-only entries, extract them into an isolated fixture and retain their intended-use information alongside the cases.

The form does not store the batch in the URL, analytics or persistent storage. “Clear” removes the result and resets confirmation; reload does not restore a batch. For repeatable tests, retain your own labelled fixture rather than expecting the next submission to return the same values.

Separate form testing from business verification

Passing a checksum test does not check a business, NIP issuance, VAT status or an account. Official counterparty checking is a separate process. The MF and KAS sources explain identifier checks and the VAT register; they do not approve our test fixtures for real transactions.

A useful suite covers success, last-digit failure, format and required-entry behaviour. Testing an official integration requires the conditions and fixtures supplied by its test-environment operator. Do not treat a passing local-generator value as that permission or as an approved integration fixture.

Source: Ministry of Finance — structural identifier checks, not issuance verification; Polish tax administration — using the VAT register (a separate check).

Frequently asked questions

Tools covered by this guide