Verifactu impact on touchless AP

ininvoice: Verifactu is the invoicing records system regulated by Spanish Royal Decree 1007/2023: every issued invoice generates a signed record with a chained hash and, in verifiable mode, is transmitted to the Spanish tax agency in real time. For accounts payable the game changes. If your suppliers issue Verifactu, the invoices you receive are already on file at the tax agency with structured data. Any manual re-keying in your AP introduces divergences between what AEAT has and what your accounting reflects. Touchless stops being efficiency: it becomes compliance hygiene.

For the last two years, accounting software vendors and many tax advisors have talked about Verifactu as an issuer project: the ERP that signs, the POS that generates the QR, the invoicing system that adapts. True, but it's only half the picture.

The other half is carried by the recipient. And nobody is telling that part well. If your finance department handles received invoices, Verifactu affects you directly, even if your own invoicing software already complies.

This article is for Finance Directors, controllers and admin leads who live on the AP side. The thesis is simple: when AEAT receives your suppliers' data in real time, any manual re-keying in your AP creates liability. Touchless AP stops being an efficiency project. It becomes a regulatory necessity.

What Verifactu is

Verifactu is the common name for the Computerised Invoicing Systems (SIF) regulated by Royal Decree 1007/2023, of December 5. It requires the software used to issue invoices to generate, for every invoice, a structured record signed and chained by hash with the previous one.

Every invoice also carries a visible QR code that lets AEAT and the recipient verify the integrity of the data. The official page is on the AEAT electronic site.

The system has two modes:

Verifiable mode (Verifactu). The software sends the invoicing record to AEAT in real time as soon as it's issued. The invoice reaches the customer and, simultaneously, is already on the tax agency's servers.
Non-verifiable mode. The software complies with technical requirements (signed record, chained hash, QR, retention) but doesn't transmit to AEAT. The obligation to keep and exhibit remains with the issuer.

Verifiable mode is voluntary for the issuer. But once activated, the tax agency receives data without intermediaries and without delay. When we talk about AP impact, this is the mode that matters.

What Verifactu is NOT

Three confusions come up repeatedly in conversations with Finance Directors.

1. Verifactu is not the same as SII. The Immediate VAT Information Supply (Royal Decree 596/2016) is a VAT obligation for those who settle VAT monthly (large companies, VAT groups and businesses registered in REDEME) and for those who opt in voluntarily. SII sends VAT books within four calendar days, excluding Saturdays, Sundays and national holidays. Verifactu works at the individual invoice level, affects a much wider universe (companies and self-employed not on SII) and stems from the anti-fraud framework of RD 1007/2023. Companies on SII are outside the Verifactu scope because SII already covers near-real-time reporting.

2. Verifactu is not the mandatory B2B e-invoicing. That rule comes from Law 18/2022 (Crea y Crece) and requires structured e-invoicing between companies and professionals. It's a different rule, with its own calendar and separate regulatory development. Verifactu regulates how invoicing records are generated; Crea y Crece regulates format and transmission between companies. They coexist, but are not interchangeable. B2B e-invoicing, developed by Royal Decree 238/2026, applies from 6 October 2027 to companies with turnover above EUR 8 million and from 6 October 2028 to everyone else, according to the AEAT implementation calendar.

3. Verifactu doesn't require transmission to AEAT. Compliance is on the software (signed and chained records). Real-time submission in verifiable mode is an issuer choice. The thing is, that choice is designed to be attractive (simplification of formal obligations, presumption of compliance), so many issuers will activate it.

Verifactu deadlines

The deadlines are set in the fourth final provision of Royal Decree 1007/2023, as amended by Royal Decree-law 15/2025. Application is staggered by obligor type.

Obligor	Billing system adapted	Rule
Corporate income tax payers (art. 3.1.a)	Before 1 January 2027	RD 1007/2023, 4th final provision (as amended by RDL 15/2025)
All other obligors, including self-employed and professionals	Before 1 July 2027	RD 1007/2023, 4th final provision (as amended by RDL 15/2025)
Businesses keeping their VAT books through the SII	Outside Verifactu	RD 1007/2023, art. 3.3

On 5 October 2026 the Spanish Ministry of Finance announced, in an information note, a further delay to October 2028. It is only an announcement: until it is published in the BOE, the dates in force are the ones in the table. The recipient of an invoice has no Verifactu obligation. Official information is on the AEAT website.

Why Verifactu impacts AP (even if your billing software already complies)

The key argument is this. If your supplier operates in verifiable mode, when you receive their PDF invoice the tax agency already has the same record on file: amounts, taxable base, VAT rate, hash, date and issuer. The record you book in your accounting must match that record.

