Laravel Vat Laravel Package

Product Decisions This Supports

• Build vs. buy for tax logic. This package is a useful forcing function for the question every VAT-exposed product eventually faces: do we own rate tables, VAT-number validation, and reverse-charge logic in-house, or do we lean on a library or a paid tax engine? Reading its API surface is a cheap way to scope what "in-house" actually means before you commit engineering time to it.
• EU/B2B expansion sequencing. If your roadmap includes selling to EU businesses, VAT-number validation and reverse-charge handling (charging 0% against a validated VAT ID, and knowing when you legally can't) become launch blockers. This package tells you how much of that is a weekend of glue code versus a multi-sprint compliance project — which directly informs whether an EU launch is a Q2 or a Q4 item.
• Checkout and invoicing scope. It clarifies where VAT logic must sit in the product: price display and rounding at checkout, rate resolution at invoice time, and the audit trail finance needs afterward. Deciding where tax logic lives (cart service, order service, invoicing service) is an architecture decision that's much cheaper to make before the first EU invoice is issued.
• Prototype and internal-tool feasibility. For a pricing spike, a back-office VAT-ID lookup tool, or a sandbox to demo reverse charge to stakeholders, a small MIT library removes a week of yak-shaving and lets you put something concrete in front of sales/finance early.
• Vendor concentration and maintenance-ownership decisions. The package is archived, last released in 2022, and has zero dependents. That is itself a product input: it argues for treating this as a reference implementation or a fork candidate, not a foundation. The decision it most cleanly supports is "adopt the pattern, own the code" — which sets an explicit owner and a maintenance budget rather than letting a dependency quietly rot under checkout.

When to Consider This Package

Consider it when all of the following hold:

• You're on Laravel/PHP and want VAT handling that fits the framework's conventions rather than a standalone library you have to wire up yourself.
• Your need is narrow: VAT-number validation and rate resolution for a limited set of EU countries — not a full tax-determination engine with rules, thresholds, exemptions, and filing artifacts.
• You're building something low-blast-radius: internal tooling, a prototype, a pre-revenue pilot, or a back-office admin screen where an occasional stale rate is a support ticket, not a compliance incident.
• You're willing to vendor or fork it and accept ownership of the rate tables and validation fallbacks yourself.
• Your finance/accounting function already owns filing and reconciliation, so the software only needs to record the right inputs, not guarantee regulatory correctness.

Look elsewhere — or budget to build — when:

• Money is on the line in production. Archived, no releases since September 2022, and no dependents means no realistic path to a security or compatibility patch. Unmaintained code on the checkout path of a revenue-generating product is a risk you inherit permanently.
• You need current Laravel support. An unmaintained package will drift out of compatibility with new Laravel majors; the upgrade cost lands on you at the worst possible time (usually mid-migration).
• VIES availability matters. Real-time EU VAT-ID validation depends on an external service with known downtime; you need retry, caching, and a documented fallback policy. Confirm what the package does here — assume you'll be writing it.
• You have multi-jurisdiction needs. US sales tax, Canadian GST/HST, UK post-Brexit treatment, or digital-services place-of-supply rules are well outside a small VAT library's remit. At that point a commercial tax engine (Avalara, Stripe Tax, Paddle as merchant of record) is the honest comparison.
• You need audit trail, rate history, or evidence retention. Tax authorities expect you to be able to show the rate and the validation result as of the transaction date. That's a persistence and immutability design problem, not a library feature.
• You want a support contract or someone to call. MIT and archived means no vendor relationship, by definition.

Net: treat this as a timeboxed spike and a spec, not a procurement decision. Two engineer-days to evaluate against a real sample of your EU customers will tell you more than any further reading.

How to Pitch It (Stakeholders)

Executive summary. dannyvankooten/laravel-vat is a small, MIT-licensed VAT helper for Laravel — the kind of component that answers "is this a valid EU VAT number, and what rate applies?" It's free and low-risk to evaluate, but it is archived, unreleased since 2022, and has no downstream dependents. That combination makes it a good reference implementation and a poor long-term dependency.

Why it's on the table. If EU/B2B selling is on the roadmap, VAT-ID validation and reverse-charge handling are hard prerequisites. This package lets us scope that work concretely — days, not months — and gives us a working demo for sales and finance before we commit headcount. The evaluation cost is negligible and the learning is real.

What we're actually recommending. Not wholesale adoption. We propose a short, timeboxed spike to (a) confirm the library's coverage against our actual customer mix, and (b) use its API as the specification for a small internal module we own outright. The MIT license permits this; the archived status requires it. Either way, we end the spike with an explicit owner, a rate-update process, and a documented fallback for when the EU's VIES lookup service is down.

Cost and risk framing for engineering. Adopting as-is: near-zero upfront cost, deferred and unbounded maintenance cost, plus a guaranteed Laravel-upgrade surprise. Forking or reimplementing: a few days of work, permanently owned, no external dependency on the checkout path. For anything touching invoicing or money movement, the second option is the defensible one.

The question we need answered. Is EU/B2B revenue material in the next four quarters? If yes, fund the spike and pick an owner now — the cost of getting VAT wrong retroactively (credits, reissued invoices, exposure in an audit) dwarfs the cost of building it properly. If no, note the finding and revisit; do not let this package into the dependency tree in the meantime.