Skip to main content
VeriFactu

VeriFactu errors with invoices issued by a third party or by the recipient

Not every invoice is issued by the seller. Sometimes a third party issues it on their behalf, and sometimes the customer does, in self-billing. VERI*FACTU declares it with one field, EmitidaPorTerceroODestinatario, and one block, Tercero. Nine codes from the AEAT, the Spanish tax agency, check that the two fit together.

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

How it is declared

The EmitidaPorTerceroODestinatario field accepts two values, and each one makes a different block mandatory:

T, issued by a third party
The Tercero block is mandatory, with the tax ID of whoever issues the invoice.
D, issued by the recipient
The Destinatarios (recipients) block is mandatory.

The Tercero block can only appear with value T. If it is identified with a Spanish tax ID, that tax ID has to be on record at the AEAT and be different from that of the party obliged to issue the invoice. And it can never be identified with type 07, «No censado» (not in the census).

Card for the VeriFactu third-party codes
The nine codes for invoices issued by third parties or by the recipient, in amber: they reject the record.

The nine codes

CodeWhat fails
1151The field only accepts T or D.
1155There is a Tercero block without the EmitidaPorTerceroODestinatario field.
1158The field is there, but its matching block is missing.
1159The Tercero block is reported while the field says D, recipient.
1178Generic error in the Tercero block.
1186With T, the Tercero block is missing.
1187There is a Tercero block with a value other than T.
1188The third party's tax ID is the same as that of the obliged party.
1211The third party is identified with type 07.

All of them reject the record of the affected invoice; the rest of the submission carries on, and the rejected invoice remains pending correction.

What our module declares

The registration record built by the module carries neither the EmitidaPorTerceroODestinatario field nor the Tercero block. That is why none of these nine codes can come from one of its submissions. Every invoice is declared as issued by the company itself: its tax ID goes as the obliged party in the header and as the issuer on each invoice.

That covers the normal case, which is most cases: you sell and you invoice from your own Odoo. The two special cases are not reflected:

  • If a third party issues invoices in your name, for example a service company that bills for you, the module does not declare it as such.
  • If it is your customer who issues the invoices for what you sell them, under a self-billing agreement, those invoices are not born in your Odoo and the module does not send them.

If you work with either of these arrangements, write to comercial@flexigobe.com before turning VeriFactu on for those invoices.

AEAT error catalogue inside Odoo
The AEAT catalogue inside Odoo holds the nine third-party codes with their literal text, alongside all the others. Odoo 20 screenshot with demo data.

Not to be confused with the representative

A tax adviser submitting your records to the AEAT does not become a third-party issuer. The adviser submits, and that is what the header's Representante block is for; the third party issues, and that goes on each invoice. The Representante errors, from 4105 to 4124, are on their own page.

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)
1151El campo EmitidaPorTerceroODestinatario solo acepta valores T o D.
1155Se está informando el bloque Tercero sin estar informado el campo EmitidaPorTerceroODestinatario.
1158Se está informando EmitidaPorTerceroODestinatario, pero no se informa el bloque correspondiente.
1159Se está informando del bloque Tercero cuando se indica que se va a informar de Destinatario.
1178Error en el bloque de Tercero.
1186Si EmitidaPorTercerosODestinatario es igual a T el bloque Tercero será de cumplimentación obligatoria.
1187Sólo se podrá cumplimentarse el bloque Tercero si el valor de EmitidaPorTercerosODestinatario es T.
1188El NIF del bloque Tercero debe ser diferente al NIF del ObligadoEmision.
1211El bloque Tercero no puede estar identificado con IDType=No Censado (07).

What if I see one of these codes with Odoo?

It should not happen with a submission from the module. If you get one, send us the answer of the submission: it would mean something else is sending with your tax ID.

Keep reading

VeriFactu errors with the optional fields: Macrodato, Cupon, simplified invoices and agreementsVeriFactu errors on the optional fields: Macrodato, Cupon, FacturaSimplificadaArt7273, Art61d, billing agreement and RefExterna, and which ones Odoo sends.VeriFactu errors 1189, 1190, 1191 and 1192: invoice type and recipient have to matchVeriFactu errors that cross the invoice type with the recipient (1189, 1190, 1191, 1192, 1106 and 1156): the AEAT rule and what Odoo decides when an invoice is posted.VeriFactu errors with your company tax ID: 4104, 4107, 4109, 4115, 4116 and the IDEmisorFactura familyVeriFactu errors on the issuer tax ID (4104, 4107, 4109, 4115, 4116, 1108, 1215…): what the AEAT checks, which Odoo field it comes from and how to resend the submission.
Checked in the module's source code (version 20.0) and the linked sources

Sources