Facturas rectificativas

Una factura rectificativa es un documento fiscal por derecho propio: recibe su propio número, su propia alta ante la AEAT y su propio efecto en la declaración de IVA. Emitirla implica cuatro decisiones independientes, y las integraciones tienden a mezclarlas:

1. Qué factura puede rectificarse.
2. Qué código de rectificación lleva — el motivo legal.
3. Sustitución o diferencias — si la rectificativa declara los importes correctos o solo el delta.
4. Con qué líneas acaba la rectificativa.

Equivócate a la vez en la tercera y en la cuarta y presentarás una declaración de IVA con el signo invertido.

Cuándo aplica

La factura original debe estar sent o paid. Ninguna otra sirve (BR-INV-001, RD 1619/2012 art. 15):

Para una factura pagada esto no es una opción entre varias: es la única. Una factura pagada no se puede anular, porque su IVA repercutido ya está comprometido con un periodo (BR-INV-023). Ver Anular o rectificar.

La matriz de códigos de rectificación es legal, no cosmética

El código de rectificación declara por qué se rectifica el original, y la AEAT restringe qué códigos son legales para cada tipo de original.

Fuerza un código fuera de su fila y la API responde 422 con los valores legales en allowed_values (BR-INV-035).

Hay dos formas de llegar al código. Por defecto se deriva del slug correction_reason que envías (BR-INV-018):

R5 no se deriva nunca de un motivo. Viene del tipo del original: una rectificativa de una F2 nace siempre R5, sea cual sea el motivo que pases (BR-INV-019).

Como alternativa, fijas correction_code de forma explícita. Sobre un original completo, un R1–R4 explícito gana a la derivación por slug y pasa a ser el código que viaja en la cadena VeriFactu. Úsalo cuando tu propio sistema ya conozca la causa legal y no quieras que se infiera de un slug.

R2 y R3 exigen documentación acreditativa por ley. Pasa justification (de 10 a 1000 caracteres); se antepone a las notas de la rectificativa como trazabilidad documental.

Sustitución o diferencias

Es la decisión de mayor radio de impacto, y en el contrato v1 no la fijas directamente — fijas correction_type y la naturaleza se deriva:

La regla que impone el motor fiscal: una base imponible puede ser negativa solo en una rectificativa por diferencias. En una sustitución —y en cualquier factura ordinaria— una base negativa es un dato incoherente y se rechaza con 422 (BR-VFC-033, BR-INV-017).

Este es el mecanismo para una corrección a la baja. Un abono es una rectificativa por diferencias con base y cuota de IVA negativas, y la AEAT la acepta precisamente porque es la forma fiscalmente correcta de expresar un crédito. Intentar expresar ese mismo abono como una sustitución con importes negativos se rechaza.

Qué envía la API

POST /v1/invoices/{id}/corrective, scope invoices:write. Responde 201 con la nueva factura y una cabecera Location que apunta a ella.

La API Reference publica un ejemplo listo para enviar por cada código — r1_error_fundado, r2_concurso, r3_incobrable, r4_otras y r5_simplificada — en el desplegable de ejemplos del cuerpo de petición de esa operación. Se publican además como entradas reutilizables components.examples.corrective_* del documento OpenAPI, de modo que los clientes generados puedan resolverlas por $ref.

curl -X POST https://api.factuarea.com/v1/invoices/0197a2a8-4cf0-7a31-9a5e-3f2b8c1d6e42/corrective \
  -H "Authorization: Bearer fact_live_3pXnR2VbY7TcA9eFmN5z8KqW" \
  -H "Content-Type: application/json" \
  -d '{
        "correction_reason": "otras",
        "correction_type": "partial",
        "correction_code": "R3",
        "justification": "Crédito declarado incobrable por resolución judicial firme.",
        "lines": [
          { "description": "Ajuste por impago", "quantity": -1, "unit_price": 100, "tax_rate": 21 }
        ]
      }'

La respuesta es un objeto factura ordinario cuyo is_corrective vale true y cuyo bloque corrective lleva original_id, original_number, original_date, correction_reason, correction_type, correction_nature, base_rectificada, cuota_rectificada y correction_aeat_type — este último es el código de rectificación que viajó de verdad a la AEAT.

