Correcting rejected records

A correction resubmits the Veri*Factu record of an issued invoice to the AEAT with Subsanacion=S, keeping the record history intact. It fixes submission data, not the fiscal content of an invoice already delivered to a customer.

Exceptional operation

This only applies to submission errors, usually an integration bug. If you need to change amounts, number or date, you probably need a corrective invoice.

An invoice can only be corrected when its latest registration has a final AEAT response: rejected, accepted or accepted_error. With pending, in-process or unknown_response the call returns invoice.fix_requires_rejected.

Two paths depending on history

POST /invoices/{id}/actions/request-fix decides on its own:

Invoice history	What request-fix does
No registration ever accepted (latest record is rejected)	Reopens the invoice as needs_fix so you can edit and issue again.
Some registration accepted (accepted or accepted_error)	The invoice stays issued and immutable. It immediately generates and queues a correction using the current issuer name and partner data, preserving number, date and amounts. Returns the unchanged invoice; the new record shows up in GET /verifactu-records?invoice_id=….

Accepted with errors: fix the source first

If the AEAT accepted with errors because of partner data (tax ID, name…), update the partner (PATCH /partners/{id}) before calling request-fix.

Reopen flow (no registration ever accepted)

issued ──request-fix──▶ needs_fix ──(edit)──▶ issue ──▶ issued
   (rejected)                                (Subsanacion=S)
                         └── abandon-fix ──▶ issued

1. Reopen

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

Moves the invoice to editable needs_fix. Requires invoices:fix and invoices:issue, and only works when no registration was ever accepted and the latest record is rejected.

2. Correct

Use the normal update endpoints (PATCH /invoices/{id}, line operations, and so on) to fix the rejected data. Number, series, issue date and issuer data are locked: a correction preserves the invoice identity.

3. Resubmit

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

Issuing from needs_fix keeps the invoice number and creates a new registration record with Subsanacion=S and the calculated RechazoPrevio.

Abandon

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

Returns to issued without submitting anything. Edits remain stored. Requires invoices:fix.

RechazoPrevio

Value	When
X	The record does not exist at the AEAT: every previous attempt was rejected.
S	The record previously existed at the AEAT and the latest correction was rejected.
N	No previous rejection.

API only

Correction of rejected records is a public-API integration flow. The app does not reopen invoices to needs_fix.