VeriFactu and Anti-Fraud Controls: Implications for Existing Systems

Spain’s anti-fraud framework changes how billing systems behave, not just what they report.

VeriFactu introduces system-level controls that require invoice data to be generated, stored, and managed in a way that prevents manipulation and supports audit review. For finance and IT leaders, this is not a reporting change. It’s a change to how invoicing systems are designed and operated.

Most existing ERP, POS, and ecommerce platforms were not built with these requirements in mind. They allow edits, corrections, and workarounds that break traceability. In a VeriFactu context, those same behaviours create compliance risk.

This is where the impact becomes operational.

Invoice issuance, correction flows, offline transactions, and integrations all need to be reviewed. What worked under traditional processes may no longer meet requirements for immutability, traceability, and audit evidence.

Finance, IT, and operations teams must align on how invoices are created, corrected, and stored across systems. Without that alignment, inconsistencies appear quickly — especially in multichannel environments.

The objective is not to replace systems, but to understand where existing processes break, introduce the right controls, and design a road map that allows compliance to be achieved without disrupting operations.

Key takeaways

• VeriFactu changes system behaviour, not just reporting. You need to build invoice integrity, audit trail, and traceability into how billing systems operate, not add them after the fact.
• The Spain Anti-Fraud Law makes existing practices noncompliant. Silent edits, deletions, and inconsistent correction flows must be replaced with controlled, traceable processes.
• You can adapt existing systems without a full rebuild. Most organisations can keep ERP, POS, and ecommerce platforms and introduce a compliance layer to meet requirements.
• Invoice integrity must be provable at any point. Good compliance means showing exactly what happened to every invoice, when it happened, and who triggered it, with no gaps.

Spain’s Anti-Fraud Law vs VeriFactu: The definitions business teams must get right

VeriFactu sits within Spain’s broader anti-fraud framework. For finance and IT teams, the risk is not misunderstanding the law but what it requires systems to do.

The Anti-Fraud Law and VeriFactu requirements define how invoicing software must behave, not just what data it produces. The distinction matters.

The Anti-Fraud Law sets the objective. VeriFactu defines how systems must meet it.

What Spain’s Anti-Fraud Law is trying to prevent in billing software

At its core, the Anti-Fraud Law targets tampering. In operational terms, this includes editing invoices after issuance without leaving a trace, deleting transactions and recreating them, and running parallel records that do not reconcile.

These behaviours often exist in legacy systems. They are not always intentional. Teams correct mistakes, reissue invoices, or adjust records to fix errors. Over time, these actions create gaps in the audit trail.

In a multisystem environment, the risk increases. ERP, POS, ecommerce, and billing APIs may all handle invoices differently. Small inconsistencies — such as how corrections are applied — can create systemic issues.

The Anti-Fraud Law is designed to remove these gaps.

What VERI*FACTU is and what makes a system “verifiable”

VeriFactu defines two operating approaches.

In VERI*FACTU mode, invoice records are transmitted to AEAT in near real time. This creates an external reference point for validation.

In non-verifiable mode, records remain within the business but must meet strict requirements for integrity and traceability.

A system is “verifiable” if it can prove:

• Records were created in sequence
• Changes were recorded, not overwritten
• Data has not been altered without evidence

The benefit is operational. A stronger evidence chain makes reconciliation easier and reduces audit friction. Finance teams can demonstrate compliance without reconstructing data manually.

Where e-invoicing initiatives get confused with VeriFactu controls

VeriFactu is often confused with e-invoicing, but they’re not the same. E-invoicing focuses on how invoices are delivered. VeriFactu focuses on how invoice data is generated and controlled. Common confusion points include:

• Assuming PDF or structured formats alone are sufficient
• Treating invoice delivery as the compliance requirement
• Overlapping projects that duplicate effort

The distinction is practical. You can have compliant e-invoicing without meeting VeriFactu requirements, and vice versa.

What obligations look like in software behaviours

VeriFactu requirements translate into system behaviours. At a minimum, systems must:

• Create a record for every invoice event
• Maintain traceability across the full life cycle
• Ensure integrity by preventing silent edits
• Provide consistent outputs across channels
• Support export of records for audit

A simple checklist for teams:

• Does every invoice have a traceable history?
• Are corrections recorded rather than overwritten?
• Can records be exported in a consistent format?
• Are outputs aligned across ERP, POS, and ecommerce?