Until today, manual AP has lived comfortably in the asymmetry: the supplier declares when they declare, you book when you book, and reconciliation comes late or doesn't come. Verifactu closes that asymmetry on the issuer side.

Consequences for AP:

Any manual re-keying introduces measurable noise. A mistyped digit, a confused VAT rate, a rounded total: it's no longer an internal error; it's a divergence from data AEAT received from the issuer.
The received-invoices book must be cross-checkable with Verifactu on any audit. If AEAT crosses amounts and tax IDs between Verifactu and your form 303 / 390, the differences appear on their own.
Capture lead time drops. It's not viable for an invoice to take two weeks to enter your accounting if AEAT already had it from day one.
The QR is a shortcut. Verifying the QR code on the received invoice is a direct way to validate that the data you're ingesting matches the data signed by the issuer.

This doesn't make Verifactu compliance a new recipient obligation. It turns manual AP into a process with latent liability.

IDP vs classic OCR on Verifactu invoices

Classic OCR read pixels. It pulled a number from a field, spat it out, and someone reviewed. Worked for years at 95-98% rates on standard invoices. But 2-5% is a lot when the data on the other side is signed by AEAT.

Verifactu invoices arrive with two vectors of structured data that classic OCR doesn't use well:

The QR code contains a URL with parameters (issuer tax ID, invoice number, total amount, date). Decoding it is reading signed data, not interpreting pixels.
If the supplier also issues FacturaE or structured XML attached to the PDF, that data is official. The PDF is the wrapper.

Verifying the QR against the AEAT or parsing the XML are integrity controls that exist, but they need dedicated tools and do not replace the recipient's operational work: cross-checking the invoice against the PO and delivery note, ruling out duplicates and checking VAT, withholding, tax ID and dates before paying. That control is what separates a reliable accounts payable flow from a last-decade OCR, and it is where ininvoice works: it reads the invoice as it arrives (PDF or image) and sends any doubtful field to human review instead of letting a misread figure into the entry.

Mandatory B2B e-invoicing in Spain changes the receiving side too. The guide for the company that receives the invoices explains what changes and when. Read the e-invoice reception guide

The touchless AP flow under Verifactu

The AP flow changes less in structure than in error tolerance. A Verifactu-adapted touchless flow looks like this:

Intake. The invoice enters from Gmail (OAuth, read-only access) or by manual upload.
AI extraction. ininvoice reads the invoice as PDF or image and extracts header and lines. If a field is unclear, the invoice goes to human review; a doubtful figure is never posted.
Duplicate detection. Multi-criteria comparison, with a block before approval and a side-by-side view.
Tax checks. Total = base + VAT − withholding, the invoice tax ID against the PO supplier, dates and intra-EU VAT (reverse charge).
Line-by-line three-way matching. The invoice is cross-checked with its PO and delivery note at the line level, with configurable tolerance (e.g. 2% / EUR 1.50 OR per line).
Approval and recording. If everything squares, the invoice is ready for approval with clean data and an audit trail.
Export. The result is exported as a CSV or Excel file, with an audit-trail sheet, importable into Holded, Sage or A3.

The underlying principle: people spend their time on exceptions, and what matches is left ready for a person to approve. And the exceptions are three-way matching discrepancies, duplicates and fields the AI cannot read with confidence.

What does this look like on your real invoices?

ininvoice ingests from Gmail, reads your invoices as PDF or image, cross-checks line by line with PO and delivery note and holds possible duplicates for a person to decide; a person approves, and approved invoices are exported as CSV or Excel. See a demo on your own invoices.

Risks of not adapting AP

The argument "I'll do it when an audit comes" has a problem: audits cross data. A mistyped tax ID on a received invoice leaves a gap automatically detectable when the tax agency crosses Verifactu from suppliers with your form 303 or 347. Companies on SII have been living this level of cross-check for years. What changes is the scope expands.

Specific risks:

Divergences between issuer Verifactu and your received-invoices book. Amounts that don't match, shifted dates, mistyped tax IDs.
Re-keying as exposure factor. Every minute a human types invoice data is a minute introducing error.
Long capture lead times. If it takes weeks to post and AEAT already has the invoice, the gaps accumulate.
VAT deduction losses. A poorly captured invoice may fall outside the correct deduction period.

Finance Director checklist for 2026

