Holded and Verifactu: how to receive QR-Verifactu invoices in your Holded

If you run Holded as your ERP, accounting and billing are already covered. What changes with Verifactu going into production is not what you issue: it's what you receive. More and more suppliers are sending you invoices with a Verifactu QR, which opens three new questions in the AP flow.

First: does the QR on that invoice match what AEAT says? Second: is the incoming hash the first occurrence or has it landed before? Third: do the lines the supplier is claiming match your PO and delivery note?

This article explains how a Verifactu invoice shows up in Holded, what the ERP solves by design and where an upstream layer like ininvoice fits in to close validation and three-way matching.

What is Verifactu and why is there a QR on your received invoices?

Verifactu is the verifiable invoicing system defined by Spanish Royal Decree 1007/2023 and developed in Order HAC/1177/2024. It requires invoicing software to generate, for each issued invoice, a signed invoicing record, chained to the previous one via a hash and reportable to AEAT.

In practice this means two visible things on the invoice you receive:

• A QR code printed on the PDF or attached to the XML. The QR encodes the URL of the AEAT verification service plus the key record fields: issuer tax ID, invoice number, date and total.
• A "Verifactu" mention or "Invoice verifiable on the AEAT electronic site" next to the QR when the issuer reports records in real time.

As recipient you are not required to issue under Verifactu, but you are required to accept these invoices, keep the signed document and, if you want to exercise the control the system enables, validate the QR against AEAT before paying.

How Holded shows a received Verifactu invoice

Holded integrated Verifactu in 2025 for issuance: if you issue with Holded, the system generates the QR, chains the hash and sends the record to AEAT. For receipt the logic is different because the QR is already generated by the supplier's system.

Typical flow when a Verifactu invoice enters your Holded:

1. You upload the document (PDF with QR or signed XML) from the supplier invoices tab, or you receive it via a configured mailbox.
2. Holded extracts the basic fields: issuer, tax ID, number, date, base, VAT, total. If the document carries structured XML, data is exact. If only a PDF, it depends on OCR.
3. The QR is anchored to the entry as an attachment. On the received invoice detail you can see the code and the original document.
4. The Verifactu hash is stored if the document is signed XML. For visual PDF, Holded keeps the attachment but doesn't decompose the chain hash.

Up to here, Holded does its ERP part: capture, post and keep. What it does not do by design is what follows.

What Holded does automatically

To avoid the opposite mistake — underestimating the ERP — first list what Holded already solves well without an extra layer:

• Accounting entry for the received invoice, with journal entry, operation date and calculated due date.
• Automatic VAT breakdown by applicable rate (21%, 10%, 4%, exempt, reverse charge) per the document data.
• Posting by date in the right period, aligned with your monthly close and Spanish forms 303/390.
• Attachment storage (PDF and XML) on supplier card and entry, with basic upload trace.
• Due-date alerts and payment management from the Holded treasury module.
• Reports for advisor or accountant with consolidated entries.

For an SME receiving 30 invoices a month with low formal PO volume, this is usually enough. The question changes when volume grows and Verifactu-QR suppliers appear where you want real control.

What Holded does NOT do (and you should)

Holded is an ERP. It is not an AEAT verification platform or a three-way matching engine. Four tasks fall outside the ERP and should be covered upstream:

• Validate the QR against AEAT. The Verifactu QR is validated by calling the AEAT invoice verification service with the encoded fields. Holded does not systematically make this call for every incoming invoice.
• Reconcile line by line against PO and delivery note. The ERP stores the total. If a supplier invoices you a unit price different from the agreed one or a quantity above what was received, this isn't visible in the total — it's visible in the lines. Line-by-line three-way matching is a discipline upstream of posting.
• Detect duplicates by Verifactu hash. Holded checks basic duplicates by number and supplier. The Verifactu hash provides a far more reliable dedupe key: if the hash already entered, it is the same invoicing record without ambiguity.
• Assign a risk score per supplier or invoice. Historical variance pattern, frequency of resends, supplier age, tax ID jumps: signals an ERP does not process because it is not its mission.

This is where ininvoice fits as a complement to Holded, not a replacement. Holded remains your ERP. ininvoice operates upstream of the entry, on the purchase control layer: read-only email intake, Verifactu QR validation, three-way matching, hash dedupe and risk score. When the invoice is validated and reconciled, the ready entry is exported to Holded.

Three-way matching for Verifactu invoices in Holded

Three-way matching cross-checks three documents per expense:

1. Purchase order (PO): what you ordered, at what price, in what quantity.
2. Goods receipt / delivery note: what actually arrived at the warehouse.
3. Supplier invoice — now with Verifactu QR as proof of existence vs AEAT.

The cross-check is not at header level. The total never lies, but the lines do. ininvoice compares each line of the invoice against the corresponding PO and delivery note line, with a configurable tolerance (default 2% or EUR 1.50 in OR mode per line). Matching lines are marked matched and auto-approved. Lines breaking tolerance are routed to the buyer or warehouse with the exact deviation context.