If the answer to any of these is no, the system is not compliant.

Why VeriFactu compliance is hard in existing billing stacks

VeriFactu does not fail because teams don’t understand the rules. It fails because existing billing systems were not designed to meet them.

Most organisations operate across multiple systems. ERP, POS, ecommerce platforms, subscription tools, and APIs all generate invoices in different ways. Each system has its own logic, data model, and correction process. This creates fragmentation.

The Anti-Fraud framework requires a single, consistent view of invoice data. Most stacks do not have one.

System sprawl and inconsistent “issuance truth” across tools

In many organisations, there is no single source of truth for invoice issuance. ERP systems may generate invoices for B2B sales. POS systems handle in-store transactions. Ecommerce platforms issue online invoices. Marketplaces and APIs add further complexity.

Each system may use different numbering sequences, correction logic, and templates and formats. The result is inconsistency. For example, a refund processed in a POS system may not follow the same logic as a credit note issued in the ERP. Over time, these differences break traceability.

The issue is not technical capability, but governance. Without clear ownership of numbering, corrections, and templates, systems drift apart.

Legacy behaviours that break integrity and traceability

Many existing systems allow behaviours that are no longer acceptable under VeriFactu. Common examples include:

• Editing invoices after they are issued
• Renumbering transactions
• Reprinting invoices with changes
• Deleting errors and recreating records

These behaviours are often used to fix operational issues quickly. However, they break the evidence chain. Under VeriFactu, corrections must be recorded, not hidden. Every change must leave a trace. If systems allow these actions, they will continue to happen.

Operational friction points that force exceptions

Even well-designed systems face operational pressure. High-volume issuance, offline POS environments, end-of-day processes, refunds, and recurring billing all introduce complexity.

Teams create workarounds to keep operations running. These exceptions are where compliance breaks. For example:

• Offline transactions that are uploaded later
• Refunds processed outside standard workflows
• Partial shipments that create multiple invoice events

Compliance requires systems that handle exceptions as part of the design, not as afterthoughts. Monitoring and reconciliation must be built in, not added later.

VeriFactu technical requirements that force redesign in legacy systems

VeriFactu does not require new invoices. It requires new behaviour from the systems that create them.

For most organisations, this is where the real work sits. Existing systems can generate invoices, but they do not always preserve the integrity, traceability, and audit evidence that VeriFactu requires. This is what forces redesign.

Immutability and integrity in day-to-day operations

In practical terms, immutability means no silent edits.

If an invoice is issued, it cannot be overwritten. Any change must be recorded as a new event, with a clear link to the original. This changes how teams handle mistakes. Instead of editing a record, they must create a correction. That correction must include:

• Who made the change
• When it was made
• What changed
• Why it changed

These are not audit extras. They’re required system outputs. Legacy systems often allow direct edits because they prioritise operational flexibility. Under VeriFactu, that flexibility becomes a risk.

Traceability across the invoice life cycle

Traceability means being able to follow a transaction from start to finish. In operational terms, this includes:

• The original sale or event
• Tax determination
• Invoice issuance
• Any corrections or adjustments
• The final customer-facing document

Breaks in this chain are common. They appear in areas such as:

• Discounts applied outside standard logic
• Tax overrides
• Split payments or partial shipments
• Bundled products with mixed tax treatment

Each break creates a gap. Under VeriFactu, those gaps must be closed. Systems must show a continuous, consistent record of what happened.

Sequencing, series governance, and concurrency

Invoice numbering becomes a control, not just an accounting detail.

In multichannel environments, different systems often generate their own sequences. POS, ecommerce, and ERP may all issue invoices independently. This creates risk. If sequences overlap or break, traceability is lost.

Concurrency adds another layer. High-volume systems may issue multiple invoices at the same time. Without coordination, numbering collisions or gaps can occur.

The solution is central governance. Series rules must be defined once and enforced across all systems. Each emitter must follow the same logic.

Invoicing record structure and exportability

VeriFactu requires records to be accessible and exportable. This means:

• Data must be complete
• Formats must be consistent
• Records must be retrievable on demand

In practice, finance teams need to be able to produce:

• Invoice records by period
• Full event histories
• Supporting data for audit

If data is fragmented across systems, this becomes difficult. Exportability should not be limited to extracting data but include having a consistent structure that can be reviewed externally.

Customer-facing outputs and consistency across channels

