---
name: verifactu-subsanacion-decidida
description: La laguna de diseño "cómo corrige el SIF un registro rechazado" se cerró el 2026-08-29 con núcleo D15 + transporte D5; qué se decidió y qué quedó anotado para otros agentes
metadata:
  type: project
---

El 2026-08-29 se cerró el hueco de la **subsanación** (corregir un registro, distinto de anular la factura y distinto de una re-alta duplicada). Quedó escrito en `add-sif-nucleo-registro/design.md` **D15** y `add-sif-transporte-aeat/design.md` **D5**, con specs y tasks actualizadas en ambos.

**Why:** ni D13 del núcleo ("toda corrección es un registro adicional posterior") ni D2 de `add-sif-controles-integridad` (bloqueo en cabeza + escalado a 4 h) decían qué operación ejecuta la persona. Faltaba la continuación de ambas.

**How to apply:** antes de reabrir nada de subsanación, leer D15/D5 — están trazadas a fuente oficial (✅), no son interpretación. Los cuatro pilares:
1. La clave NIF+NumSerie+FechaExpedicion identifica a la **factura**, no a la fila de registro (una factura acumula alta inicial + N subsanaciones + anulación).
2. Re-alta y subsanación se distinguen **por la puerta de entrada**, no por el estado.
3. La consulta a la AEAT es **precondición** de construir la subsanación, no comprobación; respuesta `Anulado` → negativa incondicional (subsanar reactivaría la factura anulada).
4. La subsanación nunca es automática: el SIF la prepara, una persona la autoriza.

**Pendiente señalado y no tocado:** D2 de `add-sif-controles-integridad` sigue sin nombrar la subsanación como la salida del bloqueo. Es un matiz de una frase; se avisó al orquestador en vez de editarlo.

Ver [[verifactu-arquitectura-fronteras]].
