Swedish Entity Laravel Package

Product Decisions This Supports

• Swedish market entry and localization roadmap — decides whether we can ship native Swedish onboarding flows without building identity-format logic from scratch.
• Onboarding/KYC-lite feature — validating personnummer at form-submit time catches typos and fake inputs before they reach bank-ID or manual review, reducing failed verifications and support tickets.
• Age gating and regulated-product access — extracting date of birth and computing age from a validated number supports alcohol, gambling, healthcare, and financial-product eligibility checks.
• B2B onboarding and invoicing — organisationsnummer validation for supplier records, marketplace seller verification, invoice recipient data, and CRM deduplication.
• Build vs. buy — a small, focused MIT dependency versus an in-house Luhn checksum + date-parsing + century-handling + coordination-number edge-case implementation that someone must own forever.
• PII handling strategy — the format/extract APIs make it easy to normalize and mask identifiers before logging or analytics, which feeds directly into GDPR data-minimization decisions.
• Data quality and normalization — standardizing user-entered formats (YYYYMMDD-XXXX vs YYYYMMDDXXXX) at the boundary rather than downstream in reports and integrations.

When to Consider This Package

Consider it when:

• Swedish individuals or organisations are in scope and the stack is Laravel/PHP.
• The need is format validation, normalization, and field extraction — not authoritative identity verification.
• You want a single-purpose dependency rather than pulling in a broader validation or identity suite.
• Your team is comfortable wrapping third-party code in a thin internal adapter (recommended here given the small maintainer footprint).
• Licensing matters and MIT is acceptable.

Look elsewhere when:

• You need multi-country identity handling — this is Sweden-only by design; adopting it locks in a Sweden-specific path.
• You need real KYC/AML or e-ID (BankID, Freja, document checks) — that is a vendor integration, not a checksum library.
• You need authoritative registry data for organisationsnummer (e.g., Bolagsverket lookups, company status, address) — validation only proves the number is well-formed, not that the entity exists.
• Procurement or compliance requires vendor support, SLAs, security attestations, or a maintained LTS commitment.
• You are outside PHP/Laravel.

Risk note to carry into the decision: low star count and apparent single-maintainer bus factor. Mitigate with an internal adapter interface, a pinned version, and a fork-ready posture — the code surface is small enough that this is cheap insurance.

How to Pitch It (Stakeholders)

To executives: This is a free, permissively licensed library that handles Swedish social-security and organisation-number validation — the fiddly checksum and formatting rules we would otherwise hand-build and maintain. It shortens time-to-market for Swedish onboarding, cuts form errors and downstream verification failures, and carries negligible cost. Risk is low because the scope is narrow and it can be swapped out behind our own interface if needed.

To engineering: A focused, single-responsibility package covering validation, formatting, and extraction for personnummer and organisationsnummer, including the edge cases teams usually get wrong. Recommended integration pattern is a thin domain wrapper — SwedishIdentityValidator or similar — so business logic never depends on the package directly. That gives us testability, a clean swap path, and a place to layer policy (masking, logging rules, age thresholds) on top.

To compliance/security: Adopting it does not change our data-handling obligations. It validates format only and performs no external calls; any extracted PII should still flow through existing retention and masking controls.