Invoices must be consistent across all channels. This includes PDF invoices, POS receipts, and email or portal views. VeriFactu introduces visible requirements such as QR codes. These must appear correctly in all formats.

In many organisations, templates are managed separately by different systems. This leads to inconsistencies. To avoid this, template governance must be centralised.

Compliance elements must be fixed. Branding can vary, but required elements must remain consistent. Legacy systems do not fail because they cannot generate invoices. They fail because they cannot guarantee how those invoices are controlled, linked, and evidenced.

That is what VeriFactu changes.

Anti-fraud controls auditors expect billing software to demonstrate

VeriFactu shifts audit focus from transactions to systems. Auditors are no longer just checking whether VAT has been calculated correctly. They’re also assessing whether billing systems prevent manipulation, preserve evidence, and produce a reliable audit trail.

This changes what “good” looks like.

Anti-tampering controls that must be demonstrable

Controls must prevent and detect changes to invoice data. This includes:

• Blocking deletion of issued invoices
• Preventing overwrites of existing records
• Recording all changes as new events

If data is changed, there must be evidence of that change. If data cannot be changed, the system must prove it. Auditors will expect to see that systems enforce these rules consistently.

Controls that prevent parallel records in multisystem environments

In complex environments, the risk is not just tampering. It’s duplication. Different systems may generate overlapping records, creating “parallel books” that do not align. To prevent this, businesses need:

• Central control of invoice numbering
• Defined series rules across systems
• Monitoring of sequence integrity

Without these controls, gaps appear. The more systems involved, the higher the risk.

Access controls and segregation of duties

Control over who can perform actions is critical. Key roles include:

• Issuing invoices
• Approving transactions
• Making corrections
• Managing system settings

These roles should be separated. If a single user can issue, edit, and approve invoices, the system cannot demonstrate control. Special attention is needed for:

• Administrator access
• Emergency overrides
• Temporary permissions

These must be logged and reviewed.

Vendor and support access controls

Third-party access is often overlooked. System vendors, integrators, and support teams may have access to billing systems. This creates additional risk. Controls should include:

• Logged sessions for all external access
• Approval processes for changes
• Defined responsibilities for each party

Without this, accountability becomes unclear.

Evidence readiness

Auditors expect evidence quickly. This includes:

• Invoice records
• Event histories
• Configuration settings
• Access logs

The key requirement is speed and clarity. If teams need to assemble evidence manually, the process becomes slow and error-prone. A compliant system should be able to produce this information on demand.

The underlying principle is simple. Controls must be visible and provable. It’s not enough to have processes in place. Systems must demonstrate that those processes are enforced.

Implications for existing systems: ERP, POS, ecommerce, and API-driven invoicing

VeriFactu does not affect a single system. It affects how all invoicing systems work together.

Most organisations do not have one billing system. They have several. ERP handles core finance. POS manages in-store sales. Ecommerce platforms handle online transactions. APIs generate invoices for subscriptions or integrations.

Each of these becomes part of the compliance scope.

Build an invoicing “source of truth” map before changing systems

Before making changes, you need to understand where invoices are actually created. This means mapping:

• Every system that issues invoices
• Every integration that moves invoice data
• Any manual steps in the process
• Any “issued on behalf of” scenarios

Without this, changes are applied in the wrong place.

Ownership must also be defined. Who controls numbering, corrections, templates, and record storage? If ownership is unclear, inconsistencies will persist.

This mapping exercise is the foundation for any compliant design.

Event handling, retries, and duplicates

Modern systems rely on events. When an invoice is issued, an event is triggered. That event may be retried if a system fails to respond. It may be processed by multiple systems at the same time. This creates risk.

Duplicate records can appear. Events can be processed twice. Timing differences can create inconsistencies. In simple terms, the same invoice may be recorded more than once. To prevent this, systems need:

• Unique identifiers for each transaction
• Correlation IDs to track events across systems
• Logic to ensure events are only processed once

Without these controls, traceability breaks.

Observability and reconciliation

It’s not enough to process invoices correctly. You must be able to prove what happened. This requires observability. Systems must log:

• When an invoice was created
• When it was transmitted
• When it was corrected
• What responses were received

These logs must be usable by finance teams, not just IT.

Reconciliation is the next step. Finance needs to confirm that:

• All invoices issued are recorded
• All records are complete
• No duplicates or gaps exist

This must be possible without manual reconstruction.

Multisystem coexistence after acquisitions

