Subsanación de errores

La subsanación reenvía a la AEAT el registro Veri*Factu de una factura ya emitida, marcándolo como corrección (Subsanacion=S) y sin borrar el historial de registros. Sirve para arreglar un error de remisión (típicamente un bug de integración que envió datos incorrectos), no para cambiar el contenido fiscal de una factura ya entregada.

Solo procede cuando no se exige la emisión de una factura rectificativa (ni otro mecanismo contemplado en el Reglamento de Facturación): si la corrección requiere una rectificativa, ese es el camino y no la subsanación.

Operación extraordinaria

La subsanación es muy poco frecuente y no forma parte del flujo normal: solo aplica cuando la AEAT rechazó un registro por un error de remisión (casi siempre un bug de integración). No es una rectificativa ni sirve para corregir el contenido fiscal de una factura ya entregada. Si lo que quieres cambiar son importes, número o fecha, esto no es lo que buscas — es probable que quieras rectificar.

¿Subsanar o rectificar?

• Bug de integración (la factura llegó mal a Bilteo, la AEAT rechazó el registro) → subsanar: reabrir, corregir el dato y reenviar.
• Factura manual correctamente entregada pero con un dato fiscal a corregir → rectificativa (rectify).

Solo se puede subsanar una factura cuyo último registro de alta tenga respuesta firme de la AEAT: rejected, accepted o accepted_error. Con un registro pending, in-process o unknown_response la llamada devuelve invoice.fix_requires_rejected.

Dos caminos según el historial

POST /invoices/{id}/actions/request-fix decide solo qué hacer:

Historial de la factura	Qué hace request-fix
Ningún alta aceptada (el último registro está rejected)	Reabre la factura a needs_fix para que edites y vuelvas a emitir.
Algún alta aceptada (accepted o accepted_error)	La factura sigue issued e inmutable. Genera y encola en el acto una subsanación con el nombre del emisor y los datos del cliente vigentes, conservando número, fecha e importes. Devuelve la factura sin cambios; el nuevo registro aparece en GET /verifactu-records?invoice_id=….

Aceptada con errores: corrige primero el origen

Si la AEAT aceptó con errores por un dato del cliente (NIF, nombre…), edita el cliente (PATCH /partners/{id}) antes de llamar a request-fix. La subsanación toma los datos que haya en ese momento.

Flujo con reapertura (ningún alta aceptada)

issued ──request-fix──▶ needs_fix ──(editas la factura)──▶ issue ──▶ issued
   (rejected)                                              (reenvía Subsanacion=S)
                          └──────────── abandon-fix ──────────────▶ issued
                                          (vuelve sin enviar nada)

1. Reabrir

curl -X POST https://api.test.bilteo.com/api/v1/invoices/{id}/actions/request-fix \
  -H "Authorization: Bearer bk_live_xxxxxxxxxxxxxxxx"

Pasa la factura a needs_fix (editable). Requiere los scopes invoices:fix y invoices:issue (debes poder re-emitir lo que reabres). Solo si nunca hubo un alta aceptada y el último registro está rejected.

2. Corregir

Edita la factura con los endpoints normales de actualización (PATCH /invoices/{id}, líneas, etc.) para arreglar lo que la AEAT rechazó. Número, serie, fecha de emisión y datos del emisor quedan bloqueados: una subsanación conserva la identidad de la factura. Si hay que cambiar eso, es una rectificativa.

3. Reenviar como subsanación

curl -X POST https://api.test.bilteo.com/api/v1/invoices/{id}/actions/issue \
  -H "Authorization: Bearer bk_live_xxxxxxxxxxxxxxxx"

Re-emitir desde needs_fix conserva el número y genera un nuevo registro de alta con Subsanacion=S y el RechazoPrevio que corresponda (ver abajo).

Abandonar

Si decides no continuar:

curl -X POST https://api.test.bilteo.com/api/v1/invoices/{id}/actions/abandon-fix \
  -H "Authorization: Bearer bk_live_xxxxxxxxxxxxxxxx"

Devuelve la factura a issued sin enviar nada. Las ediciones hechas se conservan. Requiere invoices:fix.

RechazoPrevio (Lista L17)

Bilteo calcula el RechazoPrevio automáticamente a partir del historial de registros de la factura:

Valor	Cuándo
X	El registro no existe en la AEAT: todos los intentos previos fueron rechazados. Es el caso habitual al subsanar un alta rechazada.
S	El registro existió en la AEAT (algún intento aceptado) y la última subsanación fue rechazada.
N	Sin rechazo previo.

Scopes

Acción	Scopes
request-fix	invoices:fix + invoices:issue
abandon-fix	invoices:fix
re-emitir (issue)	invoices:issue

Solo API

La subsanación es un flujo de integración: vive en la API pública. Desde el panel/front no se puede reabrir una factura a needs_fix.