NIP & PESEL Validator

NIP (Numer Identyfikacji Podatkowej, Polish Tax Identification Number) is 10 digits. The first 9 identify the taxpayer; the 10th is a checksum computed as: multiply each of the first 9 digits by weights (6, 5, 7, 2, 3, 4, 5, 6, 7), sum, take modulo 11. The result is the check digit. If modulo 11 equals 10, the NIP is invalid by definition — such a combination is never issued.

NIP carries no information about region or industry (since the 2009 reform — prior to that, the first 3 digits indicated the tax office). In 2026 the first 3 digits are assigned sequentially without semantic meaning. The official format is 123-456-78-90 or 1234567890 — separators are cosmetic only.

• Digits 1-2 (YY) — last two digits of the year of birth.
• Digits 3-4 (MM) — month of birth with century offset: 01-12 → 20th century (1900-1999); 21-32 → 21st century (2000-2099); 41-52 → 22nd century (2100-2199); 61-72 → 19th century (1800-1899); 81-92 → 22nd century alternate. Historical accident, not elegant design.
• Digits 5-6 (DD) — day of month (01-31).
• Digits 7-10 (SSSS) — sequential birth number for that day. The 10th digit encodes sex: even = female, odd = male.
• Digit 11 (K) — checksum. Multiply digits 1-10 by weights 1,3,7,9,1,3,7,9,1,3, sum, take modulo 10, subtract from 10. That is the check digit. Exception: if the result is 10, the check digit is 0.

• Checks — that the NIP/PESEL has a valid checksum and structure. That the date of birth in PESEL is plausible (no Feb 32).
• Checks — sex and age extracted from PESEL match user expectations (e.g., someone claiming to be 25 did not paste a PESEL from 1953).
• Does NOT check — whether the NIP exists in the CEIDG/KRS registry. That requires a query to the Polish White List of VAT taxpayers API (https://wl-api.mf.gov.pl/) or GUS REGON.
• Does NOT check — whether the PESEL belongs to a specific person. This verification cannot be done — PESEL is confidential and knowing the number alone does not identify or authorize a person.
• Does NOT detect — PESELs with wrong century encoding (a 90-year-old whose PESEL month digits 21 suggest the year 2090). The number is formally valid; semantically suspicious.

• You are importing a large batch of customer data and want to filter typos in NIP/PESEL before sending to the accounting system.
• You are writing a registration form and need a reference implementation for the client-side validator (before the request goes to the API).
• You are checking whether an invoice from a counterparty was issued under a valid NIP — before deducting VAT (this is checksum only; White List verification is a separate step).
• You are generating test data and want to understand how a PESEL structure encodes the date of birth.

• It will not connect to the state registry to verify "does this NIP/PESEL exist". That requires authenticated queries to government APIs (White List of VAT taxpayers, BIR REGON).
• It will not validate other documents (REGON, KRS, ID card number). REGON has its own checksum; KRS is just a number with no checksum; an ID card number (3 letters + 6 digits) has its own algorithm — all outside the scope of this specific validator.
• It does not consider historical context (NIPs issued before 2009 vs after). Checksum validation is independent of issue date.