Spanish invoicing has moved from "print a PDF and file the VAT return" to "your software must prove what it did". Veri*factu requires that invoicing software produce a tamper-evident record for each invoice — chained to the previous one, hashed, timestamped, carrying the issuer and recipient tax identifiers, the taxable base and quota by rate, and a QR the recipient can verify. Separately, SII requires near-real-time submission of the issued and received invoice ledgers to the AEAT. Two obligations, one posting event, and finance teams end up bridging them with spreadsheets, a third-party portal, and a monthly panic when the ledgers do not agree with the general ledger.

Odoo core does not close this gap. l10n_es gives you a Spanish chart of accounts and tax codes; l10n_es_edi_sii (Enterprise) covers a slice of SII, and neither ships a Veri*factu record chain, the hash/QR generation, or a rejection-and-correction workflow that an auditor can follow. Community editions have no SII path at all. The practical failure mode is not "it does not work" — it is that a rejection from the AEAT lands in a log nobody reads, the invoice stays posted in Odoo, and the ledger silently diverges from what the tax authority believes you issued.

What we build is a l10n_es-dependent module that hangs off account.move and treats the compliance record as a first-class Odoo object rather than a side effect. Posting an invoice fires an override on _post() that snapshots the fiscally relevant fields into a new ecosire.es.verifactu.record model — chained via a previous_record_id and a stored hash computed by a @api.depends-guarded compute so the chain cannot be silently rebuilt, with the QR payload rendered into the QWeb invoice report from that same stored record. Tax mapping is driven from your master data, not hardcoded: account.tax rows carry a mapping field resolving to the correct SII/Veri*factu tax key and régimen clave, and res.partner supplies the NIF/VAT type discrimination (national, intra-community, third country) so the ledger classification is derived from what your accountants already maintain. Submission runs through a queued outbound job driven by an ir.cron and an automated action, so a slow AEAT endpoint never blocks a user posting an invoice; every request and response is persisted on the record with its CSV/acknowledgement, and the whole model is secured with ir.model.access.csv plus record rules so multi-company groups only see their own establishment's records.

Rejections are where most implementations quietly fail, so the correction workflow is explicit. A rejected or partially accepted submission moves the record to a rejected state, raises an activity on the responsible accountant, and exposes the AEAT error code and message in a dedicated notebook page on the invoice form. From there you either resubmit after fixing master data, or issue a factura rectificativa that inherits the original's chain reference — Odoo's credit note flow is extended so the rectification carries the correct rectification type and reason rather than being posted as an unrelated document. Everything remains queryable over XML-RPC/JSON-RPC, so a group consolidation tool or a Power BI model can read submission state without touching the database. We build for whichever of Odoo 17.0, 18.0 or 19.0 you actually run, and we handle the Community versus Enterprise difference explicitly during scoping — on Enterprise we can extend and reuse the existing SII plumbing; on Community we implement the transport layer ourselves.

This is a build-to-order product, not an instant download. You request a quotation, we run a scoping call to confirm your Odoo version and edition, your establishments, invoice volume, whether you are already in SII, your certificate arrangements, and any existing localisation customisations. We then quote a fixed scope, build the module against a copy of your database, and deliver it with UAT on a staging instance before anything touches production. Typical delivery is one working week from confirmed scope — the range moves with how much of your master data needs remediation, which is usually the real work. You receive the full source, the git repository, documentation, a training session, and a post-go-live support window.