---
title: "Reissue Invoice"
method: POST
path: "/api/autopilot/invoices/{invoice_id}/reissue"
tags: ["autopilot"]
---

# Reissue Invoice

`POST /api/autopilot/invoices/{invoice_id}/reissue`

## Request

- Base URL: `https://api.taxcompass.it` (the document declares no server; this is the origin it was published from)
- URL: `https://api.taxcompass.it/api/autopilot/invoices/{invoice_id}/reissue`
- Auth: HTTP bearer

Send an already-numbered document to SdI again (AP-033).

The route for the two ways a transmission ends badly: a **scarto** (SdI
refused the document — it was never issued, so its number is still the right
one) and a send the provider never answered. Both keep their number and their
XML on purpose, and this re-transmits exactly those bytes; nothing is
rebuilt, so a document that validated once cannot become a different one on
the second attempt.

Status codes, all decided by the store's own refusals:

* **404** — no invoice of that id for this caller, unknown and somebody
  else's alike;
* **409** — the invoice is not in a state to re-send: a draft (issue it
  first) or a document SdI has accepted or is still answering. Two of them
  because the caller's next step differs, and the row is one they can read
  anyway, so neither message leaks anything;
* **500** — the stored document cannot be read back. The same server fault
  ``GET /xml`` reports, and for the same reason: those bytes are what would
  be sent;
* **502** — the transmission failed again. The invoice is back in ``error``
  and this call can be repeated.

Carries the AP-099 write limiter, like every other mutation here: it makes an
outbound call, even though (unlike issuing) it never spends a number.

## Path parameters

- `invoice_id` string, uuid, required

## Response `200`

Successful Response

- InvoiceRead: One stored invoice as the API returns it (``payload`` decrypted). ``number`` is NULL until the issue transaction assigns it, so a draft is exactly the row whose ``status`` is ``draft`` and whose ``number`` is unset. ``total_amount`` is the imponibile the store computed from the lines, and ``bollo_applied`` the builder's verdict on it — both stored plaintext because the live estimate aggregates them in SQL. ``credit_note_of`` is what makes a TD04 legible on its own (AP-090): set, this row is a nota di credito and names the invoice it corrects; NULL on every ordinary document. It is the store's field and never a client's — a credit note is opened through its own route, not by writing this on a draft. ``client_label`` is the same kind of field for an ``imported`` row (AP-095): a pre-signup invoice names its customer as the text the user's own export carried, because there is no client record behind it and inventing one would put a half-filled customer — no address, no identifier — in the picker that issues real documents. It is NULL on every invoice that has a ``client_id``.
  - `client_id` string, uuid, nullable
  - `ateco` string, nullable
  - `issue_date` string, date, nullable
  - `due_date` string, date, nullable
  - `causale` string, nullable
  - `lines` InvoiceLineOutput[]
    - `description` string, required
    - `unit_price` string, required
    - `quantity` string
    - `unit` string, nullable
  - `id` string, uuid, required
  - `year` integer, required
  - `number` integer, nullable
  - `doc_type` string
  - `status` 'draft' | 'sending' | 'issued' | 'delivered' | 'not_delivered' | 'rejected' | 'error' | 'imported'
  - `total_amount` string
  - `bollo_applied` boolean
  - `credit_note_of` string, uuid, nullable
  - `client_label` string, nullable
  - `created_at` string, date-time, nullable
  - `updated_at` string, date-time, nullable
  - `payment` InvoicePayment: The payment side of one invoice — computed by ``services.invoice_payments``. Only ever computed on the server, from the ledger: a paid flag on the document would be a second copy of a fact the incassi table already holds, and the two would disagree the first time someone deleted a payment. * ``due`` — the invoice total minus the credit notes *issued* against it (a draft credit note has told the customer nothing yet, so it owes nothing less). * ``credited`` — that credit-note sum. * ``paid`` — net cash collected against this invoice: its own payments plus the refunds recorded against its credit notes (which are stored negative). * ``outstanding`` — what the customer still owes, never below zero. * ``overpaid_by`` — what arrived beyond ``due``, never below zero. * ``last_payment_date`` — the latest *incoming* payment (a refund is not a payment). * ``days_overdue`` — whole days past ``due_date`` while something is still owed; ``None`` when nothing is owed or the invoice has no due date.
    - `state` 'unpaid' | 'partly_paid' | 'paid' | 'overpaid' | 'credited', required
    - `due` string, required
    - `credited` string
    - `paid` string
    - `outstanding` string
    - `overpaid_by` string
    - `last_payment_date` string, date, nullable
    - `days_overdue` integer, nullable

## Other responses

- `409`: The invoice is not waiting to be sent again
- `422`: Validation Error
- `500`: The stored document could not be read back
- `502`: The provider could not be reached

---

[API](https://skmtc.dev/taxcompass/apis/taxcompass-api.md) · [All operations](https://skmtc.dev/taxcompass/apis/taxcompass-api/llms.txt) · [OpenAPI document](https://skmtc.dev/taxcompass/apis/taxcompass-api/revisions/fef5fc6a9b91?raw)