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.
