September issue

Practical guide · VERI*FACTU

What will change in an invoice under VERI*FACTU

The QR is only the visible layer. Here is what happens when an invoice is issued, what records software creates and why correction can no longer mean overwriting an old PDF.

24.08.2026 · 9 min

NowAfter transition
IssueA PDF or record may be edited in the appAn alta record is created with timestamp and technical data
AppearanceA conventional invoice templateMandatory QR; VERI*FACTU wording only when records are sent to the AEAT
CorrectionThe file is often replacedThe original remains; a corrective invoice or formal cancellation record is created
HistoryDepends on the provider's audit logRecords are chained into a verifiable trail
AEATReceives data through returns and auditsIn VERI*FACTU it receives records automatically, not the PDF

01

An invoice and its invoice record are not the same

The client still receives a PDF, electronic document or paper invoice. At the same time the software creates a structured registro de facturación de alta.

That record contains issuer, number and series, date, invoice type, recipient where required, amounts, taxes and technical data. The record—not the visual template—must be integral, traceable and linked to its predecessor.

VERI*FACTU sends the record to the AEAT, not the branded PDF.

02

What appears on the invoice

Full and simplified invoices produced by an in-scope SIF must carry a QR code.

The wording «VERI*FACTU» or «Factura verificable en la sede electrónica de la AEAT» is used only where all records are sent to the AEAT. A non-verifiable mode still uses QR but not that wording.

The QR does not contain the entire invoice and is not a payment tool. It supports record verification or communication of essential data.

03

Issuing becomes a real boundary

An «Issue», «Finalise» or «Send» action becomes significant because it creates the alta record and separates a draft from an issued document.

Before issue, client, description and amounts can change. Afterwards, changes must use a controlled process that retains history.

Ask exactly which action creates the record: saving, downloading, emailing or explicit confirmation.

04

Correction is not overwriting

An invoice issued by mistake does not vanish. The case may require a corrective invoice, a new correct invoice or a cancellation record.

The AEAT explains that once an alta exists for an invoice issued in error, an opposite-sign record cancels it and a new correct alta may then be created.

A wrong tax ID, VAT rate, amount or non-existent transaction may require different treatment. Software should guide the route rather than offer permanent deletion.

05

What happens offline

VERI*FACTU sends records automatically and consecutively. Temporary connectivity should be handled with a queue that preserves order and retries.

Users need visible states: created, pending, accepted, accepted with warning or rejected. Sent to client is not the same as accepted by the AEAT.

Check whether rejection reasons and AEAT acknowledgements are retained.

06

Practical example

Sasha issues A-2027-0042 for €1,210: €1,000 base and €210 VAT. The system creates and links the alta, generates QR and sends the record.

The next day the client's tax ID is found to be wrong. Sasha does not replace the PDF under the same number; the correction workflow preserves the original and creates the required related records.

The result is a demonstrable sequence of issue, discovery and correction.

07

Five software tests

Test the entire lifecycle before choosing.

  • Clear boundary between draft and issued invoice.
  • QR and VERI*FACTU wording used only in the correct mode.
  • Flows for corrective invoices, cancellation, refunds and client-data errors.
  • Visible AEAT states and offline queue.
  • Export of records, acknowledgements and action history.