Prepare for VeriFactu without rebuilding your entire system

Spain’s VeriFactu requirement changes how invoices are created, not just how they are reported. Systems must produce compliant invoice records with traceability, integrity, and audit-ready evidence. At the same time, invoicing operations cannot stop. ERP, POS, and ecommerce platforms must continue to run without disruption.

The default assumption is that this requires a system replacement. It doesn’t.

Most organisations can meet Spanish Tax Agency (AEAT) VeriFactu requirements without rebuilding their entire stack. The shift is not about replacing ERP or billing systems, but adapting how invoice data is generated, recorded, and controlled.

Let’s explore how to do that.

Key takeaways

• Use an integration layer, not a rebuild. Keep ERP, POS, and ecommerce systems in place and add a connector or middleware to generate compliant records, QR codes, and audit trails required by AEAT.
• Decide your mode early. Choose between VERI*FACTU mode, where records are sent to AEAT in real time, and non-verifiable mode, where records are stored locally with strict integrity guarantees. This decision affects architecture, cost, and operational risk.
• Focus on outputs, not systems. Your systems must produce three minimum outputs: a compliant billing record, a QR code on the invoice, and traceability and immutability evidence.
• Treat traceability as a control, not a feature. VeriFactu requires a complete, provable history. No silent edits, no missing events, and every change must be logged and linked.

Why VeriFactu readiness matters for finance and IT leaders

VeriFactu changes how invoices are produced and controlled. Spain’s invoicing requirements place increasing emphasis on system-level controls, particularly in how invoice data is generated, stored, and validated.

If systems cannot produce compliant records, problems appear quickly. Invoices are challenged, correction flows break down, and audit response becomes slower. The issue is not interpretation of the rules — it’s whether systems can meet them consistently.

Delays in issuing invoices, corrections that cannot be traced, gaps in audit trails, and reliance on manual fixes all increase risk. These issues only repeat as volume grows.

VeriFactu shifts compliance into the system itself.

Invoice integrity, traceability, and auditability must be built into how data is created and managed. This creates a direct link between billing systems and compliance risk.

For most organisations, the practical solution is not to replace systems.

A connector or middleware layer allows businesses to meet AEAT requirements while keeping ERP and billing platforms stable. Compliance logic is separated from core operations, reducing disruption and maintaining continuity.

Compliance and enforcement risk without system-level readiness

The first failures are operational. Invoices cannot be issued correctly, corrections create inconsistencies, and audit responses take longer because evidence is fragmented.

The biggest risk comes from gaps in traceability. If systems allow silent edits or do not maintain a clear event history, compliance cannot be demonstrated. This is where exposure increases — not because of a single error, but because the system cannot prove what happened.

Operational impact across channels and teams

VeriFactu affects every invoicing channel. POS receipts must include compliant outputs. Ecommerce invoices must reflect the same logic. Back-office systems must handle credit notes and corrections consistently.

This creates cross-functional dependency. Finance, IT, operations, and customer service all interact with invoice data. Without alignment, inconsistencies appear across channels.

The ROI of an integration layer versus a forced migration

Replacing ERP or POS systems is costly and slow. An integration layer delivers faster results. By adding a connector or middleware, businesses can:

• Adapt invoice outputs
• Generate compliant records
• Maintain traceability
• Support audit requirements

All without changing core systems. The result is lower cost, reduced disruption, and faster time to compliance.

VeriFactu without a rebuild: The “integration layer” strategy executives approve

Most organisations need to meet VeriFactu requirements without disrupting invoicing operations.

A full system replacement is rarely necessary. A more practical approach is to introduce an integration layer — typically a connector or middleware — that sits between existing systems and the compliance requirements defined by AEAT.

This approach delivers three outcomes: compliance, minimal disruption, and future-proofing.

In practical terms, “no rebuild” means keeping your ERP, POS, and ecommerce platforms unchanged, while adapting how invoice data is processed and output. The core systems continue to manage products, pricing, and billing logic. The integration layer handles the compliance requirements.

That includes generating structured billing records, applying QR codes, maintaining traceability, and enforcing immutability rules. VeriFactu technical requirements highlight the importance of these system-level controls.