What the Verifactu QR adds to this flow is an extra guarantee: if the AEAT check confirms the record exists in the issuer's system, you rule out an invented or accidentally duplicated invoice. The subsequent reconciliation validates that it also matches what you ordered and received.

Recommended workflow: Holded + ininvoice

Concrete workflow for an SME or company with Holded already operational and growing Verifactu invoice volume:

1. Intake at ininvoice. You connect Gmail or Outlook in read-only mode. Every incoming invoice — with or without Verifactu QR — is processed at ininvoice before touching Holded.
2. Verifactu QR validation. If the invoice carries a QR, ininvoice extracts the encoded content and queries the AEAT verification service. The result (record exists / does not exist / inconsistency) is anchored to the document.
3. Dedupe by hash and by content. If the Verifactu hash already entered, the invoice is marked as duplicate and stops. If no hash, dedupe by tax ID + number + amount + date.
4. Line-by-line three-way matching. ininvoice cross-checks invoice against PO and delivery note. Matched: auto-approval. Variance: routed to buyer/warehouse.
5. Export to Holded. Only when the invoice is validated (QR ok, not duplicated, matched or with justified variance) is it exported to Holded as a ready entry: mapped supplier, suggested account, VAT breakdown, withholding tax if applicable, original attachment with QR anchored.
6. Accounting close in Holded. The Holded team keeps working as before: the entry appears in the ledger, computes in the close and is visible to the advisor, with the difference that it comes pre-validated vs AEAT and reconciled line by line.

Detailed integration coverage: ininvoice + Holded integration for accounts payable.

Quick comparison: Holded alone vs Holded + ininvoice

Task on received Verifactu invoice	Holded alone	Holded + ininvoice
PDF/XML capture and accounting entry	Yes	Yes (entry comes from ininvoice)
VAT breakdown and due date	Yes	Yes
QR stored on the attachment	Yes	Yes
QR check against AEAT service	Not automatic	Yes on every intake
Dedupe by Verifactu hash	No	Yes
Line-by-line match with PO and delivery note	No	Yes with 2% / EUR 1.50 tolerance
Supplier risk score	No	Yes
Auditable trail QR → matching → entry	Partial	Complete

Verifactu recipient checklist for Holded

1. Holded supplier master with correct tax IDs and Verifactu issuer flagged when known.
2. Clear policy on what to do if the QR doesn't validate against AEAT (hold payment, open supplier ticket).
3. Conservation of the original signed document (XML or PDF with QR) linked to the Holded entry.
4. Documented chart of accounts so the automatic account suggestion doesn't need manual correction.
5. Matching tolerances defined per expense category (default 2% / EUR 1.50).
6. Single email mailbox for received invoices (shared or alias) connected read-only to the AP layer.
7. Approvers assigned by amount limit and expense family.
8. Monthly close calendar with cutoff date for final entries in Holded.
9. Duplicate policy: how the supplier is notified when resending an already-registered invoice.
10. Internal contact point for critical exceptions (QR doesn't validate, high variance, new supplier).

Frequently asked questions

Does Holded automatically validate the Verifactu QR of a received invoice?

Holded stores the QR and document but does not systematically query the AEAT verification service per incoming invoice. QR validation as an AP practice is covered by an upstream layer.

What information does a Verifactu QR contain?

The URL of the AEAT verification service plus issuer tax ID, invoice number, issue date and total. Reading it redirects to the AEAT portal that confirms whether the record is registered.

Is Verifactu mandatory for me as recipient?

You don't need to issue under Verifactu just because you receive them, but you do need to accept and keep them. Recommended: validate the QR, archive the hash and keep the signed document tied to the entry.

Does Holded detect Verifactu invoices duplicated by hash?

The ERP controls basic duplicates by number and supplier, not by Verifactu hash. For strong hash dedupe, the logic lives in the upstream AP layer.

Do I need to change Holded to reconcile Verifactu invoices line by line?

No. Holded remains the ERP and accounting source. Line-by-line reconciliation is done upstream and exports the reconciled entry to Holded.

How are Verifactu invoices archived for an AEAT inspection?

The original signed document, the Verifactu chain hash and the validation trace are kept. Holded stores the attachment on the entry; the AP layer adds the AEAT verification result and the unique ID to reconstruct the auditable chain.

Three takeaways

1. The Verifactu QR on a received invoice is useful information but doesn't validate itself. Holded stores it; verification against AEAT is the recipient's responsibility.
2. Holded handles the ERP. QR validation, hash dedupe and line-by-line three-way matching are upstream layers. ininvoice covers that part and exports a reconciled entry to Holded.
3. Activation in hours, no consultant and no historical migration. Only invoices entering from today flow through — with or without Verifactu QR.

To see how this looks on top of your current Holded, see pricing, or read the complete ininvoice + Holded integration.

Related content

• Three-way matching: cross-check invoice, PO and delivery note line by line
• ininvoice + Holded integration for accounts payable
• Verifactu impact on touchless AP
• ininvoice pricing