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 emitida: issued u overdue, esté cobrada o no. Ninguna otra sirve (BR-INV-001, RD 1619/2012 art. 15):

Para una factura pagada esto no es una opción entre varias: por defecto es la única. Una factura pagada no se anula por defecto, porque su IVA repercutido ya está comprometido con un periodo (BR-INV-023); la única excepción es una factura emitida por error, que se anula con revert_collections: true. Ver Anular o rectificar.

Una factura ya anulada por completo (con una rectificativa total por diferencias) no admite ninguna rectificativa más (invoice_already_rectified_in_full). Una sustituida por completo no admite una segunda corrección total, pero sí una parcial.

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. El artículo 15.5 del RD 1619/2012 permite expresar la corrección con el importe de la rectificación, sea cual sea su signo (por diferencias, I), o con la factura tal como queda (sustitución, S). Se elige con correction_type y, opcionalmente, correction_nature; las tres formas de corregir una factura son:

correction_nature es opcional. Sin ella, full con lines es una sustitución (S) y full sin lines y partial son por diferencias (I). La naturaleza que envías manda siempre, pero debe ser coherente con el resto de la petición: una combinación incoherente se rechaza con 422 antes de crear nada.

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, BR-INV-078). Una rectificativa con base negativa se lee siempre como I, y unit_price nunca es negativo: lo que resta es una quantity negativa.

Un abono es, por tanto, 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. VeriFactu la registra como TipoRectificativa I; una sustitución se registra como TipoRectificativa S junto con ImporteRectificacion, la base y la cuota del original.

Qué envía la API

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

Todas las rutas de esta guía cuelgan de /v1/companies/{company}/…: {company} es el id (UUID v7) del NIF con el que operas, y en los ejemplos curl es $COMPANY_ID. Alcanzar un NIF explica cómo resolverlo.

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/companies/$COMPANY_ID/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/companies/{company}/invoices/{id}/correctives.

Cómo se construyen las líneas

Las tres formas de corregir 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 y el prefijo [ANULACION], 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, y correction_nature: S es opcional porque esta combinación es una sustitución por defecto. 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, con el prefijo [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.

Naturaleza de cada línea corregida. Una línea puede declarar unit, regime_key, exemption_reason y exemption_reason_text, con las mismas reglas que POST /v1/companies/{company}/invoices. Siguen la presencia de la clave: una clave que omites hereda el valor de la línea original con el mismo índice; una clave que envías —incluso null— lo sustituye, y null significa expresamente ninguno. Por ejemplo, exemption_reason: null convierte una línea original exenta en una gravada. Vale tanto para una sustitución como para una corrección por diferencias, y las mismas claves existen en la tool MCP create_corrective_invoice.

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.

Numeración y series

Cada serie de facturas tiene un propósito fijo (invoice_kind), y un documento solo se numera en una serie de su propio propósito (BR-INV-076):

La rectificativa se numera con el contador correlativo de esa serie y su formato, así que con el formato por defecto los números son R-2026-001, R-2026-002… para las facturas completas y RS-2026-001… para las simplificadas. El original conserva su propio número, su estado y su registro VeriFactu; la rectificativa lo referencia por su número.

Envía series_id para elegir la serie; si no, se usa la serie por defecto del propósito correcto y, si la empresa no tiene ninguna, se crea en el momento. Una serie de otro propósito se rechaza con 422 series_invoice_kind_mismatch; también una archivada o de otra empresa. Una rectificativa no se duplica (invoice_not_duplicatable_in_current_state): para volver a corregir el original, emite una rectificativa nueva a partir de él.

Qué sale en el PDF

La rectificativa se imprime como documento aparte con su propio número, tomado de su serie de rectificativas (ver Numeración y series).

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.

Elegir la plantilla

Una rectificativa es un documento nuevo con su propia presentación: no copia la plantilla de la original. Tanto POST /v1/companies/{company}/invoices/{invoice}/corrective como POST /v1/companies/{company}/invoices/substitute-simplified aceptan el pdf_template_id opcional:

El propósito decide qué plantillas encajan: corrective para la rectificación de una factura completa (R1–R4), simplified_corrective para la de una simplificada (R5) y complete para la factura completa que sustituye a simplificadas. expected_selection_version no se acepta en estas dos operaciones — no hay una versión anterior con la que comparar — y tampoco pdf_template_uuid; enviar cualquiera de los dos responde 422 cuando la presentación con revisiones está activa para tu empresa y se ignora en caso contrario. Mientras la presentación con revisiones no esté activa para tu empresa, pdf_template_id se ignora y la rectificativa se genera como antes.

curl -X POST https://api.factuarea.com/v1/companies/$COMPANY_ID/invoices/0197b1c2-89ab-7def-8123-456789abcdef/corrective \
  -H "Authorization: Bearer $FACTUAREA_API_KEY" \
  -H "Idempotency-Key: $(uuidgen)" \
  -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 }
    ],
    "pdf_template_id": "0197c4a1-02aa-7c31-9e5b-6d2f8a4c1b73"
  }'

La rectificativa se emite al crearse, así que su presentación se conserva en ese momento. Cambiar después el aspecto de su PDF es una revisión de presentación, nunca una edición: consulta Presentación de documentos. Los datos de negocio estructurados de una factura (calendario de pagos, referencias, centros DIR3) se explican en Datos de negocio de la factura: una rectificativa admite su propio calendario de pagos (los plazos negativos son válidos) y hereda las referencias de línea solo a través de source_line_id. Una rectificativa vence el día de su último plazo, o 30 días después de emitirse si no tiene calendario.

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 — el formato de número de factura SERIE-AAAA-NNN.
• BR-INV-076 — una serie solo numera documentos de su propio propósito; las rectificativas, en su propia serie.
• BR-INV-078 — las tres formas de corregir y la coherencia de naturaleza, alcance y líneas.
• 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.
• BR-PDF-022 — cómo se elige la plantilla de un documento y la escalera de precedencia.
• BR-INV-086 — la identidad de línea y qué hereda una rectificativa por source_line_id.