What changes vs. what stays the same

By isolating change, core systems can remain unchanged. Including:

• ERP and accounting platforms
• POS and ecommerce systems
• Product catalogue and pricing logic
• AR/AP workflows

The integration layer adds:

• A record builder to create compliant invoice data
• A QR generator for invoice outputs
• An audit log to track all events and changes
• Optional transmission capabilities if operating in VERI*FACTU mode

Success is measurable. For finance, it means consistent invoices and audit-ready records.
For IT, it means minimal system disruption and controlled deployment. For compliance, it means traceability and integrity are built into the process.

VERI*FACTU mode vs. non-verifiable mode: Decide before architecture

VeriFactu allows two ways of operating, depending on how invoice records are handled and controlled. This decision shapes the entire design.

In VERI*FACTU mode, invoice records are transmitted to AEAT in near real time. This requires system connectivity, monitoring of submissions, and handling of acknowledgements from the tax authority.

In non-verifiable mode, records are stored locally but must still meet strict requirements for integrity, traceability, and immutability. The system must be able to prove that records have not been altered.

The choice affects:

• System complexity
• Operational latency
• Control requirements
• Cost and maintenance

It should be made early, before implementation begins. For most organisations, clarity at this stage avoids rework later.

Deadlines and scope: Who is impacted and when (plan for 2027)

VeriFactu has phased deadlines, but it is mandatory. Businesses are expected to comply within the set implementation timeline, so preparation needs to start early.

SII is a useful reference point. If your business already reports under SII, you’re already working with near real-time VAT reporting. VeriFactu builds on this by introducing requirements at system level — specifically how invoice data is generated, stored, and controlled.

Implementation timing you can build a road map around

Current guidance points to a phased implementation, with full compliance expected by 2027. For planning purposes, this should not be treated as a single deadline. It’s a sequence:

• Discovery: Understand current systems and gaps.
• MVP connector: Build a minimal integration layer.
• Pilot: Test in a low-risk channel.
• Scale: Extend across all invoicing channels.

This phased approach reduces risk. It allows finance and IT teams to validate processes before full rollout, rather than attempting a single large change.

The key is to start early. Waiting until deadlines approach compresses testing and increases the likelihood of disruption.

Scope and exclusions that change the design

VeriFactu does not fundamentally change VAT rules. It changes how systems must produce and manage invoice data.

Tax treatment remains the same. What changes is the requirement to generate structured records, maintain traceability, and ensure system integrity.

Scope also depends on your current setup. If your business operates under SII, many processes are already aligned with real-time reporting. If not, VeriFactu introduces new requirements that must be built into existing workflows.

Confirming your regime early — SII, non-SII, or hybrid — helps define the design of your integration layer.

What the VeriFactu regulation actually requires your system to produce

VeriFactu does not ask you to change what you invoice. It requires you to change how your system produces and controls those invoices.

At a practical level, this is about outputs and controls. Your system must generate structured billing records, ensure those records cannot be altered without trace, and provide evidence that supports audit review. The focus is on integrity, traceability, and immutability — not just correct totals.

Record integrity and immutability in operational terms

In simple terms, no silent edits are allowed. If an invoice is created, that event must be recorded. If it’s corrected, the correction must also be recorded, with a clear link to the original.

From an operational perspective, this means that every invoice event has a timestamp, corrections are handled through defined workflows (not overwrites), and a complete history of changes is retained.

Auditors will look for this history. They need to see that records are complete, accessible, and traceable from creation through to any correction. If the system cannot demonstrate this, compliance cannot be proven.

QR and invoice markings: Where it hits your invoice templates

VeriFactu introduces visible changes to invoices. QR codes must be included, containing key information about the transaction. This affects all output formats:

• PDF invoices
• POS receipts
• Customer portal views

This is often where implementation becomes visible to customers. Template ownership becomes important. Finance defines content requirements, but IT controls rendering. In multi-entity or multi-language environments, templates must be consistent while supporting local variations. Common issues include:

• Inconsistent placement of QR codes
• Different formats across channels
• Branding conflicts with compliance requirements

These are design problems, not tax problems.

The billing record chain: How numbering and series choices affect compliance

