Read an AEAT rejection
An error code is not the end of the world. We explain what the most common rejections mean, how they are fixed and what Cofactu repairs for you.
- Category
- Compliance
- Level
- Intermediate
- Time
- ≈ 10 min
- Steps
- 5
- Updated
- July 2026
Before you start.
What you are about to solve.
When you send an invoice to the AEAT (Spanish Tax Agency), its system replies with acceptance, acceptance with incidents or rejection, each with a code. The code tells you exactly what fails: a badly formed field, a NIF that does not exist, a problem in the hash chain or a temporary service incident. Most are solved in a minute once you know what they check.
Cofactu translates those cryptic codes into plain language and, when the problem has an automatic fix (such as a broken hash chain), repairs it without you touching anything. This guide gives you the map of the most frequent rejections and what to do with each.
The general rule: a rejection means the invoice has not been registered at the AEAT, so you have to correct and resend; an acceptance with incidents does register, but it is worth reviewing the warning.
Do it in order.
Open only the step you are on.
5 steps to review, issue and leave the document ready, without reading a whole guide at once.
-
Find the code and its explanation
Step 01: Find the code and its explanation
In Invoices → Errors you will see each invoice with a problem next to its AEAT code and a plain-language explanation of what it means. Cofactu keeps a catalogue of the most common errors (families 1xxx, 41xx, 5xxx) with cause and solution, so you do not have to look the code up in the official documentation.
-
Data errors (families 1xxx and 2xxx)
Step 02: Data errors (families 1xxx and 2xxx)
These are the most frequent and the easiest: an empty required field, a NIF with the wrong format, an inconsistent date or an amount that does not match the base and the tax. The AEAT validates the content of the record. Correct the data point flagged on the invoice and resend.
- Customer NIF non-existent or badly formed → check the NIF on the customer's record.
- Inconsistent amount/base/tax → recalculate the lines.
- Wrong invoice type for the case → adjust F1/F2/R1-R5.
-
Chain errors (error 4171 and similar)
Step 03: Chain errors (error 4171 and similar)
The 41xx family has to do with chaining: the AEAT expects your invoice's hash to link to the previous record in the series, and if it detects a jump it rejects it. It usually happens after a half-failed submission or a retry. Cofactu detects the break and repairs the chain automatically, re-chaining the affected records before resending.
-
Service errors (family 5xxx)
Step 04: Service errors (family 5xxx)
5xxx codes are usually temporary incidents on the AEAT side (service overloaded or under maintenance), not a problem with your invoice. The right strategy is to retry later, not to modify the invoice. Cofactu requeues and retries these submissions for you with progressive back-off.
-
Correct and resend
Step 05: Correct and resend
For data errors, correct the field and press resend: a new attempt is generated with the corrected record. For chain and service errors, in most cases Cofactu is already retrying. When the AEAT accepts, the invoice moves to accepted and receives its CSV (código seguro de verificación, secure verification code), which is the proof of registration.
When you finish you will know how to read any AEAT rejection, tell a data error (which you correct) from a chain or service one (which Cofactu repairs), and have your invoices accepted with their CSV as proof of registration.
The questions that come up
when you put it into practice.
Can an AEAT rejection lead to a penalty?
The rejection itself is not a penalty: it means that record has not entered and has to be corrected. The penalty risk comes from not keeping invoicing compliant systematically (non-verifiable software, not keeping records), not from a one-off rejection that you correct. That is why it is better to resolve them, not accumulate them.
What is error 4171?
It is a chaining error: the AEAT detects that your invoice's hash does not link correctly to the previous record in the series, normally after an interrupted submission. Cofactu detects the break and repairs the chain automatically, re-chaining and resending without you having to intervene.
Do I resend or does Cofactu?
It depends on the error. Data errors you correct yourself (change the field and resend). Chain errors (41xx) and service errors (5xxx) Cofactu retries automatically. The Errors page tells you in each case whether your action is needed.
How do I know an invoice was properly registered?
When the AEAT accepts it, the invoice receives a CSV (secure verification code) and moves to accepted status in Cofactu. That CSV is proof that the record entered the AEAT and allows the invoice to be checked on its portal.
Continue from here.
Without losing context.
Related to this task
More Cofactu guides
Compliance≈ 6 min · Beginner How to digitise invoices and what the AEAT requires Digitising expense invoices with OCR is legal and lets you deduct them, but only certified digitisation with approved software lets you throw the paper away. What to keep and for how long. Open the guide → 
Compliance≈ 15 min · Intermediate How to authorise your accountant at the AEAT (step by step) How to grant a power of attorney (apoderamiento) on the AEAT portal so your accounting firm can file on your behalf, which type to choose and how to track its expiry with Cofactu alerts. Open the guide → 
Tax≈ 15 min · Intermediate How to file the Modelo 303 VAT return (step by step) Guide to filing the quarterly Modelo 303 VAT return in Spain with Cofactu: how it is calculated from your VAT book, which boxes to check, deadlines and how to generate the file for the AEAT. Open the guide → 