Confirm with tax advisor when Verifactu applies to you as obligated issuer and whether any of your large suppliers will issue in verifiable mode before you.
Audit your current AP flow: how many invoices go through manual keying, average time to book and historical error rate.
Identify how many of your main suppliers will issue with Verifactu QR in 2027.
Validate that your AP system can read QR and parse FacturaE/XML, not just OCR on PDF.
Define the exception model: which divergences stop the invoice and what tolerance is accepted.
Document the three-way matching cross-check (invoice, PO, delivery note) line by line, with tolerances in percentage and absolute euros.
Review the records retention plan (format, periods, accessibility on audit).
Agree with the ERP (Holded, Sage, A3, etc.) how clean data are exported and how cross-references are kept.
Train the admin team: the role shifts from typing to resolving exceptions.
Ask your advisor or auditor for a mock cross-audit Verifactu vs received book vs form 303 vs form 347 over a real quarter.

Is your AP ready for issuer-side Verifactu?

If the answer is "we'll look at it in autumn", you're already late. Try it with a sample of your invoices.

How ininvoice adapts to Verifactu in AP

ininvoice is pure AP automation software. It doesn't issue invoices. It is not an ERP. What it does, on the AP side, is exactly what a touchless flow under Verifactu needs:

Automated intake from Gmail. Invoices arrive without anyone forwarding.
PDF and image reading with AI. If a field is unclear, the invoice goes to human review; a doubtful figure is never posted. Reading of XML e-invoices (FacturaE, UBL, Peppol) is in development.
Line-by-line three-way matching with configurable tolerance (2% or EUR 1.50 absolute per line, OR-mode).
Duplicate detection crossing issuer, number, amount and date.
Tax checks and CSV/Excel export (total = base + VAT − withholding, tax ID, dates), with an audit-trail sheet, importable into Holded, Sage or A3.

If you want to see the full flow, it is documented in invoice-to-PO-to-receipt matching and AP automation with no manual keying.

Frequently asked questions

When does Verifactu take effect for my company?: Depends on your tax regime. Under RD 1007/2023 (fourth final provision, as amended by Royal Decree-law 15/2025), corporate income tax payers must have their billing system adapted before 1 January 2027 and all other obligors before 1 July 2027. Businesses keeping their VAT books through the SII are outside the scope (art. 3.3). On 5 October 2026 the Ministry of Finance announced a delay to October 2028 that has not yet been published in the BOE.
Does Verifactu require receiving e-invoices?: No. Verifactu regulates how the issuer's invoicing records are generated. The obligation to issue e-invoices between companies comes from Law 18/2022 (Crea y Crece), which is a different rule with its own calendar.
Is it the same as SII?: No. SII is a VAT obligation for large companies, REDEME and VAT groups, who send VAT books in short windows. Verifactu works at the individual invoice level, reaches a wider universe (non-SII companies and self-employed) and stems from a different anti-fraud framework. Those on SII are not on Verifactu.
Do I need to change my AP system for Verifactu?: Not by direct obligation, but yes due to risk exposure. If your suppliers issue in verifiable mode, AEAT receives their data in real time and any manual re-keying in your AP introduces detectable divergences. Touchless AP shifts from "efficiency" to "compliance hygiene".
What about FacturaE?: FacturaE is a standardized signed XML format used especially when invoicing public administrations. It is complementary to Verifactu: an invoice can be FacturaE and, if the issuer operates in verifiable mode, also generate a Verifactu record. In AP, parsing FacturaE delivers cleaner data than any OCR.
Are Verifactu and Crea y Crece the same?: No. Crea y Crece (Law 18/2022) introduces the obligation of e-invoicing between companies and professionals. Verifactu (RD 1007/2023) regulates how invoicing records are generated in any SIF software. Different objective, different development and different deadlines: B2B e-invoicing arrives on 6 October 2027 for companies with turnover above EUR 8 million and on 6 October 2028 for everyone else, according to the AEAT implementation calendar.
What do I do if a supplier already issues Verifactu and I don't?: You receive invoices with QR and, possibly, attached structured XML. Minimum: your AP must be able to read both. Recommended: take the opportunity to close manual re-keying gaps before the cascade reaches your own obligation as issuer. Receiving Verifactu requires no regulatory change in you, but gives you clean data for free.
Does classic OCR work for Verifactu invoices?: It works but loses value. Verifactu invoices arrive with QR and, often, attached XML/FacturaE. Staying on pixel-by-pixel OCR when there is signed structured data is wasting the cleanest source. IDP combining QR, XML and OCR is the new standard.

Three takeaways

Verifactu is a change in how Spain issues. But its most practical effect is for the recipient.

If your supplier issues in verifiable mode, AEAT already has the data. Any manual re-keying in your AP is risk, not just inefficiency.
Touchless AP stops being an optional productivity project. It becomes compliance hygiene.
The modern stack controls what you receive: it reads the invoice as PDF or image, does line-by-line three-way matching, holds possible duplicates, checks VAT, withholding and tax ID and, once a person approves, exports to your accounting. Manual re-keying alone doesn't cut it.

Verifactu and accounts payable: why it forces a rethink of invoice automation