VeriFactu requires a continuous, traceable chain of records. This depends on how invoices are numbered and grouped.

If numbering is inconsistent across channels — for example, separate series for POS, ecommerce, and back office — the chain can break. This creates gaps in traceability.

Credit notes (rectifications) must also be linked correctly. Each correction must reference the original invoice and maintain the sequence. If this linkage is missing, the audit trail is incomplete.

For finance teams, numbering, series, and correction logic are no longer just accounting decisions. They’re compliance controls.

Five “no-migration” integration patterns to adapt invoices for VeriFactu

Not every business can — or should — replace its ERP or billing systems to meet VeriFactu requirements. In most cases, compliance can be achieved by adding an integration layer that adapts existing outputs.

The choice of pattern depends on how your current systems expose data and how much control you have over them.

Pattern 1: API connector (best for modern ERP/POS)

This is the most robust option. An API connector listens for invoice events, for example “invoice issued”, and processes them in real time. It normalises the data, generates the required record, applies QR and hash logic, and optionally transmits the record if operating in VERI*FACTU mode.

The key advantage is control. The system can enforce validation rules, handle retries, and prevent duplicate submissions through idempotency controls.

The main risk is dependency on API availability. If events are not triggered correctly, records may be missed.

This approach is best suited to modern ERP or POS systems with reliable API access.

Pattern 2: PDF or print gateway when there is no API

When systems cannot expose data via API, outputs can be intercepted.

A gateway processes invoice PDFs or print streams, adding QR codes and generating a parallel structured record store.

The key advantage is minimal system change.

The main limitation is reduced visibility into underlying tax logic. More complex scenarios may require reconciliation to ensure consistency between the document and the record.

This approach is best suited to legacy systems where output is accessible but internal logic is not.

Pattern 3: Database or CDC replication layer

Where direct application access is limited, data can be replicated.

A read-only database or change data capture layer extracts invoice data, transforms it, and generates compliant records without affecting production systems.

The key advantage is low impact on core systems.

This approach requires controls such as daily reconciliation, drift detection, and escalation of mismatches.

The main risk is lag between source data and processed records if replication is delayed.

This approach is best suited to environments where database access is available but application changes are restricted.

Pattern 4: RPA as a last resort for legacy environments

Robotic process automation can simulate user actions to extract and process data. This is not ideal, but it can be used as an interim solution.

The key advantage is speed of deployment in constrained environments.

The main risk is fragility. Changes in user interfaces or processes can break the automation, so it requires close monitoring and strong documentation.

This approach is best suited to low volume, short-term compliance, or as a bridge to a more stable solution.

Pattern 5: Manual or AEAT tool fallback

For low volume or contingency scenarios, manual submission may be used. This ensures continuity if systems fail or for micro-scale operations.

The key advantage is simplicity.

The main limitation is that it does not scale and carries a higher risk of error and delay.

This approach is best suited to contingency planning rather than primary compliance.

The objective is not to choose the most complex solution, but to select an approach that fits your system capabilities while maintaining control, traceability, and continuity.

Designing the VeriFactu module: Minimum components, maximum insulation

The goal is not to redesign your ERP. It’s to isolate compliance into a dedicated module that can sit alongside existing systems.

A well-designed VeriFactu module acts as a control layer. It takes invoice data from your systems, standardises it, applies compliance logic, and produces the required outputs — without changing core billing processes.

This makes it reusable across ERP, POS, and ecommerce channels.

Data normalisation layer: Translating your invoice into a compliance-ready model

The first step is standardisation. Different systems store invoice data in different formats. Fields may be named differently, structured differently, or populated inconsistently. Common problem areas include:

• Counterparty identification
• VAT treatment and exemptions
• Rounding differences
• Discounts and adjustments
• Special regimes

The normalisation layer translates this into a consistent format that meets VeriFactu requirements.

Validation is key. Finance teams must decide whether to block invoice issuance when data fails validation or allow it and correct later. In most cases, blocking high-risk errors reduces downstream issues.

Hashing and chaining layer: Making traceability provable

VeriFactu requires a continuous, verifiable chain of records. Each invoice must be linked to the previous one through a hash. This creates a sequence that cannot be altered without detection.

