01
Issuing map
Series, numbering, corrective invoices, cancellations, retries, multi-entity operation and every point where fiscal data is created or altered.
VERI*FACTU integration for invoicing software
Design and implementation of the technical flow connecting an invoicing product with RRSIF requirements and, where applicable, AEAT services.
Regulatory review
- Scope
- SaaS, ERP, in-house products and invoicing software
- Current milestones
- 1 January 2027 and 1 July 2027, depending on the affected taxpayer
- Boundary
- Technical implementation, not a replacement for tax advice
Context
Adaptation does not end with generating XML. The product needs a documented operating mode, preserved invoice sequencing, traceable records, controlled rejection handling and evidence supporting each software version.
01
Start with the actual flow
The first review identifies where an invoice originates, who can change it and which systems participate before an integration path is selected.
02
Operating mode
A documented VERI*FACTU or non-VERI*FACTU decision with the client’s adviser, keeping the controls of each alternative distinct.
03
Responsibilities
Clear ownership across product, integrator, certificate holder, tax adviser and the person accepting the software release.
02
Implementation components
Scope is defined against published specifications, the product’s use cases and its real operating constraints.
01
Records and validation
Creation and cancellation records, XML/XSD, fiscal fields, chaining, fingerprint, QR and checks performed before submission.
02
Transport and certificates
Authentication, certificate custody, secure submission, idempotency, timeouts and strict separation between test and production.
03
Status and recovery
Acceptances, rejections, corrections, queues, controlled retries, reconciliation and traceability of every response.
03
A reviewable delivery
Adaptation must be tied to a specific software version. A change to fiscal behaviour requires renewed evaluation, updated evidence and a review of the corresponding responsible declaration.
- Requirements matrix and recorded architecture decisions.
- Implementation with unit, integration and negative-path tests.
- External test-environment evidence without real commercial data.
- Operating runbook for incidents, retries and recovery.
- Technical support for preparing the per-version responsible declaration.
04
A schedule without artificial urgency
AEAT currently states 1 January 2027 for Corporate Income Tax taxpayers and 1 July 2027 for the other taxpayers covered by the relevant scope. Before treating either milestone as a project requirement, the client’s tax adviser should confirm the entity, territory, regime and exclusions.
The technical objective is to leave enough time to test a stable release, resolve rejections and rehearse operations rather than discover the real invoicing flow on the application date.
Validation standard
A useful test covers the complete lifecycle and retains per-version evidence. A single accepted submission does not prove that the system is operable.
- 01Creation and cancellation accepted in the external test environment.
- 02Reproducible rejection with the error surfaced without losing traceability.
- 03Correction linked to the previous record and accepted.
- 04Responsible declaration identified with the evaluated release.
Common questions
Short answers about scope, evidence and implementation boundaries.
Does AEAT approve or certify invoicing software?+
This service is not presented as an AEAT approval. The system producer issues a responsible declaration for each version and retains the evidence supporting that declaration.
Do VERI*FACTU and non-VERI*FACTU use the same flow?+
They share RRSIF requirements but are not the same operating mode. The decision affects submission, custody and other controls, so it needs to be fixed before architecture is finalised.
Can the flow be tested without customer invoices?+
Yes. The technical protocol should use controlled test identities and documents, isolate certificates and endpoints by environment, and avoid commercial data in validation artefacts.
Does the integration include tax advice?+
No. The work implements technical requirements and documents decisions. Applicability, tax treatment and fiscal acceptance remain with the client and its adviser.
Official sources
Spanish regulatory and technical sources used for this page. Specifications may change and must be checked again when a project starts.
- Frequently asked questions on invoicing systems
AEAT · Spanish source on schedule, scope and general criteria
- VERI*FACTU technical information and schemas
AEAT · Spanish source on designs, WSDL, XSD and validation
- VERI*FACTU and non-VERI*FACTU operating modes
AEAT · Spanish source on differences between both modes
- Responsible declaration for the invoicing system
AEAT · Spanish source on producer responsibility and releases
- Royal Decree 1007/2023, consolidated text
BOE · Spanish legal text on RRSIF and responsible declarations
- Order HAC/1177/2024, consolidated text
BOE · Spanish legal text on technical requirements and QR
Initial technical review
Review the flow before estimating the adaptation.
Share the product version, invoice types, intended mode and issuing diagram. I can identify dependencies and propose an initial technical scope.
- Do not send certificates, tax IDs, invoices or secrets through this form.
- Tax and legal applicability must be validated with your adviser.
- A human reply, normally within one business day.