Laravel Verifactu Laravel Package

Product Decisions This Supports

Compliance roadmap for Spanish invoicing. VeriFactu (Reglamento RD 1007/2023, the successor regime to the SII/"Ley Antifraude" framework) is a mandatory obligation for Spanish businesses and for any vendor selling invoicing software into Spain, with phased deadlines landing across 2026–2027. This package is a compliance dependency, not a feature — the decision it really supports is "how do we reach VeriFactu conformance without derailing the roadmap?"

• Build vs. buy (vs. wrap). Offers a fourth option: don't build record generation, hashing/chaining, QR payloads and AEAT submission plumbing from scratch; wrap a Laravel-native package and put engineering effort into product surface instead.
• Time-to-market for a Spain launch. If we are localizing an existing billing/ERP/vertical SaaS product for Spain, this is a candidate accelerator for the compliance layer, letting us ship a "VeriFactu-ready" claim earlier in the sales cycle.
• Feature scoping. Helps decide whether to ship (a) invoice-record compliance only, or (b) a full compliance product including certificate management, submission retries, rejection handling, and audit logs. The package likely covers the low-level plumbing; the operational wrapper is still our build.
• Multi-tenant / multi-deployment readiness (v1.0.2). The new release makes IdSistemaInformatico — the identifier of the producing software system, which VeriFactu records must carry — configurable rather than fixed. That is a prerequisite for the two deployment shapes we actually sell: one codebase serving many tenants/environments, and separate staging vs. AEAT test instances. Previously this was a likely blocker for a SaaS-shaped offering; now it is a configuration concern.
• Sandbox/acceptance testing. The stated intent ("support multiple test instances") means we can point the same build at AEAT's test environment per instance. That materially de-risks the spike below: we can validate record generation and submission against a test harness without a bespoke fork.
• Architecture fit. Explicit Laravel 10–12.x support means it slots into a modern Laravel monolith or modular monolith without a service rewrite — a meaningful constraint on our target stack and hosting decisions.
• Vendor/dependency posture. MIT license and 0 dependents mean low legal friction and low blast radius. v1.0.2 shows active maintenance and, for the first time, two external contributors landing PRs — a modest positive signal on ecosystem health, though 23 stars and a single-package surface still mean low validation overall. Treat it as a tactical dependency behind an internal adapter interface, not a strategic one.
• Opportunity signal. The high opportunity score (7.95) against a modest overall score (6.95) reads as "real, growing demand, immature supply" — exactly the profile where an internal abstraction layer plus a thin third-party dependency is the right bet, and where a build-vs-buy review is worth scheduling now rather than at deadline pressure.

When to Consider This Package

Consider it when all of these hold:

• We sell into Spain (or have Spanish-resident customers/autónomos) and must produce VeriFactu-compliant invoice records.
• Our stack is Laravel 10, 11, or 12 and we are comfortable with a package-level dependency rather than a standalone compliance service.
• We need the producer-side plumbing (record generation/registration, chaining, QR/record data) and are prepared to own the surrounding operations: certificates, retries, AEAT responses, corrections/cancellations, and archival.
• We need multiple instances or environments — multi-tenant, per-deployment, or staging vs. AEAT test — which v1.0.2's configurable IdSistemaInformatico now supports. (Confirm per-tenant vs. per-deployment semantics with the maintainer before designing around it; a globally configurable value may still not be a true per-tenant setting.)
• We have legal/fiscal review capacity — a package can implement a spec; it cannot certify that our invoice flow, numbering and retention policy is compliant.
• We can isolate it behind an internal interface so it is replaceable if the maintainer stalls or the regulation's interpretation shifts.

Look elsewhere when:

• We are not operating in Spain, or we need SII, Facturae, Crea y Crece, or EU-wide e-invoicing (Peppol/EN 16931) — those are different specifications with different vendors.
• We need a managed service with SLAs: hosted submission, guaranteed retries, certificate custody, and a support contract. This is a library, not a provider.
• We want a turnkey SaaS with dashboards, ticket/QR generation for end customers, and reconciliation — that is product work, not package work.
• Our stack is not Laravel, or we are on an unsupported PHP/Laravel version.
• We require demonstrable production adoption before adding a compliance dependency — two new contributors is encouraging but is not production evidence; we would still be an early adopter absorbing discovery risk.
• We cannot accept bus-factor risk on a legally mandated path; in that case budget for a maintained commercial alternative or in-house ownership with a spec test suite.

How to Pitch It (Stakeholders)

For executives: Spain's VeriFactu mandate becomes enforceable for our customer base in the 2026–2027 window. Non-compliance blocks sales in that market and creates penalties and audit exposure for customers — so this is a revenue-gating requirement, not a nice-to-have. This MIT-licensed Laravel package gives us a head start on the compliance layer at near-zero licensing cost: it is a focused, low-coupling dependency that lets us ship a credible "VeriFactu-ready" capability in weeks rather than quarters, and it maps directly to the largest near-term opportunity in our pipeline. The newest release (v1.0.2) removes a concrete blocker for our business model — the software-system identifier in each invoice record is now configurable, so one build can serve multiple tenants and AEAT test environments — and it is the first release with outside contributors, a small but real sign the project is not a single-person side project. The trade-off remains maturity: small star count, no production adopters we can point to, and no support contract, so we should treat it as an accelerator behind our own interface, budget for independent fiscal review before any customer-facing compliance claim, and keep an exit path. Recommendation: approve a short spike (1–2 sprints) to validate coverage against the regulation and our invoice flows — with v1.0.2 the spike can now cover multi-instance config and test-environment submission — then decide on adopting it as an internal, wrapped dependency versus funding a commercial alternative.

For engineering: This is a Laravel 10–12 package covering VeriFactu invoice record management/registration — the plumbing layer, not the whole product. v1.0.2 makes IdSistemaInformatico configurable (PR #7) to support multiple test instances, plus an integration fix (PR #10); treat it as a minor, non-breaking release, but read the diff and pin the version — the config change may alter where and how that identifier is resolved, and if we assume per-tenant granularity we may need a thin resolver on our side. Both changes come from first-time external contributors, which is a good maintenance signal but also means new code paths with limited battle-testing. Plan to wrap it behind a VerifactuGateway-style interface so we can swap implementations, and expect to own the hard parts ourselves: certificate lifecycle and signing, submission retries and AEAT rejection/correction handling, idempotency, immutable audit trails, and long-term retention. It is MIT with zero dependents, so legal and blast-radius risk are low, but do not let it leak into domain models — keep invoice aggregates clean of regulatory detail, and build a spec-driven test suite around the regulation so we are validating against the law rather than against the library's behaviour.