Skip to main content
VeriFactu

VeriFactu error 4102: «El XML no cumple el esquema. Falta informar campo obligatorio»

Error 4102 is the structural error par excellence: the XML received by the AEAT, the Spanish tax agency, lacks a field that the schema requires. As it is a structural failure, the AEAT rejects the whole request, with every invoice it carried. With our module you will normally see it in Odoo before anything is sent, not as an answer from the AEAT.

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

Why it brings down the whole submission

The AEAT validation document distinguishes three kinds of checks: structural, syntactic and business rules. Structural checks verify that the XML follows the schema, with its mandatory tags, and when they fail the whole message is rejected. That rejection comes back as a SOAP fault and no invoice of the request is registered, not even the correct ones.

The official list says so in Spanish: El XML no cumple el esquema. Falta informar campo obligatorio., «the XML does not comply with the schema, a mandatory field is missing». It is in the first section, the codes that reject the whole submission.

Card for VeriFactu code 4102
Code 4102 in red: it rejects the whole request and, in the module's queue, leaves the submission in Failed.

What the module does so it never gets there

A single malformed record would drag every other record of the same submission down with it. To avoid that, the module validates each record against the official AEAT schema before sending it. It carries a copy of that schema, the SuministroLR.xsd file with its dependencies, and the path is this:

  1. When the invoice is posted Its invoicing record is created, and it does not change afterwards.
  2. On the next queue run Each pending record is turned into XML and validated against the schema.
  3. If a record does not comply It is marked as rejected in Odoo with the schema message, with no AEAT code, and it does not go out.
  4. The rest Goes to the AEAT in the same request, without the bad record.

That way a defective record does not take down the good invoices travelling with it.

How you will see it in Odoo

In the submission queue, the stopped record shows in Failed with the validator's message as its last error, instead of a four-digit code. That message names the element that is missing or out of place, which is exactly what you need to know where it comes from. In the list of invoicing records its status is «Rechazado AEAT», rejected by the AEAT, even though the AEAT never saw it.

AEAT submission queue grouped by status
The queue grouped by status: the submissions in Failed are the ones that will not be retried on their own. Odoo 20 screenshot with demo data; the AEAT answers are simulated.

Even before the schema, there is data without which the module will not build the XML at all, and it tells you with its own message:

  • Company … has no NIF for Veri*Factu. when the company has no tax ID.
  • Record … has no tax breakdown (Desglose) to declare. when the record has no tax breakdown.

If the 4102 comes from the AEAT

If the answer with 4102 comes from the AEAT itself, the record passed the local validation and the AEAT rejected it with its own schema. The reasonable explanation is that the AEAT schema and the module's copy no longer match. In that case resending is pointless: write to comercial@flexigobe.com with the full answer, the Raw Response field of the queue, so we can review the schema copy.

Can I fix the data and retry?

It depends on where the data lives. The header is built on every submission from the company data at that moment: if the fault was in the name, fix it and use Retry Selected in AEAT Errors. If it was in the tax ID, fixing it is not enough, because the tax ID also went into each invoice's hash at posting and the resend comes back with 2000. If the data is in the invoice's record, a retry sends the same thing and fails again. In those two cases, write to us.

Is the invoice lost?

No. The record stays in Odoo, chained, and the queue processes pending work every 1 minute as soon as the problem is solved.

Keep reading

VeriFactu errors with the submission format: unreadable XML, UTF-8 and empty requestsVeriFactu errors on the submission format (4103, 4119, 4135 to 4138, 1100, 1251): unreadable XML, UTF-8, GET or empty requests, and how Odoo sends each submission.VeriFactu errors 4113 and 4114: too many records in the same submissionVeriFactu errors 4113 and 4114: too many records in one submission. The limit of 1000 per request, the per-block limits and how Odoo 17, 18, 19 and 20 respects them.VeriFactu error 4134: «Servicio no activo», what happens to your invoices and how to resend themWhat VeriFactu error 4134 from the Spanish tax agency means, why it rejects the whole submission and how to resend your invoices from Odoo 17, 18, 19 and 20.
Checked in the module's source code (version 20.0) and the linked sources

Sources