Design decisions matter. The chain can be defined per series, per entity, or per channel. Choosing the wrong scope can create complexity or break traceability. The system must also handle real-world scenarios:

• Retries when submission fails
• Replays when data needs to be resent
• Partial outages

Without this, gaps appear in the chain.

Document rendering layer: QR, markings, and multichannel output

Invoices must include specific markings and a QR code. This requires a unified rendering approach. Instead of generating different formats in different systems, a single rendering layer ensures consistency across:

• PDF invoices
• POS receipts
• Customer portals

Templates should be version-controlled. Compliance elements — such as QR placement — must be fixed, while branding elements can vary. This prevents accidental changes that break compliance.

Transmission and acknowledgements (if you choose VERI*FACTU mode)

If operating in VERI*FACTU mode, records must be transmitted to AEAT. This requires a queue-based system. Records are sent, responses are received, and statuses are tracked:

• Sent
• Accepted
• Rejected
• Retried
• Quarantined

The system must handle peak volumes and backpressure without interrupting invoice issuance.

Reconciliation reports confirm that all records have been processed, with no gaps or mismatches.

The objective is to keep compliance logic separate from core billing systems.

That way, regulatory changes can be handled in the compliance layer without disrupting invoicing operations or forcing a full system rebuild.

Certificates, signing, and security: The hidden work that breaks timelines

Many VeriFactu projects do not slip because of invoice logic. They slip because certificate ownership, signing design, and security controls are left too late.

These are not minor implementation details. They determine who can issue compliant records, how failures are handled, and whether the business can prove records have not been altered.

For finance leaders, this affects continuity. For IT and security teams, it affects control.

Certificate ownership: Company-controlled vs provider-managed

One of the first decisions is who controls the digital certificate. If the business controls it, ownership is clear and incident response stays in-house. The trade-off is operational burden. Someone must manage renewal, rotation, access, and testing.

If the provider manages it, implementation may be faster. The trade-off is dependency. If the relationship changes or an incident occurs, the business may have less control over continuity and recovery.

Whichever model is chosen, renewal cannot be left to chance. A certificate that expires silently can stop compliant operation without warning.

This needs a named owner, a renewal calendar, and a tested fallback process.

Security controls that prove records weren’t tampered with

VeriFactu is not just about generating records. It’s about proving they were controlled properly. That requires clear segregation of duties. The people who issue invoices should not have the same permissions as those who void records or administer compliance settings.

It also requires immutable logs. Every issue, correction, retry, and status change must be recorded in a way that cannot be altered without detection.

Retention matters too. Logs, exports, and supporting evidence must be accessible for review, not buried in system archives or scattered across vendors.

For finance teams, the practical question is: could you show an auditor exactly what happened to a record, when it happened, and who triggered it?

If the answer is unclear, the security model is not ready.

Expensive mistakes when adapting billing for VeriFactu and how to avoid them

Most issues with VeriFactu implementation are not technical failures, but design decisions that create risk later.

Treating VeriFactu as the same thing as e-invoicing

One of the most common mistakes is assuming VeriFactu is simply another e-invoicing requirement. It isn’t.

E-invoicing focuses on how invoices are exchanged. VeriFactu focuses on how invoice data is generated, controlled, and evidenced within your system.

When teams treat them as the same, they create overlapping or duplicated projects. This increases cost and complexity without improving compliance.

The fix is simple: define the boundary early.

VeriFactu is about system integrity and traceability. E-invoicing may be a separate requirement. Design each with a clear purpose.

Building a single point of failure into the connector

Another common mistake is designing the integration layer as a “hard stop.” If the connector fails, invoicing stops. This creates operational risk. Instead, the system should be resilient:

• Queue records when the connector is unavailable
• Allow invoicing to continue
• Process backlog once the issue is resolved

Recovery must also be provable. After an incident, the business must demonstrate that all records were processed and no gaps exist. This requires reconciliation reports and clear audit logs.

Without this, a temporary outage becomes a compliance issue.

Mistakes occur when implementation focuses only on meeting requirements, rather than on maintaining continuity and control. Avoiding these issues means designing for failure as well as success.

