# Corrective invoices (R1–R5)

Pick the right rectification type and code, and see the canonical request shapes BeeL. accepts for each scenario.

A corrective invoice (*factura rectificativa*) corrects a previously issued invoice. BeeL. exposes them through `POST /v1/companies/{company_id}/invoices/{invoice_id}/corrective` — the URL points to the **original** invoice, and the body describes the correction.

You decide two things:

- **`rectification_type`** — `TOTAL` (rectify everything still invoiced on the original) or `PARTIAL` (apply a delta)
- **`rectification_code`** — `R1`–`R5` (the legal motive)

Plus a `reason` in free text (10–1,000 characters) describing the situation in human language. All three are required.

The corrective comes back with `type: CORRECTIVE` and `rectified_invoice_id` pointing at the original. It goes through VeriFactu exactly like any other invoice: same `verifactu` block, same states, same QR and the same `verifactu.status.updated` webhook.

<Callout type="warn">
  **Only invoices issued in BeeL. can be corrected.** The original is addressed by its BeeL. `invoice_id`, and an invoice issued before your integration — numbered and registered by another system — has none. Correct those with the system that issued them.
</Callout>

## The two axes

```text
           PARTIAL  (one delta registro, easy bookkeeping)
        ┌────────────────────────────────────────────────┐
why →   │  R1   │  R2   │  R3   │  R4   │  R5  (F2 only) │
        ├────────────────────────────────────────────────┤
           TOTAL    (one registro replaces the original)
```

| `rectification_type` | AEAT `tipo_rectificativa` | What BeeL. sends to AEAT |
|---|---|---|
| `PARTIAL` | `I` (by differences) | One record with delta lines; no `importe_rectificativa` block |
| `TOTAL` | `S` (by substitution) | One record with the **new** totals + the **original** totals echoed in `importe_rectificativa` |

The original invoice's status changes after issuance:

- `PARTIAL` → original becomes `RECTIFIED` (can be corrected again — several partial correctives on the same original are fine)
- `TOTAL` → original becomes `VOIDED` (terminal, no further correctives)

A `TOTAL` rectifies what is **still invoiced** on the original: its lines and those of its live correctives (voided ones do not count), negated. After two partial correctives, a `TOTAL` takes back only what they left. If they already brought the invoice to zero, it answers `422` [`CORRECTIVE_NOTHING_LEFT_TO_RECTIFY`](/errors/CORRECTIVE_NOTHING_LEFT_TO_RECTIFY).

A corrective whose `total_to_pay` is 0 — a recipient-data correction, for example — has nothing to refund or collect, so it is issued as `PAID`, with `payment_date` equal to `issue_date`.

<Callout type="info">
  **A corrective is issued immediately.** There is no draft step: the request numbers the corrective, freezes it and — if the NIF is under VeriFactu — submits it, in the same call. Check the payload before you send it; a wrong corrective is fixed with another corrective against the original, not by editing it.
</Callout>

### What a `TOTAL` corrective does to the original

The original moves to `VOIDED`, but **no cancellation record is sent to AEAT for it**. The correction travels in the corrective's own registration — a `tipo_rectificativa` `S` record that references the original. So, on the original:

- its `verifactu.submission_status` keeps its registration's outcome (typically `ACCEPTED`) — it does not become `VOIDED`;
- [its VeriFactu records](/invoices/listCompanyInvoiceVerifactuRecords) show no `VOID` record.
- its PDF does not change: it stays the document that was delivered. The corrective has its own PDF.