Many organisations operate multiple systems due to acquisitions. This creates two options:

• Keep systems separate and apply a control layer across them
• Consolidate invoicing into a single system

Both approaches can work. The key is consistency.

If systems remain separate, they must follow the same rules. If they are consolidated, migration must be controlled to avoid breaking the audit trail.

Master data prerequisites

Data quality determines success. Key areas include:

• Customer identification
• Product tax treatment
• Invoice series and numbering
• Correction logic

If these are inconsistent, compliance cannot be achieved.

Data governance is not optional. It requires:

• Defined ownership
• Clear rules
• Controlled changes

Without this, even well-designed systems will fail.

VeriFactu does not require new systems. It requires existing systems to behave in a controlled, consistent, and traceable way.

Process redesign that replaces “edit the invoice” with compliant correction flows

VeriFactu requires a fundamental change in how teams handle mistakes. The common approach today is simple: edit the invoice, fix the issue, and move on. Under VeriFactu, that approach no longer works.

Every correction must be recorded, not hidden.

Correction patterns teams can adopt without slowing billing operations

Teams need a consistent approach to corrections across all systems. In practice, this means defining clear correction types:

• Credit notes
• Rectifying invoices
• Full reversals

Each type should have a defined use case. For example:

• A pricing error triggers a credit note
• A VAT error requires a rectifying invoice
• A cancelled transaction results in a reversal

Approvals should also be standardised.

Not every correction needs the same level of control, but all corrections must be recorded with a reason and linked to the original invoice.

The objective is consistency. If different teams apply different correction logic, traceability breaks.

POS realities: daily close routines, refunds, and offline operation

POS systems introduce additional complexity. Daily close routines, refunds, and voids must all be handled within the same traceable framework. Key challenges include:

• End-of-day reconciliation
• Refunds processed after closure
• Void transactions
• Offline operation

Offline scenarios are critical.

When a POS operates without connectivity, transactions must still be recorded and later synchronised without breaking sequence or traceability. This requires:

• Local logging of all events
• Controlled upload once systems reconnect
• Reconciliation to confirm completeness

Without this, gaps appear in the record chain.

Data migration and historical record strategy

Migration is a high-risk area. Common mistakes include:

• Renumbering historical invoices
• Backdating corrections
• Merging invoice series without preserving links

These actions break traceability. A compliant approach requires:

• Preserving original numbering
• Maintaining links between records
• Creating a clear audit trail for migration

This often involves producing a migration pack. The pack should include:

• Record counts before and after migration
• Reconciliation results
• Sign-off from finance and IT

The goal is not just to move data but prove that nothing has been lost or altered.

Instead of editing invoices, teams must adopt structured correction flows that preserve a complete and auditable record of every change.

Risk and vendor management: How leaders reduce exposure under anti-fraud billing rules

VeriFactu risk is not just technical. It’s also organisational. Most failures happen when responsibility is unclear or when vendors are assumed to be “handling compliance” without clear accountability.

A prioritisation model that turns complexity into an implementation order

Not all systems carry the same risk. Leaders should prioritise based on:

• Invoice volume
• Cash impact
• Number of systems involved
• Frequency of manual intervention
• Complexity of corrections

This creates a clear starting point.

High-volume, customer-facing systems should be addressed first. Lower-risk systems can follow. This approach turns complexity into a manageable sequence.

Vendor due diligence questions that matter

Vendors must be able to demonstrate compliance, not just claim it. Key questions include:

• What VeriFactu mode is supported
• What records are generated and stored
• How integrity and traceability are enforced
• What audit evidence can be exported

Answers should be specific. If a vendor cannot show how records are created, linked, and controlled, the risk remains with the business.

Governance that keeps compliance durable

Compliance does not end at go-live. It requires ongoing governance. This includes:

• Defined ownership across finance, IT, and operations
• Change control for system updates
• Regular testing of controls
• Review of logs and evidence

Without governance, systems drift.

Changes are introduced without validation, and compliance degrades over time.

Accountability in “issued by third parties” scenarios

Many businesses rely on third parties. This includes marketplaces, platforms, integrators, and shared service centres. In these cases, responsibility can become unclear.

The key is documentation. Businesses must define:

• Who issues the invoice
• Who controls the data
• Who maintains the records

Even when third parties are involved, accountability remains internal.

Compliance risk is reduced when ownership is clear, vendors are accountable, and controls are actively managed.

