Laravel Vat Eu Validator Laravel Package

Product Decisions This Supports

• Build vs. buy for EU VAT validation: Validating VAT numbers against VIES is a deceptively fiddly integration — two transports (SOAP and REST), country-specific formats, and a service that fails in many distinct ways (member-state outages, "invalid" vs. "not found" vs. "unavailable", throttling). This package collapses that into a facade plus three validation rules, so the roadmap decision becomes "adopt a thin wrapper" rather than "dedicate a sprint to a tax-authority integration nobody wants to own."
• Where VAT checks belong in the funnel: Because validation is available as a Laravel validation rule, product can choose where to enforce it — at checkout/B2B signup (block the request), at onboarding (soft-flag and allow manual review), or in a nightly reconciliation job (audit already-stored numbers). The rule-based API makes the enforcement point a product config decision, not an engineering one.
• B2B / reverse-charge eligibility: EU VAT validation underpins whether you charge VAT at all (reverse charge for intra-EU B2B). Accurate validation has direct revenue and compliance consequences — a false "valid" is a tax liability, a false "invalid" is a blocked sale. Surface VIES outages as "defer/retry" rather than "reject," and treat that distinction as a product requirement.
• Scope check on tax/ERP integrations: If your roadmap has an Avalara/TaxJar/Stripe Tax integration, this package covers number validation only, not rate calculation, invoicing, or filing. Use it to decide whether a full tax engine is genuinely needed or whether validation-plus-a-rate-table is sufficient for your markets.
• AI-assisted development as a delivery accelerator: v3.5.0 adds Laravel Boost guidelines covering the rules, facade, SOAP/REST configuration, and VIES failure modes. That means AI tooling in your engineers' editors gets correct, current usage guidance for this package out of the box — a modest but real reduction in onboarding cost and misuse (e.g. silently swallowing VIES unavailability in an AI-generated snippet).
• Dependency hygiene as a roadmap signal: The guidelines ship with a CI drift test that fails when documented class names, config keys, env vars, rule names, translation keys, or publish tags no longer exist in code. That is a maintenance-quality signal — the maintainer is investing in keeping docs honest rather than shipping surface area.

When to Consider This Package

Good fit when:

• You are Laravel/PHP and need to validate EU VAT numbers against VIES inside standard validation flows (Validator::make, Form Requests) with minimal ceremony.
• You want both SOAP and REST transports configurable, so you can fall back or match your environment's egress/SOAP constraints.
• You need failures to be distinguishable — invalid number vs. service unavailable vs. member-state error — because your product treats those differently (block, retry, queue for manual review).
• You want a small, single-purpose dependency rather than a full tax platform.
• You use (or are evaluating) Laravel Boost and want AI tooling to produce correct usage guidance without hand-written conventions docs.

Look elsewhere when:

• You need VAT rate calculation, invoice generation, EU OSS/IOSS reporting, or filing — this validates numbers only.
• You are not on Laravel, or you need a language-agnostic integration layer (consider a standalone VIES client or a managed tax API).
• You require an SLA, support contract, or vendor accountability for VIES availability — this is a community package wrapping a government service with its own uptime characteristics.
• You need UK/HMRC, Swiss, Norwegian, or non-EU VAT checks — VIES is EU-scoped.
• Your volume profile requires heavy caching, batching, or rate-limit coordination with VIES and you'd rather own that layer — check whether caching is configurable before adopting.
• Introducing AI-assistant guidelines into your repo is a governance concern (some orgs restrict what tool-discovery files land in the codebase). Note Boost is only suggested, never required — v3.5.0 adds no runtime dependency.

On this release specifically: v3.5.0 changes no runtime code. It requires no migration, no re-evaluation of a prior adoption decision, and no regression testing beyond confirming nothing in your build pipeline reacts to the new resources/boost/ files. If you are already using the package, this is a no-op upgrade unless you want the Boost guidelines. If you are evaluating it, the release strengthens the maintenance-quality argument slightly — treat it as a tiebreaker, not a reason to adopt.

How to Pitch It (Stakeholders)

To executives: This is a small, free, single-purpose dependency that handles EU VAT number validation against VIES — the check that determines whether we can apply reverse charge on intra-EU B2B sales. Adopting it replaces a bespoke integration to a government service that is known to be unreliable, and it lets us choose per-surface whether a failed check blocks a sale or queues for review. It does not replace a tax engine: no rate calculation, no invoicing, no filing. Scope it as compliance plumbing, not as tax automation. The latest release (v3.5.0) is documentation and CI tooling only, with no runtime change and no new required dependency.

To engineering: Laravel package, facade plus three validation rules, configurable SOAP and REST clients for VIES. The important design point is that VIES failure modes are surfaced distinctly — do not collapse "unavailable" into "invalid." v3.5.0 adds Laravel Boost guidelines under resources/boost/guidelines/core.blade.php, picked up via php artisan boost:install or boost:update --discover, with laravel/boost as a suggest-only dependency. It also adds a CI drift test that validates every class, method, config key, env var, rule name, translation key, and publish tag referenced in those guidelines against the actual code, so renames can't silently stale the docs. Zero runtime changes in this release; upgrade is a plain composer update with no code changes expected. Open questions worth resolving before rollout: caching strategy and TTL for validation results, timeout/retry policy against VIES, and whether unavailable-VIES responses are queued or surfaced to the user.