Product Decisions This Supports
- Build vs. buy for Verifactu compliance. This release extends the library's coverage of AEAT interaction flows beyond invoice registration: it now handles requerimientos de información (AEAT information requests, where the tax agency asks the taxpayer to submit records or clarify data) and baja de remisión voluntaria (voluntary withdrawal from the Verifactu remission system). For a PM, each of these is a distinct compliance workflow that would otherwise be a bespoke integration ticket — their presence here meaningfully reduces the scope of a "build" option for the whole billing-compliance surface.
- Roadmap sequencing for billing/invoicing features. If your roadmap has a Verifactu workstream (mandatory for Spanish corporates from January 2026 and autónomos from July 2026 under RD 1007/2023), this release signals the maintainer is closing the operational gaps that appear after go-live — i.e., reactive AEAT correspondence and de-registration, not just record submission. That's a signal you can plan a phased rollout: registration + hash chain + QR first, AEAT back-office flows second.
- Support and operations cost modelling. Handling an AEAT information request is a legally time-boxed, low-frequency but high-consequence event. Having library support changes the staffing model: instead of an engineer building a one-off submission path under deadline pressure, ops/finance can run an established flow. That lowers the cost of the "support" phase of the product lifecycle and reduces the risk of an unplanned roadmap interruption.
- Vendor and exit-risk posture. Voluntary withdrawal from remission support is a reversibility feature: it means a customer (or your own product) can move off Verifactu remission without hand-crafting deregistration messages. This is directly relevant to decisions about whether to hard-commit to a single compliance provider, and to contractual/portability commitments you make to customers.
- Documentation-driven adoption. The addition of usage guides is a PM-visible maturity marker: it means the package is moving from "usable by the maintainer" to "usable by a team under time pressure." That should shift your estimate of onboarding cost downward and make it plausible to assign implementation to a mid-level engineer rather than a domain specialist.
- Release cadence as a signal. A v0.3.x patch bump adding two functional AEAT flows (not just fixes) suggests the surface area is still expanding and the API is still pre-1.0. That informs whether you build a thin internal adapter layer around it now, versus coupling directly.
When to Consider This Package
Consider it when:
- You are a Spanish taxpayer or you sell billing/invoicing software into Spain and need Verifactu-compliant record generation, hash chaining, QR generation, and AEAT submission within a PHP/Laravel codebase. Rewriting the record schema and hash-chain rules from the specification is high-risk, low-differentiation work.
- Your stack is PHP and you are comfortable with a framework-agnostic library rather than a Laravel-native package. This is a plain PHP package; in Laravel you will wrap it in a service, bind it in the container, and manage configuration yourself. That is a modest amount of glue, not a blocker.
- You need the back-office flows, not just submission. The v0.3.4 additions (information requests, voluntary withdrawal) are exactly the workflows that surface months after launch. If you are choosing a library now, the fact that these exist reduces your future bespoke work.
- You want to own the integration rather than rent it. If your product differentiates on billing correctness or data residency, keeping the compliance logic in-process (with your own persistence and audit log) is preferable to a SaaS compliance API.
- You can absorb pre-1.0 churn. You should plan a thin anti-corruption layer over the library's API surface, and pin versions deliberately rather than floating.
Look elsewhere when:
- You need a supported, SLA-backed dependency. This is a community package at v0.3.x. There is no vendor contract, no LTS commitment, and version bumps have already carried functional changes. For a regulated obligation with statutory deadlines, you need a mitigation plan (fork, or a paid alternative) before committing.
- You are not in Spain or not subject to Verifactu. The regulation-specific logic is the entire value here.
- You need a Laravel package with published config, migrations, queue integration, and an Eloquent model for invoice records. This gives you the protocol layer; you build the persistence, queueing, retry, idempotency, and audit-trail layer yourself. Budget for that explicitly — it is not incidental.
- Your compliance scope includes SII or other AEAT flows not covered. Check coverage explicitly against your obligation list rather than assuming "Verifactu support" means "AEAT support."
- You need certified/officially recognised software status. Library choice does not confer it; the declaration and certification obligations sit with the producer of the billing software, and you must verify the library's output against the current AEAT specification and validation service regardless of what the README claims.
- You require Spanish-language vendor support or formal security review artifacts. None is implied here.
How to Pitch It (Stakeholders)
For executives: We are assessing an open-source PHP library that implements Spain's Verifactu anti-fraud invoicing requirements — the mandated record format, cryptographic hash chaining, QR codes, and submission to the tax agency. The new release (v0.3.4) adds two workflows that matter operationally after go-live: responding to formal information requests from the tax agency, and voluntarily withdrawing from the remission regime. In plain terms, it broadens coverage from "file invoices correctly" to "handle the tax agency's follow-up correspondence and exit cleanly if we choose to." The commercial case is that it substitutes a well-defined, low-differentiation compliance build with an integration we control, and the new reversibility feature reduces lock-in risk in any future vendor arrangement. The caveat is maturity: this is a pre-1.0 community package with no support contract, so we would wrap it behind our own interface and pin versions. Recommended next step is a time-boxed technical spike to validate output against the tax agency's validation service before we commit it to the roadmap.
For engineering: The library covers record generation, hash chaining, QR, and AEAT submission, and now adds information-request handling and voluntary deregistration. It is framework-agnostic PHP, not a Laravel package — expect to write a service provider binding, configuration, persistence for the hash chain and submission state, queue-based retry with idempotency, and an audit log. Treat it as a protocol implementation, not an application. Wrap it behind an internal interface so that a future version bump — or a fork — does not ripple through the codebase. Two things to verify in the spike: that the current output validates against AEAT's test environment, and that the hash-chain persistence model is safe under concurrent invoice creation, since that is where correctness failures are most expensive.