A practical modernisation road map for existing systems

VeriFactu compliance does not require a full system replacement. It requires a structured approach to adapting existing systems.

The objective is to introduce controls without disrupting operations.

Phase 1: Discovery and gap assessment

Start by understanding your current environment. Map:

• All invoice emitters (ERP, POS, ecommerce, APIs)
• Invoice types used in practice
• Correction workflows
• Data storage locations
• Output formats and templates
• Access and permission models

Then assess gaps. Focus on:

• Integrity and immutability
• Traceability across systems
• Ability to export records
• Consistency of outputs

This phase defines the scope.

Phase 2: Design choices that reduce risk and rework

Next, decide how invoicing will be controlled. Two main approaches exist:

• Centralised issuance
• Distributed issuance with strict governance

The choice depends on:

• Number of systems
• Transaction volume
• Integration maturity
• Appetite for change

The goal is to reduce duplication and enforce consistency. Decisions made here will determine how complex the implementation becomes.

Phase 3: Testing that proves controls

Testing must go beyond functionality. It must prove that anti-fraud controls work. This includes:

• Attempting to edit or delete records
• Breaking numbering sequences
• Creating duplicate events
• Testing access controls

Performance must also be tested.

High-volume issuance, batch processing, and end-of-day operations should be included.

Phase 4: Rollout patterns that protect operations

Rollout should be phased. Start with:

• A pilot system or location
• A limited invoice series
• Low-risk transactions

Then expand.

Parallel runs help reduce risk. Systems operate in both old and new modes until outputs are validated.

A rollback plan is essential. If issues occur, operations must continue.

Phase 5: Continuous monitoring and control testing

Compliance is ongoing. Systems must be monitored for:

• Sequence anomalies
• Missing records
• Export failures
• Reconciliation gaps

Regular reviews are required. Weekly checks identify issues early. Quarterly reviews ensure controls remain effective.

The outcome is stability. A structured road map allows businesses to meet VeriFactu requirements while maintaining control over invoicing operations.

What success looks like after VeriFactu readiness

VeriFactu changes how invoicing systems operate, but the objective remains the same: consistent outputs, a complete audit trail, and provable invoice integrity.

When systems are designed correctly, the outcome is operational. Invoices are issued consistently across channels. Corrections follow defined workflows. Data can be traced from creation through to final output without gaps. Audit response becomes faster because evidence is already available.

For most organisations, the next steps are straightforward:

• Map your current invoicing architecture
• Identify where traceability breaks
• Align finance and IT on ownership and controls
• Build a phased implementation plan

How Avalara can help

Avalara helps businesses meet VeriFactu requirements without rebuilding their billing systems.

By introducing a dedicated compliance layer, Avalara enables organisations to generate structured invoice records, apply required controls, and maintain a complete audit trail across ERP, POS, ecommerce, and API-driven environments. This allows existing systems to continue operating while meeting AEAT requirements for integrity and traceability.

Avalara agentic AI capabilities continuously monitor invoice data, detect anomalies, and identify patterns that indicate potential compliance risk. Instead of relying on manual checks, the system flags inconsistencies in real time and supports faster resolution before they impact reporting or audit outcomes. This reduces dependency on manual processes and helps finance teams maintain control as transaction volumes grow.

The result is not just compliance, but a more resilient invoicing process. Fewer errors, faster reconciliation, and audit-ready records become part of normal operations.

Speak with Avalara for help preparing for VeriFactu with minimal disruption and built-in compliance intelligence.

FAQ

What does VeriFactu require from existing billing systems?

VeriFactu requires systems to generate structured invoice records, prevent silent edits, and maintain a complete, traceable audit trail. This includes recording every invoice event, linking corrections to original transactions, and ensuring data can be exported for audit.

Do we need to replace our ERP or POS system to comply with VeriFactu?

No. Most organisations can comply by adapting existing systems. This typically involves adding a control or integration layer that handles record creation, traceability, and audit requirements without replacing core billing platforms.

What breaks first if our systems are not VeriFactu-ready?

Invoice corrections and traceability usually fail first. Common issues include overwritten records, missing event history, inconsistent numbering across systems, and gaps in audit evidence.

How do we prove compliance during an audit?

You need to show a complete audit trail. This includes invoice records, event logs, correction history, system configurations, and evidence that records have not been altered without trace. The ability to export this data quickly is critical.