Adapting your invoicing software isn't something you switch on at the last minute. It means confirming the scope, updating or replacing the software, reviewing data and series, generating records with integrity and traceability, testing corrections, training staff and preparing contingency plans. Following the extension approved in December 2025, Corporate Income Tax taxpayers must have their systems adapted before 1 January 2027; all other parties covered by the regulation, before 1 July 2027.
What changes in 2027, and what shouldn't be confused
Real Decreto 1007/2023 approved the regulation setting out the requirements for the systems and software that support invoicing processes. Orden HAC/1177/2024 set out the technical and functional detail behind it. Real Decreto-ley 15/2025 then extended the adaptation deadlines to 2027.
In everyday business conversation, "Verifactu" is used as shorthand for the whole change, but it helps to separate the concepts:
- The RRSIF (the SIF Regulation, Reglamento de los Sistemas Informáticos de Facturación) sets out the requirements that invoicing computer systems within its scope must meet.
- VERI*FACTU is the mode that submits invoicing records to the Spanish Tax Agency (AEAT)'s electronic office under the established technical terms.
- A non-VERI*FACTU system must also meet the requirements that apply to it and keep additional records and controls.
- B2B electronic invoicing belongs to a different framework and different flows. It shares data and integrations, but it is not synonymous with VERI*FACTU.
So the first decision isn't "which vendor do I buy", but which entities, activities, premises, series and applications fall within scope, and which operating mode will be used.
Official timetable and how to read it
Following the 2025 amendment, the Spanish Tax Agency (AEAT) sets out:
| Group | Adaptation deadline |
|---|---|
| Entities filing Corporate Income Tax | Before 1 January 2027 |
| All other parties covered | Before 1 July 2027 |
The period before those dates can be used for testing. It shouldn't be read as licence to postpone the project. An organisation with multiple points of sale, integrations or complex closing processes needs to set aside time to fix defects without putting invoicing at risk.
Dates and scope should be checked again before publishing or executing the plan, since regulatory changes, territorial particularities or excluded situations may exist. Businesses under the Immediate Supply of Information (SII) regime and those operating under regional (foral) systems such as TicketBAI need to analyse their specific fit. It isn't prudent to extrapolate a general answer.
Step 1. Take stock of how invoicing really happens
The inventory needs to cover more than the main program. Many businesses also invoice from ecommerce platforms, POS terminals, spreadsheets, vertical applications, secondary ERPs or manual processes.
For each flow, record:
- the entity and tax ID (NIF) that issues the invoice;
- activity, premises and invoice series;
- application and version;
- vendor and internal owner;
- origin of the order or service;
- tax rules and discounts;
- ordinary, simplified and corrective invoices;
- copies, duplicates and credit notes;
- accounting and banking integration;
- peak volume and critical periods;
- current contingency mode.
The inventory must locate "shadow invoicing": office templates, rewritten receipts or documents issued outside the system. If they remain in place, the project can look finished while a residual channel still falls short of compliance.
Step 2. Confirm scope with tax advice
The company must document who is obliged, which transactions are covered and which exceptions apply. This decision shouldn't rest solely with the software vendor.
A useful scope file includes:
- entities and premises analysed;
- regulations and criteria applied;
- affected applications;
- excluded flows and their rationale;
- mode chosen for each system;
- tax validation and review date.
You also need to define the relationship with the SII, regional (foral) regimes, invoicing by the recipient or a third party, self-billing and foreign systems. When a group shares a platform, scope is decided by entity and flow, not by installation.
Step 3. Demand evidence from the vendor
A sales claim of "Verifactu compatible" isn't enough. The vendor must identify the product, version and configuration; provide the declaration of responsibility required by the regulation; explain the mode; and document technical requirements, updates, support and retention.
Essential questions:
- Which specific version complies, and from what date?
- How does it generate, chain and retain records?
- How does it handle corrections and cancellations?
- What happens if the connection or the AEAT fails?
- How are keys and certificates protected?
- Which fields must users fill in?
- How are the QR code and invoice wording updated?
- What export does it allow for audits or migration?
- What evidence remains of events and changes?
- What SLA does it offer during closing periods and deadlines?
There is no "individual approval" that lets a commercial logo stand in for the company's own due diligence. The declaration of responsibility must be kept on file, and you must check that the version deployed matches the version declared.
Functional requirements that must be tested
The regulation aims to guarantee the integrity, retention, accessibility, legibility, traceability and immutability of records. The specifications set out structure, chaining, fingerprints, events, QR codes and submission.
Testing must run through the whole cycle:
Creating an invoice
Check numbering, date, issuer, recipient, description, taxable bases, rates, tax amounts, totals and rounding rules. The record is generated at the right moment and stays linked to the invoice.
Correction and cancellation
An issued invoice isn't "edited" like a text document. Errors must be corrected through the mechanisms the regulation provides, keeping traceability intact. Test changes of amount, recipient, tax rate, refunds and wrongful cancellation.
Chaining and fingerprint
This validates that the sequence stays coherent and that any tampering is detected. Tests include a change of fiscal year, series, backup restoration and concurrency across terminals.
QR code and invoice display
The invoice must include the elements required for each case. Check printing, PDF output, mobile display, simplified invoices, custom templates and documents generated by integrations.
Submission and response
In VERI*FACTU mode, test submissions, responses, rejections, retries and reconciliation. A technical submission isn't the same as acceptance; statuses must be visible and actionable.
Event logging
Where applicable, there must be evidence of relevant system actions. Access and exports are restricted and protected against unauthorised modification.
Migration without losing traceability
Updating may mean migrating data or switching vendor. The goal isn't to copy everything indiscriminately, but to keep the ability to look up and evidence what's needed.
The plan separates:
- active master data: customers, products, taxes and series;
- pending documents: quotes, orders, delivery notes and invoices;
- legal and accounting history;
- technical records and events;
- attachments and evidence;
- users, roles and authorisations.
Before cutover, clean up data quality: tax IDs, addresses, tax codes, duplicates, series and rules. Afterwards, reconcile counts and amounts by entity, fiscal year, series and tax. Take a protected copy of the previous system and document how to query it.
A migration should never be improvised during a closing period. The rehearsal is run on a representative copy, timed, with an abort criterion defined in advance. The rollback plan states up to what point the previous system can be reused without creating two sources of truth.
Integrations: where projects fail most often
ERP, ecommerce, POS, CRM and sector applications can all share document creation. There must be a single system responsible for numbering and final status. If two systems generate numbers or issue corrections independently, gaps, duplicates or inconsistencies will appear.
Each integration must define:
| Element | Decision needed |
|---|---|
| Master system | Who creates and numbers the invoice |
| Time of issuance | The exact event that triggers the record |
| Identifier | A shared, idempotent key |
| Errors | Queue, retry, alert and owner |
| Correction | Which system initiates and synchronises |
| Reconciliation | Daily comparison of statuses and amounts |
Retries must be idempotent: repeating a request after a timeout must not create another invoice. Partial outages, latency and out-of-order messages should also be rehearsed.
Security, access and data protection
User profiles must separate administration, issuance, correction, viewing and export. Shared accounts make it hard to attribute actions. Proper authentication, immediate access revocation, backup protection, activity logging and vulnerability management are all required.
Certificates or credentials used for submission must not be embedded in code or accessible to every user. They must be stored securely, rotated and monitored.
Invoices contain personal data. The adaptation must be integrated with data processor agreements, access control, retention, handling of data subject rights and transfer analysis wherever cloud or international hosting is involved. The tax obligation justifies certain retention periods, but not indiscriminate commercial use.
Phased rollout plan
Phase 1. Diagnosis
- Inventory of entities, systems and flows.
- Scope decision validated by tax advisers.
- Classification of criticality and integrations.
- Selection of mode and vendor.
Phase 2. Preparation
- Updating master data and rules.
- Contract, declaration of responsibility and support plan.
- Test environment and acceptance test cases.
- Design of migration, security and contingency.
Phase 3. Testing
- Ordinary, simplified and corrective invoices.
- Chaining, QR code, submission and errors.
- Integrations, concurrency and peak volume.
- Restoration, historical queries and rollback.
Phase 4. Pilot
- One controlled entity, premises or series.
- Daily reconciliation and an incident desk.
- Training based on real tasks.
- Fixes before the general rollout.
Phase 5. Going live
- Cutover approved and communicated.
- Reinforced monitoring.
- Support during closing periods.
- Acceptance record and evidence archive.
Acceptance test matrix
| Case | Expected result | Evidence |
|---|---|---|
| Correct invoice | Consistent record and display | PDF, record and log |
| Invalid tax data | Controlled block or warning | Screenshot and ticket |
| Correction | Link to the original and traceability | Related records |
| Network outage | Queue and retry without duplication | Log and reconciliation |
| Restoration | Sequence intact and query available | Test record |
| Change of fiscal year | Series and chaining correct | Sequence report |
| Duplicate integration call | Idempotency prevents a second invoice | Request log |
Contingency plan
It must cover three scenarios: the application being unavailable, the connection with the AEAT being down, and a mass error following an update. For each one, define who declares the incident, how operations continue legally, what data is recorded, how it is recovered and how it is reconciled afterwards.
An uncontrolled parallel spreadsheet shouldn't be kept as a permanent solution. The contingency plan must be approved, numbered, time-limited and rehearsed. Once service is restored, a designated owner reconciles every operation and keeps the evidence.
Common mistakes
- Confusing the SIF regulation with the VERI*FACTU mode.
- Waiting until the legal deadline to request the update.
- Only inventorying the ERP and forgetting POS, ecommerce or Excel.
- Accepting "approved software" without checking version and declaration.
- Testing only a simple invoice, not corrections or outages.
- Migrating historical data without reconciliation or a rollback plan.
- Allowing shared accounts and untraceable changes.
- Failing to coordinate tax advisers, the business, IT and the vendor.
- Treating B2B electronic invoicing and VERI*FACTU as a single project.
- Not reserving support for closing periods and invoicing peaks.
Checklist for management
- Scope documented by entity and flow.
- Applicable dates confirmed against an official source.
- Software, version and mode decided.
- Declaration of responsibility and documentation on file.
- Master data, series and taxes cleaned up.
- Corrections, QR code, records and submission tested.
- Integrations with idempotency and reconciliation.
- Security, certificates and roles reviewed.
- Migration and rollback rehearsed.
- Contingency plan tested and owners trained.
- Acceptance record and evidence archive.
Frequently asked questions
Is VERI*FACTU mandatory for every business?
The regulation requires systems within its scope to meet its requirements. The VERI*FACTU submission mode must be distinguished from a non-VERI*FACTU system. The specific fit must be validated for each obligated party and flow.
What are the 2027 dates?
Before 1 January 2027 for entities filing Corporate Income Tax, and before 1 July 2027 for all other parties covered, under the extension approved in 2025.
Can I keep invoicing with Excel?
You need to analyse whether the tool is being used as an invoicing computer system within scope. A template that generates and keeps invoices shouldn't be assumed excluded without analysis.
Is there officially approved software?
The regulation relies on requirements and on the producer's declaration of responsibility. The company must check the product, version, configuration and evidence, not rely solely on a commercial label.
Is it the same as B2B electronic invoicing?
No. They are different frameworks, although they share data and may require a coordinated architecture.
Is it worth waiting until 2027?
No. 2026 should be used for the inventory, vendor choice, testing, the pilot and a gradual rollout. That runway allows you to fix issues without blocking invoicing.
Official sources consulted
- Real Decreto 1007/2023 (consolidated text).
- Orden HAC/1177/2024.
- Real Decreto 254/2025.
- Real Decreto-ley 15/2025.
- AEAT: extension of the adaptation deadlines.
Summum Sistemas can support the inventory, selection, migration, integrations and testing. Tax responsibility must be validated with competent advice; the technical goal is for the change to be traceable, reversible and compatible with how the business actually operates.