VERI*FACTU
Linked SHA-256 hash, QR code on every invoice and submission to the AEAT using your certificate. Ready to go.
VERI*FACTU · E-invoicing · RD 1007/2023 · RD 238/2026
Verifactu and e-invoicing
One complete solution to issue, send, receive and stay compliant. Every invoice is registered with the AEAT (Spanish Tax Agency) using a hash and QR code, sent to your customer electronically, and supplier invoices are imported automatically with their payment statuses.
Updated 15 October 2026 with the BOE (Spain’s Official State Gazette) and Tax Agency guidance.
Verifactu and e-invoicing software: what you get
All in your ERP, with no extra software or platform to learn.
Issue invoices in UBL
Invoices are issued as signed UBL files, with an exact copy sent to the AEAT’s public solution.
Receive UBL and Facturae invoices
Supplier invoices are automatically converted into supplier bills, with no manual data entry.
Statuses and payments
Track acceptance, rejection and payment for every invoice, with an alert for the four-day deadline set by the rules.
Ecuador: SRI
If you also invoice in Ecuador, electronic receipts are authorised by the SRI from the same ERP.
What is Verifactu and what does it require?
VERI*FACTU is the Spanish Tax Agency’s invoicing control system. It was introduced by Law 11/2021 on preventing and combating tax fraud. Royal Decree 1007/2023 sets the technical requirements for software. Order HAC/1177/2024 adds the detail: record format and content, deadlines and even QR code size.
The rules have one simple aim: no invoice can be altered, deleted or hidden once issued.
Here’s the point few people mention. The rules don’t require you to fill in anything new. They require your invoicing software to do it. If your software doesn’t link records, submit them and print the QR…
Three requirements. All three, or none
There’s no partial compliance. Software that links records but doesn’t submit them, or submits them without a QR code, doesn’t partly comply: it doesn’t comply.
Linked digital hash
Every invoice has a unique hash calculated from its tax data and the previous invoice’s hash. Change a detail in a registered invoice and the chain no longer matches. Integrity doesn’t depend on anyone’s goodwill: it depends on the maths.
Verifiable QR code
Every document includes a QR code linking to the AEAT’s online checker. Your customer, accountant or inspector can check that the record is there.
Submission to the AEAT
Records are sent to the Tax Agency immediately on validation or later in batches. No exports, manual uploads or reminders for someone to send them.
Penalties: what’s at stake if your software isn’t compliant
The risk isn’t just a headline about fines. It’s real, easy to miss and likely to surface in an inspection.
Invoices issued but never registered. A broken hash chain because two simultaneous validations clashed without warning. A QR code below the minimum size set by the Order. A Tax Agency rejection nobody saw because the system didn’t show it anywhere. You won’t spot these things in the invoicing screen. You’ll find them when it’s too late to fix them, with retrospective impact on everything issued since.
That’s why the rules ask something many software makers would rather avoid: the…
How our Verifactu software works under the hood
This isn’t a list of promises. It’s what the code does, and you can see and check every point in a demo.
SHA-256 hash, exact format
Eight fields, in the order set by the rules: issuer’s tax ID, serial number, issue date, invoice type, total tax, total amount, previous hash and date/time with time zone. Uppercase hexadecimal, as required. Cancellations use their own five-field format, as the rules specify.
One continuous chain, not one per series
The previous link is the entity’s latest submitted record, not the latest in its series or the current month. The first-record marker is “S” only when no earlier record exists. That’s the difference between a chain and a pile of fragments.
A real concurrency lock
Two invoices validated in the same second can’t read the same previous link. The entity’s chain is locked before reading and always unlocked afterwards. All five submission routes use it: invoice validation, batch submissions, manual retries, the POS hook and the scheduled task.
Rejections don’t use up a link
If the AEAT returns an error or the network goes down, the chain doesn’t move on. A retry starts from the same previous hash. That’s the difference between retrying and rebuilding the chain.
Authenticated submission with your certificate
HTTPS with a client certificate and peer and host verification enabled. Exactly two environments: production and the AEAT’s official sandbox. One setting switches submissions, cancellations and queries together, so you’re never half in testing and half live.
XML validated against official schemas
The AEAT’s XSDs and WSDL are included in the module. XML can be validated before sending, with the parser’s network access disabled. Structural errors show up here, not in a rejection.
Full traceability for every submission
The exact XML sent, raw AEAT response, status, secure verification code and timestamp are stored against the invoice. Every exchange also gets an audit log with its direction, code and message. When you need to prove something, you have the document, not just a memory.
30 mm QR code on any template
The QR code is stamped onto the generated PDF, after the document generator. It works with standard and custom templates without changing them. At 30 mm square, it meets the Order’s minimum; the four-module quiet zone is calculated from each invoice’s actual QR code. POS receipts have the QR embedded in the document itself, so they print even without an internet connection.
Catch errors before rejection
Before submission, the module checks the format and check digit of each DNI, NIE or CIF, as well as the tax name, using the same tax-ID lookup as the submission process. What’s checked is what’s sent. If the AEAT still rejects it, you see a plain-English error, its code and a direct route to correct the customer record.
At a glance
- SHA-256Hash algorithm for each record, linked…
- 8 fieldsIn each new-record hash, in the order…
- 30 mmQR code size: the minimum under Order…
- 8 typesF1, F2, F3 and R1 to R5, classified…
- 5 routesSubmission routes, all using the same…
- HourlyAutomatic retries for pending records…
- 1.a–1.lResponsible declaration sections…
Your day-to-day: five steps, four of them handled for you
Validate the invoice
The only thing you do differently is nothing. Create the invoice as usual and click VALIDATE. At the POS, take payment. After that, there’s no “send to the Tax Agency” button to forget.
The hash is calculated
The module takes the tax details, reads the latest link in your chain and creates the hash with the date, time and time zone. It locks the chain so simultaneous invoices can’t share a link.
It’s sent to the AEAT
The record is sent using your authenticated certificate. If auto-send is on, it goes immediately. You can switch it off separately for invoices and POS receipts and send them in batches: the rules allow delayed submission.
The response is saved and the PDF sealed
The status, secure verification code, time and full response are attached to the invoice. The PDF is regenerated with the QR code and a link to verify it on the AEAT website.
If something goes wrong, nothing is lost
Network outage, unavailable AEAT, customer details the Agency won’t accept: the invoice is still validated, its hash is calculated and linked, and the record stays pending. It retries automatically every hour, or you can trigger a retry from Resubmissions. An error doesn’t use up a link.
Eight document types, classified automatically
The rules distinguish between document types, each with its own registration process. Nobody needs to choose from a dropdown: the module works it out from the invoice source and content.
Standard invoice
A customer identified by full tax details. The usual invoice for a business or professional customer.
Simplified invoice
Generated by TakePOS at checkout. No recipient details are needed, and the QR code prints on the receipt.
Replacement for simplified invoices
When a customer asks for a full invoice after paying with a receipt. Groups multiple F2s, imports their lines and tells the AEAT which receipts it replaces.
Correction for a legally valid reason
Errors in recipient details, tax charged or other legally justified errors.
Correction due to insolvency proceedings
For the recipient. As with any correction, choose replacement or difference; the module follows your choice or works it out from the amounts if you don’t specify.
Correction for bad debts
Debts that won’t be paid. As with R2, you choose how to correct it, and the record includes the corrected amounts required by the AEAT.
Correction for other reasons
Cases that don’t fit the three types above. Supports replacement or difference, like the others.
Correction of a simplified invoice
Assigned automatically when the original invoice was an F2 receipt, so nobody has to remember to select it.
What you and your accountant can see
Internal compliance is no use if nobody can check it. These are the screens used by the people who issue invoices and manage your taxes.
Validated but pending
The list nobody wants but everyone needs: validated invoices the AEAT hasn’t accepted yet. Not registered, queued or in error. All on one screen, no need to search one by one.
Resubmissions
All pending and rejected records, with the AEAT’s specific message on each line. Submit individually or in bulk. Long batches run within a time limit: if it’s nearly reached, the module tells you how many remain instead of failing silently.
Check the actual status
Ask the AEAT what it has recorded for an invoice you’ve sent, from the list without leaving your ERP. Settle a query in 30 seconds.
Exports for your accountant
Sales, purchases and quarterly reports by customer, with taxable amount, VAT, total, document type and payment status. CSV with a UTF-8 marker so Excel preserves accents, plus PDF attachments.
True multi-entity support
Records and chains are separated by company. Multiple companies in one installation, each with its own chain, certificate and separate data.
Protected certificate
Accepts FNMT certificates in all three formats and converts them as needed. The password is encrypted with AES-256-GCM and a key derived from your installation: never stored in plain text. Every module action checks permissions, session token and entity.
A responsible declaration, not a “Tax Agency seal”
Let’s be clear, because plenty of adverts claim otherwise: the AEAT does not certify or approve invoicing software. There’s no official seal or public register. Instead, the software producer signs a responsible declaration under Article 15 of Order HAC/1177/2024. If someone sells you “Tax Agency-certified software”, they’re describing something that doesn’t exist.
Ours covers every section from 1.a to 1.l and is available as a PDF from the module. It names the system, its two-character code registered with the AEAT and the exact declared version. It also names who is responsible: BITCAR…
And e-invoicing? Two separate requirements
Two separate requirements. Regifactu covers both in one module.
VERI*FACTU
What it covers: how your software records each invoice. Rules: Law 11/2021 and RD 1007/2023. For: the AEAT. Requires: linked hash, QR code and record submission. Invoice format: any format (your usual PDF is fine). Aim: prevent fraud. Covers: all your invoices, including receipts and sales to consumers.
E-invoicing
What it covers: how invoices reach your customer. Rules: Law 18/2022 and RD 238/2026. For: your customer and the AEAT. Requires: structured format, a copy for the public solution, statuses and payment details. Formats: UBL, CII, EDIFACT or Facturae. Aim: tackle late payment. Covers: invoices between businesses and sole traders only.
From Verifactu to mandatory e-invoicing: one module
VERI*FACTU is the first step: every invoice is fully registered with the AEAT. The second is mandatory e-invoicing between businesses (the “Create and Grow” Law): invoices reach your customers as signed data, with acceptance and payment statuses, and supplier invoices arrive automatically. It starts in October 2027 for large businesses and October 2028 for the rest.
With Regifactu, there’s no extra software or setup: it’s an upgrade to this module. The same certificate, submission queue and validation button; invoices are issued in UBL, the format required by the AEAT public platform.…
Verifactu FAQs
When does Verifactu become mandatory?
As things stand, it depends on how you’re taxed: companies subject to Corporation Tax must use compliant software by 1 January 2027; sole traders and permanent establishments of non-residents by 1 July 2027. These dates are set by Royal Decree-Law 15/2025 of 2 December. On 5 October 2026, the Ministry of Finance announced plans to move everything to October 2028, but until that appears in the BOE, the legal deadline remains in 2027. Our module is already compliant, so the date only tells you how long you can wait.
What changes for sole traders under Verifactu?
The same as for a company, but with a different deadline: if you pay income tax under IRPF, your invoicing software must comply by 1 July 2027 (Royal Decree-Law 15/2025). There’s nothing to file with the Tax Agency: the software links each invoice, sends it and adds the QR code. If you invoice with us, it’s already done.
What are the penalties if my software isn’t Verifactu-compliant?
The General Tax Law (Article 201 bis) sets a €50,000 fine per tax year for using non-compliant invoicing software, and €150,000 per year for making or selling it. Ask your provider for its responsible declaration before signing up.
Has VERI*FACTU been postponed to 2028?
It’s been announced, not approved. On 5 October 2026, the Ministry of Finance published an information note proposing to postpone outstanding obligations under Royal Decree 1007/2023 until October 2028, aligning them with mandatory e-invoicing for businesses and sole traders with turnover below €8 million. Until the change is published in the BOE, the current deadlines remain 1 January and 1 July 2027. We’ll update this page with the exact date once the law is published.
How does VERI*FACTU relate to mandatory e-invoicing?
They’re separate requirements that are due to arrive together. VERI*FACTU governs how your software records and submits each invoice (hash, QR code and submission to the AEAT). Mandatory e-invoicing between businesses (Law 18/2022, “Create and Grow”) requires invoices to be issued and received in a structured electronic format. The timetable was set by Order HAC/1028/2026: October 2027 for businesses with turnover over €8 million and October 2028 for the rest. The Ministry’s announcement aims to bring both in at once for SMEs and sole traders, so you don’t have to adapt twice. Our module already covers VERI*FACTU; we’re preparing e-invoicing on the same foundation.
Do I need to do anything each time I issue an invoice?
No. Once your certificate and operating mode are set up, everything happens when you validate an invoice or take payment at the POS: the hash is calculated, the record is sent and the document is sealed with a QR code. If your provider answers “it depends”, the system isn’t set up properly.
What if the connection to the AEAT goes down as I validate?
The invoice is still validated. Its hash is calculated and linked, and the record remains pending. It retries automatically: the module installs its own scheduled task, set to run hourly by default. You can also trigger a submission from Resubmissions. Because an error or rejection doesn’t use up a link, the retry starts from the same previous hash and the chain stays intact.
Do I have to submit in real time?
No. The rules allow delayed submission. You can switch off auto-send separately for invoices and POS receipts and submit them in batches when you prefer. We recommend sending immediately for a practical reason: a problem found today takes five minutes to fix; one found at quarter-end doesn’t.
Can I test it without contacting the live AEAT?
Yes, using the Tax Agency’s official test environment. You need a company certificate, and test records have no legal effect. The module has exactly two environments: production and this sandbox. One setting switches submissions, cancellations and queries together. There’s no halfway state where you think you’re testing while something goes live.
What exactly is a linked hash?
A SHA-256 hash calculated from eight specific fields, in the order set by the rules: issuer’s tax ID, serial number, issue date, invoice type, total tax, total amount, previous record’s hash and date/time with time zone. Change a cent on a registered invoice and its hash changes, along with the hashes of every invoice after it. That’s why integrity shouldn’t depend on how much you trust your provider.
Can I correct or cancel an invoice already submitted?
You can’t change it, but you can correct or credit it. The module issues R1–R5 corrections and credit notes. Choosing replacement or difference is up to you—the AEAT says so—and the module respects your choice for every type instead of imposing a rule the regulations don’t. For replacements, it adds only the corrected taxable amount and tax required by the Agency, commonly missing from rejected submissions. A cancellation is a separate linked record with its own hash, leaving an audit trail. Cancelling twice is blocked on the server, not by a hidden button: the second cancellation never reaches the AEAT or uses up a link.
The POS customer has no tax ID. Is that a problem?
No. TakePOS receipts are simplified invoices and don’t need recipient details. The QR code is embedded in the receipt, so it prints even if the terminal has no internet connection. If the customer later asks for a full invoice, an F3 is issued to group and replace those receipts, and reported to the AEAT.
Can I use my FNMT certificate?
Yes, in all three standard formats: native .p12 or .pfx, .pem with certificate and key together, or separate .crt.pem and .key.pem files. The last two are converted automatically, so you don’t have to wrestle with OpenSSL. The password is encrypted with AES-256-GCM using a key derived from your installation ID: it’s never stored in plain text.
Does the QR code appear on every document?
On every document required by the rules: invoices and corrections in their PDF when validated, and POS receipts when printed. It’s stamped onto the generated PDF, so it works with standard and custom templates without changing them. It’s 30 mm square, the Order’s minimum, with the quiet zone calculated from each invoice’s actual QR code. It links to the AEAT online checker with the tax ID, serial number, date and amount. It confirms the record exists; it doesn’t display the document.
What does it run on?
It’s software-only, with no dedicated hardware, and runs on PHP and a database. Exact technical details are in the responsible declaration, available to download on this page and filed with the AEAT.
Part of your business management
The module is part of Regifactu and works with the rest of the platform:
Tell us how you invoice and we’ll show you what’s missing
Half an hour is enough to review your situation: the document types you issue, whether you use a POS, the state of your customers’ tax details and exactly what happens when you validate an invoice today. You’ll leave with an assessment, not a generic quote. If your invoices include exempt or out-of-scope transactions, tell us in the first minute: we need to review those cases individually before making any promises.