Spain has moved invoicing from a bookkeeping obligation into a software obligation. Verifactu, under the anti-fraud law and its invoicing-software regulation, requires that the system issuing the invoice produce an unalterable, hash-chained record at the moment of issue, carry a QR code on the printed or electronic document, and keep an event log that proves nothing was edited afterwards. SII, in force for large filers and VAT groups, requires the VAT ledgers themselves to be transmitted to the AEAT within days of issue or receipt. Dynamics 365 Business Central handles Spanish VAT posting, VAT statements and the 347/349 style reporting well, but it stops short of both of these: there is no Verifactu record, no chain hash, no QR, and no SII web-service client in the base application. Finance teams therefore either key ledgers into the AEAT portal by hand, or bolt on a bridge that lives outside the ERP and immediately drifts from the posted documents it is supposed to represent.\n\nECOSIRE builds a Business Central AL extension that puts both obligations inside the system that already posts the invoice. A table extension on the sales invoice, credit memo and posted equivalents carries the Verifactu fields — record hash, previous record hash, chain sequence, issue timestamp, QR payload — and a codeunit subscribed to the posting events (OnAfterPostSalesDoc and the equivalent service and finance-charge publishers) writes the record in the same transaction that creates the posted document. Because the record is created by an event subscriber rather than a scheduled sweep, there is no window in which a posted invoice exists without a compliant record. The QR is rendered into the report layout so the human-readable document and the machine record come from one posting, not two processes that can disagree.\n\nThe SII side is a separate codeunit set that assembles the issued-invoice, received-invoice and, where in scope, investment-goods and intra-community ledgers, signs the SOAP envelope with your AEAT-registered certificate, and posts to the AEAT endpoint on a job queue entry at whatever cadence your filing profile requires. Tax codes are not re-keyed: clave de régimen, exemption causes and operation types are derived from your existing VAT Posting Setup, VAT Clauses and customer or vendor master data, with a small mapping page for the AEAT-specific codes Business Central does not model. Every submission stores the request, the AEAT response, the CSV and the per-line status. Rejected or partially accepted lines land on a correction worklist page where a finance user sees the AEAT error code in plain language, edits the offending field, and resubmits — the chain and the audit trail record both attempts, which is what an inspection actually asks for. Permission sets separate the person who corrects a rejection from the person who can view the immutable log, and API pages (REST v2.0 / OData v4) expose submission status so Power BI, Power Automate or a Dataverse-connected app can watch the filing position without a database login.\n\nThis is a build-to-order product, not an AppSource download. After a short scoping call we confirm your Business Central version and release wave, SaaS or on-premises, your filing profile (Verifactu only, SII only, or both), which document types and companies are in scope, your certificate handling, and any posting customisations we must respect. We then build against that specification, test on your sandbox against the AEAT test service, and hand over the compiled extension together with the full AL source in your own git repository. Typical delivery is one working week from confirmed scope. You get installation, configuration, documentation, a training session, UAT with a rollback plan, and a post-go-live support window with a named engineer — and because you hold the source, no future change to your AEAT position is gated on our roadmap.