Legal Entity Laravel Package

Product Decisions This Supports

• B2B vs. B2C modelling. Most product surfaces (billing, invoicing, onboarding, KYC, support, CRM sync) need to know whether a customer is an individual or an organization and which attributes are legally meaningful. A dedicated LegalEntity value object turns that from an implicit, duplicated convention into an explicit domain concept.
• Canonical customer/supplier record shape. If invoicing, contracts, and tax reporting each carry their own ad-hoc "company" fields today, this package is a candidate for the single definition those features converge on — reducing the class of bugs where a company name is formatted one way on an invoice and another in the admin UI.
• Roadmap enablers. E-invoicing mandates (EU ViDA/Peppol), VAT/tax-ID collection at checkout, self-serve account upgrades from individual to business, procurement/AP automation, and marketplace seller onboarding all depend on clean legal-entity data. Adopting a small, explicit model early lowers the cost of those roadmap items.
• Build vs. buy. The "buy" side is effectively free (MIT, Composer-installable, single-purpose). The real decision is not licensing cost but whether a ~zero-adoption package should become a dependency in a revenue-adjacent path. Treat it as adopt-with-a-wrapper, not adopt-as-is.
• Use cases it fits: representing bill-to/ship-to parties, distinguishing sole traders from companies, carrying registration/tax identifiers alongside a display name, and normalizing entity data before persisting or transmitting it.
• Use cases it does not decide: tax-ID validation, address normalization, sanctions/PEP screening, invoicing formats. Those stay separate product/vendor decisions.

When to Consider This Package

Consider it when:

• You need a small, well-named value object for "the party we invoice/contract with" and want to avoid inventing one per team.
• Your stack is PHP/Laravel and you already lean on Composer packages for domain primitives; MIT licensing removes legal friction.
• You are willing to vendor or fork it. With 0 stars and 0 dependents, you should assume you own the maintenance. Read the source first — it is small enough to audit in an afternoon.
• The alternative is worse: divergent columns (company_name, business_name, org) across three services.

Look elsewhere (or write ~50 lines yourself) when:

• You need validation or jurisdiction rules (EU VAT formats, UK Companies House, US EIN). This package is a data shape, not a compliance engine; pair it with a real validator or a vendor.
• You need addresses, contacts, or roles (buyer/seller/payer) as first-class concepts — that is a broader party model, not a single value object.
• Bus-factor and support matter more than ergonomics. Zero dependents means no community to catch regressions on PHP/Laravel upgrades; budget for pinning the version and covering it with your own tests.
• Your team is not PHP, or you would be pulling it in for one field.

Adoption criteria I would apply: audited source, immutable value semantics, no unexpected framework coupling, a test suite you can run, and a wrapper interface in your own namespace so the dependency is swappable in a sprint rather than a migration.

How to Pitch It (Stakeholders)

To executives: This is a tiny, MIT-licensed PHP library that gives us one shared definition of "the legal party" — the company or individual we bill, contract with, and report on. It is free and low-risk to trial, and it makes future compliance work (EU e-invoicing, VAT collection, business account onboarding) cheaper because the data shape is already right. The honest caveat: it has no adoption and no maintainer community, so we should treat it as a starting reference we own, not a supported vendor product. Cost is a day of engineering review; the payoff is avoiding three teams inventing three versions of "company."

To engineering: Small value-object package for legal entities. Low blast radius, trivial to vendor or fork, MIT. Recommended pattern: depend on our own LegalEntity interface and adapt this package behind it, with contract tests and a pinned version. Do not let it leak into domain code directly, and do not expect it to validate tax IDs — that stays with a dedicated validator.

Recommendation: Trial behind an internal abstraction in one bounded context (billing or onboarding). Re-evaluate in a quarter on two signals: did it actually eliminate duplicated entity modelling, and did we have to patch it for framework or PHP upgrades? If either answer is unhelpful, replace it with our own value object — the migration cost is small precisely because the abstraction is ours.