Skip to main content
VeriFactu

VeriFactu error 2007: the AEAT already had your invoices and receives another «first record»

All VERI*FACTU invoices are chained, and the first one in the chain is flagged as the first record. Error 2007 appears when another record arrives with that flag while the AEAT, the Spanish tax agency, already holds invoices from the same issuer made with the same software. The invoice gets in, but the AEAT warns that the chain has been started twice.

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

The text and its section

The AEAT writes it like this: «No debe informarse como primer registro, existen facturas emitidas con el obligado emisión y el sistema informático actual.» In English: it must not be flagged as the first record, because invoices from this issuer with the current invoicing system already exist. It belongs to the section of errors that accept the record and ask for a correction. The validation document lists it among the admissible errors: PrimerRegistro set to S when there are already records for that system and that tax ID.

Card for VeriFactu code 2007
The 2007 card: blue, like the other errors where the AEAT registers the invoice and asks for it to be fixed later.

When Odoo flags a first record

Every record carries an Encadenamiento (chaining) block. The module fills it in one of two ways:

  • If the record has no previous hash, it sends PrimerRegistro set to S. That happens with the first record of that company's chain in that Odoo database.
  • In any other case it sends RegistroAnterior, with the tax ID, number, date and hash of the record before it.

The chain lives in the database: each company has one, and the module identifies each installation with its own NumeroInstalacion, computed from the database and the company. A new database starts its chain from scratch, and its first invoice goes out as a first record.

Chain state in Odoo with the record that opened it
The chain status shows, at the bottom, the record it started with (Genesis Record) and the last hash. Odoo 20 screenshot with demo data.

What is usually behind it

Error 2007 tells you that, as far as the AEAT knows, this issuer had already sent invoices with this same software before the chain you are using began. These are the questions worth asking:

  1. Have invoices of this company been sent from another Odoo database with the same module and to the same AEAT environment? A test copy configured for Production, for example.
  2. Did you switch databases halfway, through a migration or a restore, so that the new one started its own chain?
  3. Is the Genesis Record shown in Chain State the invoice you expected to be the first one?

If any answer is yes, there are two chains for the same issuer, and it is worth stopping it before you keep invoicing from both. Every new invoice coming out of the second chain will be linked to its own start, not to the first chain's, and the mismatch carries over.

How to close it

The invoice with the 2007 is registered. In Odoo it shows as «Aceptado con errores (subsanar)», accepted with errors to be corrected, and the AEAT asks for a correction through a new record with the same invoice identifier. The published module does not send correction records on its own, so write to comercial@flexigobe.com with the company name, the Genesis Record and the databases that have been sending invoices: we will sort it out with you.

For the other chaining codes, such as a badly filled previous record or hashes with the wrong length, see the chaining page.

Keep reading

VeriFactu chaining errors: the previous record, the hashes and their lengthsVeriFactu chaining errors (1174, 1175, 1180, 1269, 1291, 2002, 2003, 2008 and the length codes): what the AEAT checks and how Odoo chains each invoicing record.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 3000: the AEAT already has that invoice on recordVeriFactu error 3000 means the Spanish tax agency already has that invoice. When it happens, which status comes back and why Odoo 17, 18, 19 and 20 does not resend it.
Checked in the module's source code (version 20.0) and the linked sources

Sources