Documentación

Anulaciones y subsanaciones

En Verifactu nada se borra: la cadena de huellas es inmutable. Corregir lo ya registrado se hace añadiendo nuevos registros. Hay tres herramientas y conviene distinguirlas bien, porque tienen efectos fiscales distintos.

Situación	Herramienta
La factura no debió emitirse (venta que no existió, factura de prueba en producción…)	Anulación — `POST /v1/cancel`
El registro tiene un error formal pero la factura es válida (dato mal informado hacia la AEAT)	Subsanación — `PUT /v1/modify`
La operación cambió: descuento, devolución, error en importes con efectos en IVA	Factura rectificativa — `POST /v1/create` con `tipo_factura R1–R5` (ver Enviar facturas)

Anulación

POST/v1/cancel

Genera un registro de anulación que se encadena y se remite a la AEAT igual que un alta. La factura original queda anulada a efectos del reglamento, pero su registro permanece en la cadena.

POST /v1/cancel
Authorization: Bearer $FACTUBRIDGE_API_KEY
Content-Type: application/json
Idempotency-Key: anu-84213

{
  "serie": "A",
  "numero": "2026-0001",
  "fecha_expedicion": "01-10-2026"
}

{
  "uuid": "c4d19a5e-8b2f-4e7a-b1c3-6d0f9e2a8b44",
  "estado": "Pendiente",
  "huella": "7F1E9A2B3C4D5E6F..."
}

La factura se identifica por su clave natural: serie, numero y fecha_expedicion.
La respuesta incluye la huella del registro de anulación, encadenada con el resto.
Anular una factura ya anulada o inexistente devuelve un error 4xx descriptivo.
La cabecera opcional Idempotency-Key hace el reintento seguro: si la respuesta se pierde por red, repetir la llamada con la misma clave devuelve el registro de anulación ya creado (con su estado actual) en lugar de intentar una segunda anulación, que volvería rechazada por la AEAT. Recomendamos derivarla del identificador local del alta que anulas, p. ej. anu-84213 — ver la guía de idempotencia.

Subsanación

PUT/v1/modify

Emite un registro de subsanación: un nuevo registro de alta con los datos corregidos que se marca ante la AEAT como subsanación del anterior. Se usa cuando la factura entregada al cliente es correcta pero el registro remitido contenía un error (por ejemplo, un NIF de destinatario mal tecleado que la AEAT devolvió como «aceptado con errores»).

PUT /v1/modify
Authorization: Bearer $FACTUBRIDGE_API_KEY
Content-Type: application/json
Idempotency-Key: sub-84213

{
  "serie": "A",
  "numero": "2026-0001",
  "fecha_expedicion": "01-10-2026",
  "descripcion": "Servicios de consultoría — octubre 2026 (corregida)",
  "tipo_factura": "F1",
  "nif": "B87654321",
  "nombre": "CLIENTE EJEMPLO SL",
  "lineas": [
    {
      "base_imponible": "1000.00",
      "tipo_impositivo": "21.00",
      "cuota_repercutida": "210.00"
    }
  ],
  "importe_total": "1210.00"
}

El cuerpo es el mismo que el de /v1/create: se reenvía la factura completa con los datos ya corregidos, identificada por la misma clave serie + numero + fecha_expedicion.

Aquí la cabecera opcional Idempotency-Key importa más que en ningún otro endpoint: subsanar dos veces la misma factura es legítimo (puedes corregirla de nuevo), así que el servidor no puede distinguir por sí solo un reintento de una corrección nueva. Con clave, el reintento con el mismo cuerpo devuelve el registro de subsanación ya creado — con su estado actual y la cabecera Idempotent-Replayed: true — en lugar de emitir una segunda subsanación. Recomendamos derivarla del identificador local del registro que subsanas, p. ej.sub-84213: laguía de idempotenciaexplica la receta completa.

Regla práctica: si el error afecta a lo que el cliente tiene en la mano o a las cuotas de IVA, es una rectificativa. Si solo afecta a lo que se informó a la AEAT, es una subsanación. Si la factura entera sobra, es una anulación.