Filament Vat Id Laravel Package

Product Decisions This Supports

• Build vs. buy for tax-ID capture. The in-house alternative is a regex per country, checksum algorithms for EU VAT / PL NIP / PL REGON / CZ IČO / CZ DIČ / UA ЄДРПОУ / UA РНОКПП, four registry integrations (VIES, ARES, Polish white list, GUS), and ten locales of error copy. That is weeks of engineering plus ongoing maintenance of rules that change. An MIT-licensed field reduces this to a Composer require and one schema line — a clear buy signal if the maturity risk is acceptable.
• B2B onboarding and self-serve registration. The core product decision this unblocks is whether to require a validated VAT ID at signup, at first invoice, or in back-office cleanup. A drop-in field with inline error messaging lowers the friction cost of "require it early," which in turn improves invoice accuracy and reverse-charge VAT handling downstream.
• Market expansion sequencing. The package's coverage maps directly to a market roadmap: EU-wide, Poland, Czechia, Ukraine. If the roadmap includes any of these, this becomes a cheap enabler for a localized checkout/registration flow, including the 10-language message surface — a real line item if localization is on the near-term plan.
• Compliance defensibility. VIES/ARES/white-list lookups produce a point-in-time validation event. That is a meaningful input to a decision about how much evidence to retain for cross-border VAT treatment — as long as the team decides where the validated result and timestamp get persisted, since the package is an input concern, not a data model.
• Validation UX prioritization. Offline checksum rules (instant, no network) vs. registry lookups (slow, can fail) is a product tradeoff, not just a technical one. This package lets you ship the offline tier immediately and treat lookups as an optional enhancement — useful when scoping an MVP vs. a "verified supplier" tier.
• Scope discipline on forms. Because it is a Filament field rather than a general validation library, the decision it informs is narrow and concrete: "do our panel forms collect tax IDs, and do we want that standardized across resources?" It is not a candidate for API-side or headless validation.

When to Consider This Package

Consider it when:

• The application is Laravel + Filament 5. Filament version is the hard gate — verify the constraint in composer.json before anything else; if you run Filament 3, this is an upgrade project, not a drop-in.
• You collect B2B tax identifiers in admin panels, onboarding wizards, or vendor/seller back-offices, and you want consistent validation and error copy across those forms.
• Your served countries fall inside EU / PL / CZ / UA. Coverage outside that set is not implied.
• You want offline format + checksum validation as the baseline, with registry lookup as an optional extra rather than a hard dependency on an external service at submit time.
• You are comfortable with MIT + small code surface: the field is small enough to read, fork, or vendor if the maintainer disappears, and there are no migrations, queues, or persistence concerns to unwind.

Look elsewhere when:

• You need tax-ID validation outside Filament — in an API, a queue job, a checkout flow, or a data-import pipeline. You want a validation library (or your own rules), not a form component.
• You only operate in one jurisdiction with a simple format. A hand-written rule is a smaller dependency than a package, however small the package is.
• You need vendor support, an SLA, or contractual indemnity. This is a single-maintainer, low-adoption project (1 star); there is no commercial backstop, and you should not pitch it as if there is.
• Registry lookups are on the critical save path at volume. Remote validation bounds your submission throughput and inherits the availability of VIES/ARES/GUS. If high-volume verified onboarding is the requirement, budget for caching, timeouts, and an offline-only fallback before committing.
• You need persisted normalization and an audit trail of validation results. That is application work regardless; if it is the dominant requirement, evaluate a dedicated VAT-validation library plus your own storage model instead.

Regardless of choice, gate adoption on: reading the source (it is small), pinning the version, confirming supported Filament/PHP majors, and confirming message output in each target locale — the v1.0.2 fix was specifically an English acronym-casing issue, so other locales deserve a check.

How to Pitch It (Stakeholders)

To executives: We need to collect and validate business tax IDs for B2B customers in the EU, Poland, Czechia, and Ukraine. Building that in-house means checksum rules for four jurisdictions, four government registry integrations, and translated error messages — weeks of work plus permanent maintenance of rules we don't own. This package is MIT-licensed, does all of that as a single form field, and costs us essentially nothing to try. The tradeoff is maturity: it is a small, single-maintainer project with minimal adoption, so I recommend a time-boxed pilot on one low-risk form rather than a company-wide mandate, with a fallback plan that costs us little because the code is small and forkable. Upside is faster, more accurate invoicing and a cheaper path into those markets; downside is bounded to one form and a few days of engineering.

To engineering: It's a Filament 5 form field — TaxIdInput::make('vat_id') — wrapping offline format/checksum rules plus optional VIES/ARES/Polish white list/GUS lookups, with 10 locales and ->validationAttribute() as the escape hatch for exact copy. Ask: confirm Filament 5 and PHP constraints, read the source (small), keep normalization (strip spaces, upper-case, country prefix) in our layer before persistence, and add a regression test on the validation message since message casing depends on Filament's label transformation. For lookups, wrap with a timeout and fall back to offline-only so a registry outage doesn't block saves. Patch-level release, no API changes, no migrations — low integration risk; the real risks are the Filament-major coupling and registry availability.