How to evaluate your current vendor without switching software

Businesses must understand whether their current vendors can support VeriFactu requirements. This requires moving beyond high-level assurances and asking specific, operational questions.

Questions that force real technical clarity (not marketing)

Start with outputs. Ask what the system actually produces:

• Does it support VERI*FACTU mode, non-verifiable mode, or both?
• What records are generated, and in what format?
• How are integrity and traceability enforced?
• What audit evidence can be exported on demand?

If the vendor cannot demonstrate how records are created, linked, and stored, the risk remains.

Integration readiness checklist

Next, assess how the system integrates. Key points include:

• Availability of APIs or event-based triggers
• Ability to intercept or modify invoice outputs (PDF/print hooks)
• Export formats for data extraction
• Access to underlying data where needed

Multichannel support is critical. The system should handle POS, ecommerce, and back-office invoices consistently. It should also support multiple entities and numbering series without breaking traceability.

If integration points are limited, additional middleware or a connector layer may be required.

Contract and accountability for regulation changes

Finally, clarify responsibility for change. VeriFactu requirements will evolve. The key question is: who tracks those changes and updates the system? Ask:

• How quickly updates are delivered
• Whether updates are included in the contract or charged separately
• What testing and validation are provided

AEAT is the reference authority for ongoing requirements, so vendors should demonstrate how they monitor and respond to updates.

Without clear accountability, compliance becomes dependent on manual adjustments — which reintroduces risk.

Turn compliance into a durable operating advantage

VeriFactu is not just a compliance requirement. It’s an opportunity to stabilise invoicing processes and reduce operational risk.

The “no rebuild” approach is central to this.

By introducing an integration layer, businesses can meet AEAT requirements without disrupting ERP, POS, or ecommerce systems. Compliance becomes a controlled process, rather than a series of manual workarounds.

A 7-step action plan

• Confirm scope and regulatory regime early
• Choose VERI*FACTU or non-verifiable mode before designing architecture
• Select the right integration pattern for your systems
• Build a minimum viable connector or module
• Run in shadow mode to validate outputs and controls
• Roll out in phases by channel
• Monitor performance and refine continuously

This creates a structured path from initial readiness to stable operation.

Future-proofing your connector so you never rebuild later

The long-term value comes from flexibility. A well-designed integration layer should be:

• Version-controlled to support regulatory updates
• Configuration-driven rather than hardcoded
• Supported by regression testing for changes
• Capable of producing audit-ready exports on demand

This ensures the system can adapt without requiring further transformation.

How Avalara can help
Avalara supports organisations preparing for VeriFactu by providing a scalable compliance layer that integrates with existing ERP, POS, and ecommerce systems.

Rather than replacing core systems, Avalara enables businesses to adapt invoice outputs, generate compliant records, and maintain traceability and audit trails required by AEAT. This approach aligns with the integration layer model, helping finance and IT teams implement controls without disrupting operations.

Avalara also supports ongoing compliance through structured monitoring, update management, and audit-ready reporting. This reduces dependency on manual processes and ensures that regulatory changes can be absorbed without system redesign.

The outcome is not just compliance, but a more resilient invoicing process, reduced operational risk, and the ability to scale without repeated system change.

Speak with Avalara today about preparing for VeriFactu without rebuilding your systems.

FAQ

Do I need to replace my ERP or invoicing system to comply with VeriFactu?
No. Most businesses can comply by adding an integration layer (connector or middleware) that adapts invoice outputs, generates compliant records, and maintains traceability without replacing core systems.

What is the difference between VERI*FACTU mode and non-verifiable mode?
VERI*FACTU mode sends invoice records to AEAT in near real time. Non-verifiable mode stores records locally but must meet strict integrity and traceability requirements. The choice affects architecture, cost, and operational controls.

What are the minimum requirements for a VeriFactu-compliant invoice?
Systems must produce a structured billing record, include a QR code on the invoice, and maintain a traceable, immutable record chain showing all invoice events and corrections.

What breaks first if we are not ready for VeriFactu?
Invoice issuance and correction workflows are usually impacted first. Gaps in traceability, missing audit logs, and inconsistent outputs across channels create compliance risk and slow audit response.