Skip to main content
VeriFactu

Correcting a VeriFactu record: how it works and the Subsanacion and RechazoPrevio errors

In VERI*FACTU a record is never edited or deleted: if it was wrong, you send another one with the same invoice identifier that corrects it. The AEAT, the Spanish tax agency, calls this «subsanación», correction, and flags it with two fields, Subsanacion and RechazoPrevio. This page explains when a correction is due, how the two fields combine and the seven codes that appear when they do not fit.

FlexigoTech · Editor in charge: Víctor Gómez · Updated 4 November 2026

Key facts

Module
VeriFactu
Versions
Odoo 17, 18, 19 and 20
Checked
in the module's source code, version 20.0 · against the sources linked at the end
Reading time
3 min

When a correction is due

The AEAT validation document provides for a correction in three situations:

  • The record was accepted with admissible errors, the 2xxx codes. Two exceptions need no correction: an empty ClaveRegimen with IPSI, and a generation timestamp ahead of the AEAT clock.
  • The record was rejected. In voluntary submission, rejected records have to be sent again in a new submission, correcting the error.
  • You later find wrong data in a record that was accepted without errors.

A correction is not possible when the cause requires issuing a corrective invoice. A correction fixes a record; it does not replace a corrective invoice.

Card for the VeriFactu correction codes
The seven codes on this page: in amber those of Subsanacion and RechazoPrevio and, next to them, 3003 and 3004.

The four ways of registering a record

The AEAT annex of admissible operations combines both fields like this:

OperationSubsanacionRechazoPrevioWhen
Initial registrationN or emptyN or emptyThe invoice does not exist yet at the AEAT.
Registration after rejectionSXCorrects an initial registration that was rejected, so the AEAT does not have it.
Correction registrationSN or emptyCorrects a record the AEAT already has.
Registration after a rejected correctionSSRepeats a correction that was rejected.

The codes of this family

CodeWhat fails
1153RechazoPrevio X without Subsanacion S.
1161RechazoPrevio S without Subsanacion S.
1171Subsanacion or RechazoPrevio with a value outside the list.
1275Wrong value in RechazoPrevio.
1276Wrong value in SinRegistroPrevio.
3003The submitter lacks the permissions to update this invoicing record.
3004The invoice cannot be changed because it was registered through the AEAT form.

3003 appears when whoever submits the correction is not allowed to update that record, and 3004 when the original invoice was registered through the AEAT's own web form rather than from an invoicing system.

What our module does today

The registration record built by the published module carries neither Subsanacion nor RechazoPrevio: all its registrations are initial registrations. That is why these codes do not come from its submissions, and also why:

A rejected record (1xxx)
The queue retries it with the same data, because the record does not change once posted, and on the sixth attempt leaves it in Dead Letter. No retry turns it into a registration after rejection.
A record accepted with errors (2xxx)
It stays as «Aceptado con errores (subsanar)». The module does not send the correction.

That is the first thing to know: in Odoo, with the published module, correcting a VERI*FACTU record is not automatic.

Invoicing records in Odoo with accepted and accepted-with-errors statuses
In the list of records, those accepted with errors stay flagged for correction. Odoo 20 screenshot with demo data; the AEAT answers are simulated.

What to do in the meantime

  1. Do not cancel the invoice to try to fix it: cancelling creates a cancellation record, which is chained and sent, but does not correct the previous record.
  2. Fix the source data in Odoo, whether the contact, the tax or the journal, so that the next invoices go out right.
  3. Write to comercial@flexigobe.com with the affected records and their answers. We will prepare with you the correction that fits each one.

The codes on this page, with the AEAT's text

Each code with its literal text, in Spanish, as the AEAT's error list gives it:

CodeAEAT text (Spanish)
1153Valor del campo RechazoPrevio no válido, solo podrá incluirse el campo RechazoPrevio con valor X si se ha informado el campo Subsanacion y tiene el valor S.
1161El valor del campo RechazoPrevio no es válido, no podrá incluirse el campo RechazoPrevio con valor S si no se ha informado del campo Subsanacion o tiene el valor N.
1171El valor del campo Subsanacion o RechazoPrevio no se encuentra en los valores permitidos.
1275Valor incorrecto campo RechazoPrevio
1276Valor incorrecto campo SinRegistroPrevio
3003El presentador no tiene los permisos necesarios para actualizar este registro de facturación.
3004No es posible modificar la factura ya que ha sido dada de alta vía formulario.

Keep reading

VeriFactu error 2000: the AEAT recalculates your hash and it does not matchVeriFactu error 2000: the Spanish tax agency recalculates the SHA-256 hash and gets a different one. Why the invoice is registered anyway and what to do in Odoo 17 to 20.VeriFactu error 2001: your customer's tax ID is not in the AEAT censusVeriFactu error 2001: the recipient's tax ID is not in the AEAT census. Why the invoice is accepted anyway and what to do in Odoo 17 to 20.VeriFactu errors 3001 and 3002: cancelling an invoice the AEAT does not have, or already cancelledVeriFactu errors when cancelling: 3001 (already cancelled), 3002 (does not exist) and the Generador block. What Odoo 17, 18, 19 and 20 does when you cancel an invoice.
Checked in the module's source code (version 20.0) and the linked sources

Sources