Para listar todas las rectificativas emitidas contra una factura, usa GET /v1/invoices/{id}/correctives.

Cómo se construyen las líneas

Las tres combinaciones producen documentos genuinamente distintos (BR-INV-036):

full sin lines — una anulación completa. Se genera una línea por cada línea del original con la cantidad negada, conservando el producto, el precio, el tipo impositivo, la retención, el recargo, el descuento y el régimen indirecto del original.

full con lines — una sustitución. Las líneas que envías son las líneas finales; no hay comparación de diferencias. Cada campo que omitas se hereda por índice de la línea original equivalente, fiscalidad incluida. La herencia nunca cae a un tipo por defecto, así que una operación exenta sigue exenta en vez de adquirir un 21 % fantasma. Si envías más líneas de las que tenía el original, las sobrantes no tienen contraparte: no llevan producto y su fiscalidad queda a cero.

partial — líneas de ajuste. No hay línea original con la que casar por índice, así que los valores por defecto son cero y product_id viaja solo si lo declaras explícitamente. Una línea sin product_id no mueve inventario.

Las líneas de suplido también se heredan del original, y por eso el payload de la rectificativa acepta line_type y source_invoice_reference en una línea. Ver Suplidos.

Qué sale en el PDF

La rectificativa se imprime como documento aparte con su propio número, derivado del original: SERIE-AAAA-NNN-REC{n}, donde {n} cuenta las rectificativas ya emitidas contra ese original (BR-INV-021).

Sus bloques de destinatario y emisor se congelan en su propio momento de emisión, no se copian del original. Es deliberado: un motivo habitual para rectificar es precisamente que los datos del destinatario estaban mal, así que la rectificativa debe imprimir los corregidos (BR-INV-024).

Como cualquier factura emitida por una empresa adherida a VeriFactu, lleva el bloque QR legal.

Qué llega a la AEAT

Como registro VeriFactu, la rectificativa es un alta ordinaria cuyo invoice_type es el código de rectificación. Su desglose fiscal lleva el signo descrito en Sustitución o diferencias: base y cuota negativas para una corrección a la baja por diferencias, siempre no negativas para una sustitución. La sustitución declara además la base y la cuota rectificadas del original; una corrección por diferencias no lo hace, en línea con el esquema de la AEAT (BR-VFC-033).

En la declaración trimestral de IVA, la rectificación de una operación en régimen general aterriza en las casillas [14] y [15] con su signo: una corrección a la baja resta, una al alza suma. El snapshot fiscal conserva el código real (R1–R4) en lugar de colapsar toda rectificativa a R5 (BR-TXR-019).

Ese encaminamiento aplica solo al régimen general. Una rectificativa cuyo régimen de operación de cabecera sea otro sigue las casillas propias de ese régimen — la inversión del sujeto pasivo y las operaciones exentas o de exportación se declaran en otro sitio y por tanto no llegan a [14]/[15]. Ver Claves de régimen para saber cómo se determina el régimen de cabecera.

Trazabilidad

Derivado de las reglas de dominio del backend de Factuarea:

• BR-INV-001 — una rectificativa debe referenciar un original emitido; los estados admisibles.
• BR-INV-017 — la naturaleza de la rectificación es exactamente S o I.
• BR-INV-018 — el mapeo de slug de motivo a R1–R4.
• BR-INV-019 — una rectificativa de una F2 nace R5.
• BR-INV-021 — la numeración -REC{n} de las rectificativas.
• BR-INV-024 — el snapshot inmutable del destinatario, congelado en el momento de emisión de la propia rectificativa.
• BR-INV-035 — correction_code explícito, la matriz legal de la AEAT y justification.
• BR-INV-036 — cómo se generan las líneas de la rectificativa y qué se hereda por índice.
• BR-VFC-033 — base y cuota negativas admitidas solo en rectificaciones por diferencias.
• BR-TXR-019 — el signo en las casillas [14]/[15] y la conservación del código de rectificación real.