Conceptual guide / Operations
No response does not mean rejected.
An integration must distinguish what it knows from what it cannot yet confirm. That distinction determines whether to retain evidence, query, correct or retry.
By Kenea · Editorial review: .
Three layers to read separately
- Transport. Is there a complete, usable response? A dropped connection or timeout leaves uncertainty; HTTP 200 alone does not establish tax acceptance.
- Submission.
EstadoEnviosummarises the batch:Correcto,ParcialmenteCorrectoorIncorrecto. - Record.
EstadoRegistrostates the individual result. The batch summary does not replace reading it.
| Official value | Meaning |
|---|---|
Correcto | Record accepted without errors. |
AceptadoConErrores | Record accepted with errors that do not cause rejection. |
Incorrecto | Record rejected; it is not registered. |
Source: AEAT web service description, §6.5.2. “Pending reconciliation” or “unknown” would be internal application labels, not values in that official catalogue.
Four decisions, grounded in evidence
1. The response is lost after submission
What we know: an attempt took place. We do not know whether the destination processed it.
Proposed design: preserve the reference, content and timeline; mark the uncertainty and reconcile through the service’s mechanisms. If querying cannot resolve the case, follow a documented recovery and escalation procedure. Do not automatically create another invoice to obtain a response.
2. A record is explicitly rejected
What we know: a response exists and must be associated with the correct operation.
Proposed design: distinguish rejection from a network failure, preserve the details and assign a reviewer. Repeating the same content without understanding the cause may repeat the problem. Choose the correction method according to the case and specification, not a generic “retry everything” button.
3. The record is accepted with errors
What we know: acceptance and an absence of issues are different things.
Proposed design: create a visible task with an owner, details and evidence of closure. Do not hide the warning because submission has finished. Determine with the appropriate person whether the problem concerns data, software or tax interpretation.
4. An event repeats or conflicting information arrives
What we know: two messages may refer to the same operation.
Proposed design: compare identity and content; retrieve the known result where appropriate or stop the discrepancy for review. A stable internal reference helps deduplication but does not guarantee destination idempotency or make every repetition an equivalent operation.
The question before the next attempt
Can we explain why this attempt is necessary and which operation it belongs to? In our conceptual design, each attempt would retain its reference, time, environment, reason, known result and exception owner. Timeouts and attempt frequency would be adapted to the service used; this guide sets no regulatory timers.
Human review is reserved for decisions and exceptions the policy cannot safely resolve. It does not replace the automatic operation required by the chosen mode. Never include keys or certificates in history shared for support.
Test the procedure, not just the happy path
A test plan should simulate lost responses, concurrent repetition, restarts and differing results within a batch. Each scenario needs an expected result, evidence and an owner. Until those tests are run, any result remains an expectation.
The fictional Demo ERP report places these checks within an integration decision. For the service context, see KeneaFactu and the VeriFactu guide.
Source and review limits
The AEAT technical document, version 1.0.3, dated 28 July 2025, was consulted on 8 September 2026. The catalogue above concerns creation and cancellation responses; it does not list every field or the states of other services. We do not reproduce specific error codes or provide a protocol implementation. This page’s operating proposals are Kenea’s own.