# Corrective invoices and voids follow the rules of the law

A corrective can no longer rectify more than was invoiced, has a deadline, and can fix the recipient's data; a sent or paid invoice is voided only if issued in error.

Sep 27, 2026 · Breaking

A corrective invoice and a void are two different fiscal acts, and the API now tells them apart the way the law does. A corrective corrects an operation that took place: it cannot take any rate below what was invoiced, it has a four-year deadline, and each reason code has its conditions. A void is only for an invoice issued by mistake. Corrective invoices and voids already issued do not change.

## What breaks

- **A `TOTAL` corrective takes no `lines`.** It rectifies everything still invoiced on the original, its live correctives included. Sending `lines` answers `422 RECTIFICATIVA_TOTAL_CON_LINEAS`; until now they were accepted, and without them the original lines were copied negated. A `TOTAL` on an invoice that earlier correctives already brought to zero answers `422 CORRECTIVE_NOTHING_LEFT_TO_RECTIFY`.
- **A `PARTIAL` corrective cannot rectify more than was invoiced.** Counting earlier correctives, no rate may end below zero: `422 CORRECTIVE_EXCEEDS_INVOICED_AMOUNT`, with `tax_group` and `max_reduction` in `error.details`. A `PARTIAL` that only changes the withholding answers `422 CORRECTIVE_WITHHOLDING_ONLY`: a withholding is not a reason to correct, so void the invoice and issue a new one.
- **Four years to correct.** Counted from the original's operation date or, for a cause of article 80 of the VAT Act, from the new optional `circumstance_date`. Past it: `422 CORRECTIVE_OUT_OF_TIME`, with `deadline` and `counted_from` in `error.details`. `circumstance_date` is rejected with `R4` (`422 CORRECTIVE_CIRCUMSTANCE_DATE_NOT_APPLICABLE`) and outside the original's operation date and today (`422 CORRECTIVE_CIRCUMSTANCE_DATE_OUT_OF_RANGE`).
- **`R2` and `R3` have conditions.** Both need a recipient established in Spain, the Canary Islands, Ceuta or Melilla (an `R2` also in another EU member state): `422 CORRECTIVE_RECIPIENT_NOT_ESTABLISHED`. An `R3` needs six months since the original's operation date (`422 CORRECTIVE_BAD_DEBT_TOO_EARLY`, with `earliest_date`) and, on a base of 50 € or less, the new `recipient_is_business: true` (`422 CORRECTIVE_BAD_DEBT_BASE_TOO_LOW`).
- **An original rejected by the AEAT is fixed first.** When VeriFactu rejected the original's record and it was not resubmitted, a corrective answers `422 CORRECTIVE_ORIGINAL_RECORD_REJECTED`.
- **Voiding a sent or paid invoice needs `issued_in_error: true`**, confirming the operation never took place, was a test or a duplicate; without it: `422 VOID_REQUIRES_ISSUED_IN_ERROR`. An invoice with live correctives cannot be voided (`422 INVOICE_HAS_LIVE_CORRECTIVES`), nor can a `TOTAL` corrective (`422 TOTAL_CORRECTIVE_NOT_VOIDABLE`).

## Does this affect you?

- If you send `lines` on a `TOTAL` corrective, remove them.
- If you void invoices that were already sent or paid, send `issued_in_error: true` when that is the case, and use a corrective otherwise.
- If you correct a withholding with a `PARTIAL` corrective, void and reissue instead.
- If you issue `R3` correctives, check the six months and send `recipient_is_business` on small operations.
- If you branch on `error.code` for corrective or void requests, add the new codes.

## What else changed

- **Correct the recipient's data.** When the invoice recorded its recipient with a wrong name, tax ID or address, send the corrected `recipient` with `PARTIAL`, `R4` and no `lines`: the amounts do not change. Another person is not a data correction (`422 CORRECTIVE_RECIPIENT_IS_ANOTHER_PERSON`); the same data as recorded answers `422 CORRECTIVE_RECIPIENT_UNCHANGED`. `recipient` on any other corrective still answers `422 CORRECTIVE_RECIPIENT_NOT_ACCEPTED`.
- **The corrective series is created for you.** Without `series_id` and without a default corrective series, one is created on first use (code `R`, or the next free one) instead of answering `422 SERIES_DEFAULT_NOT_FOUND`.
- **A corrective whose `total_to_pay` is 0 is issued as `PAID`**, with `payment_date` equal to `issue_date`.
- **`CORRECTIVE_RECENT_DUPLICATE` covers two minutes, not 24 hours.** It catches a double submission; a second identical corrective a few minutes later is no longer refused as a duplicate.
- **A simplified invoice is always corrected with `R5`.** To give its customer a full invoice with their details, use the [exchange of simplified invoices](/changelog/simplified-invoice-exchange), not a corrective.

## Endpoints

- `POST /v1/companies/{company_id}/invoices/{invoice_id}/corrective` — New optional circumstance_date and recipient_is_business; recipient accepted for an R4 data correction; new 422 codes
- `POST /v1/companies/{company_id}/invoices/{invoice_id}/void` — New issued_in_error; 422 VOID_REQUIRES_ISSUED_IN_ERROR / INVOICE_HAS_LIVE_CORRECTIVES / TOTAL_CORRECTIVE_NOT_VOIDABLE

## Where to go next

- [Corrective invoices](/verifactu/corrective-invoices)
- [Create a corrective invoice](/invoices/createCompanyCorrectiveInvoice)
- [Void an invoice](/invoices/voidCompanyInvoice)

---

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