Identity Number Bundle Laravel Package

Product Decisions This Supports

• Market-entry gating for Sweden (SE): Whether to ship a self-serve signup flow for Swedish users, or require manual/ops-assisted onboarding. Format validation of personnummer (identity numbers) and samordningsnummer (coordination numbers) is a hard prerequisite for any automated Swedish funnel — without it, you are either accepting garbage or blocking real users.
• B2B onboarding and invoicing correctness: Organisationsnummer is the Swedish equivalent of a VAT/tax identifier. Validating it at point of capture prevents failed invoice runs, dunning cycles, and manual AR cleanup — a measurable cost line, not a feature nice-to-have.
• Whether to treat coordination numbers as first-class: Samordningsnummer are issued to people resident in Sweden for under a year, and to foreign workers and students. A validator that silently rejects them blocks a real, growing user segment. This is an activation-rate and inclusivity decision, not a technical detail — and it is exactly the kind of edge case this package's test suite is valuable for surfacing.
• Build vs. buy on checksum logic: Luhn/mod-10 plus date-validity, coordination-day offset, separator handling, and organization-number prefix rules is ~100 lines of well-specified but easy-to-get-subtly-wrong code. Adopting or vendoring an existing implementation is the rational default over owning it from scratch.
• Risk posture: validation vs. verification: This package confirms a number is structurally plausible. It does not confirm the person or company exists. That distinction determines whether you still need BankID, Skatteverket, or Navet, and whether fraud or trust-and-safety controls can rely on this check alone (they cannot). This is a scoping decision the PM owns.
• Data hygiene and account deduplication: Normalizing at capture (whitespace, +/- separators, 10- vs 12-digit forms, century handling) reduces duplicate-person accounts and downstream CRM/analytics cleanup.
• Where to apply it first: Back-office and admin paths (KYC review queues, invoice entry, bulk imports) are the low-risk, high-payoff entry point before customer-facing onboarding.

When to Consider This Package

Adopt / pilot when:

• Your product has a Swedish user or customer base and you currently accept personnummer or organisationsnummer as free text or with regex-only checks.
• Your stack is Symfony. This is a Symfony bundle, not a Laravel package — the DI wiring, Form types, and Validator constraints do not auto-configure in Laravel. In Laravel you consume the underlying jongotlin/identity-number library and write your own ValidationRule. Plan for an adapter, not a drop-in.
• Validation is low-volume and mostly administrative (back-office forms, KYC review queues, invoice entry) rather than a hot request path — though the logic is microseconds of CPU and trivial to run at scale once wrapped.
• You want MIT-licensed, dependency-light code small enough to read in one sitting and vendor without reservation.
• You want the edge-case test fixtures more than the code — the value is captured knowledge of Swedish number formats and their failure modes.

Look elsewhere when:

• You need Laravel-native ergonomics: there is no service provider, facade, or Rule object; you will write glue code regardless, at which point comparing against a maintained alternative is cheap.
• Maintenance risk matters. Zero stars, zero dependents, a single maintainer, and a description that conflates Swedish and South African ID handling in the same briefing are all trust signals. Treat this as "readable reference implementation," not a dependency with a support contract. Budget to fork it into your own codebase.
• You need verification rather than validation: existence checks against Skatteverket/Navet, name matching, or BankID. This package does none of that and must not be scoped as if it might.
• You need broader coverage (Finnish HETU, Norwegian fødselsnummer, Danish CPR) or a unified EU tax-ID story — you would be assembling multiple one-off packages.
• Your compliance surface requires an audited, versioned vendor. An unmaintained bundle will not survive vendor-risk review.

Recommendation: Vendor the logic in-house behind your own IdentityNumberValidator interface, using this package as the reference implementation and its fixtures as acceptance tests. That captures the domain value while removing a zero-star dependency from your supply chain. Record the decision as an ADR.

How to Pitch It (Stakeholders)

To executives (30 seconds): Sweden requires us to check two things at signup — personal identity numbers and company registration numbers. The rules are fiddly but well-specified, and there is an MIT-licensed implementation we can adopt at essentially zero cost, including the easy-to-miss case of coordination numbers for new arrivals and foreign workers. The catch is that it is a tiny, unmaintained, Symfony-specific project — not a Laravel package — so the right move is to absorb the ~100 lines of logic and its tests into our own codebase rather than depend on it. One sprint-week of engineering, no licensing cost, and it materially reduces failed invoices and blocked signups. It is explicitly not identity verification — if the roadmap requires proving who someone is, that is a separate BankID/vendor decision and budget.

To engineering: Symfony bundle, not a Laravel package — no service provider, no Rule class, expect an adapter. Take the jongotlin/identity-number library directly, wrap it in a Laravel ValidationRule and optionally a value-object Cast so validated numbers cannot re-enter the domain unvalidated. The domain logic (Luhn checksum, date validity, coordination-day offset, organization-number prefixes, 10/12-digit and separator normalization) is short and sound; the package's real value is its edge-case fixtures. Recommend vendoring with MIT attribution, wrapping behind an internal interface, pinning versions, and never placing it on a hot path or treating it as a maintained dependency.

Risk register note: Zero stars, zero dependents, single maintainer: abandonment risk is effectively certain. Mitigate by forking, not requiring. Highest-severity failure mode is false rejection of a legitimate Swedish identity at signup — mitigate with a curated fixture corpus sourced from Skatteverket's published test ranges plus a manual-override path in support tooling. Document the validation-vs-verification boundary explicitly; compliance, support, and sales will all test it.