That is the difference from the [void endpoint](/verifactu/cancel-and-fix#anulación-void), which does send a cancellation record. Both leave the invoice `VOIDED`; only one tells AEAT the invoice should not exist — and it is only for an invoice issued by mistake. An operation that did take place is corrected, not voided.

> **Rules that apply here:** [COR-003 · A corrective shows the difference or the amounts after the correction](/rules/corrective#cor-003) · [COR-004 · The corrective record says whether it substitutes or adds a difference](/rules/corrective#cor-004)

## Pick the reason (R1–R5)

| `rectification_code` | When to use | Legal basis |
|---|---|---|
| **R1** | Almost every common correction: wrong amount, post-issuance discount, returned goods, an operation cancelled by agreement, a wrong tax treatment | Art. 80 Uno/Dos/Seis LIVA + error fundado en derecho |
| **R2** | The customer is in formal concurso de acreedores | Art. 80 Tres LIVA |
| **R3** | Bad debt: invoice is uncollectable after the legal procedure | Art. 80 Cuatro LIVA |
| **R4** | Any other cause, such as the recipient's data recorded wrong | Resto de causas |
| **R5** | Correcting a **simplified** (F2) invoice — any reason | Art. 80 Uno/Dos LIVA for F2 |

**COR-002 · Pick the reason code: R1–R4 for standard invoices, R5 for simplified**

`Required` · Law · Impact: critical · Checked by the API: a request that breaks it is rejected with the error codes listed.

Send the `rectification_code` that matches the cause: `R1` for an error founded in law or art. 80 Uno, Dos and Seis LIVA, `R2` for insolvency, `R3` for bad debt, `R4` for the rest. A simplified invoice is always corrected with `R5`, and `R5` corrects nothing else.

Full rule: [COR-002](/rules/corrective#cor-002)

> **Rules that apply here:** [COR-002 · Pick the reason code: R1–R4 for standard invoices, R5 for simplified](/rules/corrective#cor-002) · [COR-010 · A provisional price is rectified once the final one is known](/rules/corrective#cor-010) · [COR-011 · Discounts and rebates granted after the sale go on a corrective](/rules/corrective#cor-011)

## Deadline and `circumstance_date`

A corrective must be issued within four years from when the tax accrued — the original's `operation_date`, or its `issue_date` when it has none — or, for a cause of article 80 of the VAT Act (`R1`, `R2`, `R3`, `R5`), from when the circumstance took place. Send that date as `circumstance_date` (a discount granted later, an order cancelled, the insolvency order, the bad-debt claim); without it, the four years count from the operation date.

| Case | Error | Status | Why |
|---|---|---|---|
| The four years have passed; `error.details` carries `deadline` and `counted_from` | [`CORRECTIVE_OUT_OF_TIME`](/errors/CORRECTIVE_OUT_OF_TIME) | `422` | The four-year period to issue a corrective has ended. It counts from the original's operation date (its `operation_date`, or its `issue_date` when it has none) or, for a cause of article 80 of the VAT Act, from the `circumstance_date` sent. `error.details` carries `deadline` and `counted_from`. |
| `circumstance_date` with `R4`, which covers causes other than article 80 | [`CORRECTIVE_CIRCUMSTANCE_DATE_NOT_APPLICABLE`](/errors/CORRECTIVE_CIRCUMSTANCE_DATE_NOT_APPLICABLE) | `422` | `circumstance_date` was sent with a `rectification_code` that is not a cause of article 80 of the VAT Act (`R4`). |
| `circumstance_date` before the original's operation date or after today | [`CORRECTIVE_CIRCUMSTANCE_DATE_OUT_OF_RANGE`](/errors/CORRECTIVE_CIRCUMSTANCE_DATE_OUT_OF_RANGE) | `422` | `circumstance_date` is before the original's operation date or after today. |

## Scenario 1 — TOTAL cancellation (R1)

The operation was left without effect by agreement with the customer (an order cancelled before delivery, Art. 80 Dos LIVA). Don't send `lines` for a TOTAL: it rectifies everything still invoiced on the original. Sending them is rejected with [`RECTIFICATIVA_TOTAL_CON_LINEAS`](/errors/RECTIFICATIVA_TOTAL_CON_LINEAS).

```bash
curl -X POST "https://app.beel.es/api/v1/companies/{company_id}/invoices/{invoice_id}/corrective" \
  -H "Authorization: Bearer $BEEL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "rectification_type": "TOTAL",
    "rectification_code": "R1",
    "reason": "Order cancelled by agreement with the customer before delivery: the operation is left without effect (Art. 80 Dos LIVA).",
    "circumstance_date": "2026-03-10",
    "notes": "Cancellation agreed with the customer on 10/03/2026. No amount pending collection."
  }'
```

The original becomes `VOIDED`; the corrective carries the matching tipo_rectificativa `S` to AEAT.

## Scenario 2 — PARTIAL adjustment for bankruptcy (R2)

The customer was declared insolvent and has not paid the VAT charged; you reduce the unpaid part. Send the delta as a `PARTIAL`, with the date of the insolvency order as `circumstance_date`. `R2` needs a recipient established in Spain, the Canary Islands, Ceuta or Melilla — or in another EU member state, for insolvency proceedings there — or it answers `422` [`CORRECTIVE_RECIPIENT_NOT_ESTABLISHED`](/errors/CORRECTIVE_RECIPIENT_NOT_ESTABLISHED).

```bash
curl -X POST "https://app.beel.es/api/v1/companies/{company_id}/invoices/{invoice_id}/corrective" \
  -H "Authorization: Bearer $BEEL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "rectification_type": "PARTIAL",
    "rectification_code": "R2",
    "reason": "Customer declared insolvent by order of 10/02/2026 (Commercial Court No. 2 Madrid, case 123/2026): the unpaid part of the invoice is reduced under Art. 80 Tres LIVA.",
    "circumstance_date": "2026-02-10",
    "lines": [
      {
        "description": "Unpaid amount at the insolvency declaration",
        "quantity": -16,
        "unit": "hours",
        "unit_price": 37.5,
        "discount_percentage": 0,
        "main_tax": {
          "type": "IVA",
          "percentage": 21,
          "regime_key": "01"
        }
      }
    ],
    "notes": "Credit communicated to the insolvency administrator."
  }'
```

Lines carry negative `quantity` (or negative `unit_price`) to express the reduction. The original stays `RECTIFIED`.

A `PARTIAL` may raise any amount, but it may not take the taxable base of any rate below zero once the previous correctives are counted: that answers `422` [`CORRECTIVE_EXCEEDS_INVOICED_AMOUNT`](/errors/CORRECTIVE_EXCEEDS_INVOICED_AMOUNT), with `tax_group` (for example `IVA 21%`) and `max_reduction` in `error.details`. And a `PARTIAL` whose lines only change the withholding answers `422` [`CORRECTIVE_WITHHOLDING_ONLY`](/errors/CORRECTIVE_WITHHOLDING_ONLY): a withholding that should not have been applied is not a cause for a corrective — void the invoice and issue a new one without it.

> **Rules that apply here:** [COR-009 · An insolvency corrective (R2) needs a declaration of insolvency](/rules/corrective#cor-009)

## Scenario 3 — PARTIAL bad-debt write-off (R3)

Documented bad debt under Art. 80 Cuatro LIVA. Send a negative line for the uncollectible part, with the date of the claim as `circumstance_date`. The API checks what it can see:

| Case | Error | Status | Why |
|---|---|---|---|
| Less than six months since the original's operation date; `error.details` carries `earliest_date` (one year applies when the previous year's turnover exceeded the threshold, which is yours to apply) | [`CORRECTIVE_BAD_DEBT_TOO_EARLY`](/errors/CORRECTIVE_BAD_DEBT_TOO_EARLY) | `422` | A bad-debt corrective (`R3`) was requested less than six months after the original's operation date. `error.details` carries `earliest_date` and `counted_from`. One year applies instead when the previous year's turnover exceeded 6,010,121.04 €, which is the issuer's to apply. |
| An operation with a small base and no `recipient_is_business: true` declaring the recipient acted as a business or professional | [`CORRECTIVE_BAD_DEBT_BASE_TOO_LOW`](/errors/CORRECTIVE_BAD_DEBT_BASE_TOO_LOW) | `422` | A bad-debt corrective (`R3`) on an operation with a taxable base of 50 € or less, without `recipient_is_business`. The law allows that reduction only when the recipient acted as a business or professional. |
| A recipient not established in Spain, the Canary Islands, Ceuta or Melilla | [`CORRECTIVE_RECIPIENT_NOT_ESTABLISHED`](/errors/CORRECTIVE_RECIPIENT_NOT_ESTABLISHED) | `422` | `R2` (insolvency) or `R3` (bad debt) was used with a recipient not established in Spain, the Canary Islands, Ceuta or Melilla. The base is only reduced for those causes with such a recipient; `R2` also accepts a recipient in another EU member state, for insolvency proceedings there. |

The other conditions — the claim in court or by notarial demand, filing with the AEAT — are yours to meet.

```bash
curl -X POST "https://app.beel.es/api/v1/companies/{company_id}/invoices/{invoice_id}/corrective" \
  -H "Authorization: Bearer $BEEL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "rectification_type": "PARTIAL",
    "rectification_code": "R3",
    "reason": "Bad debt under Art. 80 Cuatro LIVA: more than six months since the tax accrued without collection, claimed by notarial demand.",
    "circumstance_date": "2026-05-04",
    "lines": [
      {
        "description": "Bad debt adjustment - unpaid amount",
        "quantity": -40,
        "unit": "hours",
        "unit_price": 37.5,
        "discount_percentage": 0,
        "main_tax": {
          "type": "IVA",
          "percentage": 21,
          "regime_key": "01"
        }
      }
    ],
    "notes": "Notarial demand of 04/05/2026 (Protocol 456/2026). Operation of 15/10/2025."
  }'
```

> **Rules that apply here:** [COR-008 · A bad-debt corrective (R3) needs the legal conditions first](/rules/corrective#cor-008) · [COR-020 · A bad-debt corrective waits six months and needs a business recipient under 50 €](/rules/corrective#cor-020)

## Scenario 4 — Correcting the recipient's data (R4)

The invoice recorded its recipient with a wrong name, tax ID or address. Fix the customer first, then send a `PARTIAL` corrective with `rectification_code: R4`, **no `lines`** and the corrected `recipient` — for a registered customer, the same `customer_id`:

```bash
curl -X POST "https://app.beel.es/api/v1/companies/{company_id}/invoices/{invoice_id}/corrective" \
  -H "Authorization: Bearer $BEEL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "rectification_type": "PARTIAL",
    "rectification_code": "R4",
    "reason": "The customer'\''s tax ID was mistyped on the invoice",
    "recipient": { "customer_id": "{customer_id}" }
  }'
```

The corrective carries the corrected recipient and leaves the amounts unchanged: its lines negate what is still invoiced and repeat it, so every rate nets to zero and it is issued as `PAID`. The original becomes `RECTIFIED`.

| Case | Error | Status | Why |
|---|---|---|---|
| Another customer than the one the invoice went to — that is not a data error: correct the invoice in full (`TOTAL`) and issue a new one to the right customer | [`CORRECTIVE_RECIPIENT_IS_ANOTHER_PERSON`](/errors/CORRECTIVE_RECIPIENT_IS_ANOTHER_PERSON) | `422` | A recipient-data corrective (`PARTIAL`, `R4`, no `lines`) names a customer other than the one the invoice went to. It corrects the data of the same recipient; an invoice issued to another person is not a data error. |
| The same name, tax ID and address the invoice already recorded | [`CORRECTIVE_RECIPIENT_UNCHANGED`](/errors/CORRECTIVE_RECIPIENT_UNCHANGED) | `422` | A recipient-data corrective carries the same name, tax ID and address the invoice already recorded: there is nothing to correct. |
| A `recipient` in any other corrective | [`CORRECTIVE_RECIPIENT_NOT_ACCEPTED`](/errors/CORRECTIVE_RECIPIENT_NOT_ACCEPTED) | `422` | The request to create a corrective invoice carries a `recipient` (a `customer_id` or inline data) outside a recipient-data correction. A corrective goes to the recipient of the invoice it corrects, with that invoice's data; `recipient` is accepted only to correct that recipient's name, tax ID or address, with `rectification_type` `PARTIAL`, `rectification_code` `R4` and no `lines`. Nothing is created. |

## Scenario 5 — R5: correcting a simplified invoice [#scenario-5--r5-cancelling-an-f2-to-issue-a-proper-f1]

A simplified (F2) invoice is always rectified with `R5`, whatever the cause. A customer returned one of the two items on the ticket:

```bash
curl -X POST "https://app.beel.es/api/v1/companies/{company_id}/invoices/{f2_invoice_id}/corrective" \
  -H "Authorization: Bearer $BEEL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "rectification_type": "PARTIAL",
    "rectification_code": "R5",
    "reason": "The customer returned one of the two items on the ticket",
    "lines": [
      {
        "description": "Return - T-shirt size M",
        "quantity": -1,
        "unit_price": 16.53,
        "main_tax": { "type": "IVA", "percentage": 21, "regime_key": "01" }
      }
    ]
  }'
```

<Callout type="info">
  **A customer who asks for a full invoice is not a correction.** To give them an invoice with their details instead of the ticket, use the [exchange of simplified invoices](/verifactu/simplified-vs-standard#upgrading-an-f2-to-f1-the-canje-case), not an `R5` corrective: nothing is being rectified.
</Callout>

## Validation rules BeeL. applies

| Rule | What happens if you break it |
|---|---|
| [COR-002 · Pick the reason code: R1–R4 for standard invoices, R5 for simplified](/rules/corrective#cor-002) | `422` [`RECTIFICATIVA_R5_ONLY_SIMPLIFICADA`](/errors/RECTIFICATIVA_R5_ONLY_SIMPLIFICADA) or [`RECTIFICATIVA_R1R4_NOT_SIMPLIFICADA`](/errors/RECTIFICATIVA_R1R4_NOT_SIMPLIFICADA) |
| Original must exist and belong to your account | `404` — the URL `{invoice_id}` resolves to nothing |
| [COR-007 · A wrong corrective is fixed against the original, not corrected itself](/rules/corrective#cor-007) | `422` [`CORRECTIVE_NOT_RECTIFIABLE`](/errors/CORRECTIVE_NOT_RECTIFIABLE) |
| [COR-017 · A corrective keeps the recipient, except to correct the recipient's data](/rules/corrective#cor-017) — the corrective takes the recipient of the original; send `recipient` only to correct its data ([Scenario 4](#scenario-4--correcting-the-recipients-data-r4)) | `422` [`CORRECTIVE_RECIPIENT_NOT_ACCEPTED`](/errors/CORRECTIVE_RECIPIENT_NOT_ACCEPTED), and nothing is created |
| [COR-022 · An invoice whose record AEAT rejected is fixed before it is corrected](/rules/corrective#cor-022) | `422` [`CORRECTIVE_ORIGINAL_RECORD_REJECTED`](/errors/CORRECTIVE_ORIGINAL_RECORD_REJECTED) — fix and resubmit the original first |
| [COR-023 · A corrective never rectifies more than was invoiced](/rules/corrective#cor-023) | `422` [`CORRECTIVE_EXCEEDS_INVOICED_AMOUNT`](/errors/CORRECTIVE_EXCEEDS_INVOICED_AMOUNT) or, on a `TOTAL`, [`CORRECTIVE_NOTHING_LEFT_TO_RECTIFY`](/errors/CORRECTIVE_NOTHING_LEFT_TO_RECTIFY) |
| [COR-024 · A corrective does not change only the withholding](/rules/corrective#cor-024) | `422` [`CORRECTIVE_WITHHOLDING_ONLY`](/errors/CORRECTIVE_WITHHOLDING_ONLY) |
| [SIM-007 · Exchanging a simplified invoice for a full one](/rules/simplified#sim-007) — an invoice issued in [exchange for simplified invoices](/verifactu/simplified-vs-standard#exchange-with-verifactu) and recorded with VeriFactu as `F3` cannot be corrected yet | `422` [`EXCHANGE_INVOICE_NOT_CORRECTABLE`](/errors/EXCHANGE_INVOICE_NOT_CORRECTABLE) — contact support |
| The original cannot be a proforma | `422` [`PROFORMA_CORRECTIVE_FORBIDDEN`](/errors/PROFORMA_CORRECTIVE_FORBIDDEN) |
| Original must be `ISSUED`, `SENT`, `PAID` or `RECTIFIED` | `422` [`INVOICE_NOT_CORRECTIBLE_IN_CURRENT_STATUS`](/errors/INVOICE_NOT_CORRECTIBLE_IN_CURRENT_STATUS): a `DRAFT` must be issued first, and a `VOIDED` invoice — including one closed by a `TOTAL` corrective — closes the chain |
| [COR-021 · An identical corrective a moment after another is taken as a double submission](/rules/corrective#cor-021) | `422` [`CORRECTIVE_RECENT_DUPLICATE`](/errors/CORRECTIVE_RECENT_DUPLICATE) — same original, same `rectification_type`, `rectification_code` and `reason`, and the same totals, moments after the first; the message names the corrective that already exists. It guards against a double submit; wait a few minutes, or change the reason or amounts, if you really mean a second one |
| For `PARTIAL`, line totals can be negative or positive — anything goes mathematically | — |
| For `PARTIAL`, `lines` are **required** | `422` [`RECTIFICATIVA_PARCIAL_SIN_LINEAS`](/errors/RECTIFICATIVA_PARCIAL_SIN_LINEAS) |
| For `TOTAL`, `lines` must be **omitted**: it rectifies the whole original | `422` [`RECTIFICATIVA_TOTAL_CON_LINEAS`](/errors/RECTIFICATIVA_TOTAL_CON_LINEAS) |

> **Rules that apply here:** [COR-003 · A corrective shows the difference or the amounts after the correction](/rules/corrective#cor-003)

## Which series numbers the corrective

Omit `series_id` and the corrective is numbered in your company's **default series for corrective invoices**, never in the original's series: corrective invoices go in a series of their own. If the company has none, it is created on first use (code `R`, or the next free one). An explicit `series_id` must be a corrective series. See [Series and numbering](/guides/series-and-numbering#correctives-and-proformas).

## Finding the correctives of an invoice

List invoices filtered by the original: `GET /v1/companies/{company_id}/invoices?rectified_invoice_id={invoice_id}` returns every corrective issued against it, `TOTAL` or `PARTIAL`.

> **Rules that apply here:** [COR-001 · Wrong data on an issued invoice is fixed with a corrective](/rules/corrective#cor-001) · [COR-005 · A corrective identifies the invoice it rectifies](/rules/corrective#cor-005) · [COR-017 · A corrective keeps the recipient, except to correct the recipient's data](/rules/corrective#cor-017) · [COR-019 · Insolvency and bad-debt correctives need a recipient established in Spain](/rules/corrective#cor-019) · [COR-023 · A corrective never rectifies more than was invoiced](/rules/corrective#cor-023)

## Related

<Related>

- [Invoice types](/verifactu/invoice-types) — R1–R5 in the broader catalogue
- [Cancel vs amend](/verifactu/cancel-and-fix) — when to use the void endpoint instead
- [Submission states](/verifactu/submission-states) — what happens after BeeL. submits the corrective
- [Create a corrective invoice](/invoices/createCompanyCorrectiveInvoice) — full request schema

</Related>

---

Full OpenAPI spec: https://docs.beel.es/api/openapi