> ## Documentation Index
> Fetch the complete documentation index at: https://docs.spedy.com.br/llms.txt
> Use this file to discover all available pages before exploring further.

# Cancelamento, correção e inutilização

> Como cancelar, corrigir e inutilizar documentos fiscais.

Depois que uma nota é autorizada, corrigir um erro não é tão simples quanto
editar um registro — a legislação fiscal define operações específicas, cada
uma com seu próprio propósito, prazo e limite do que pode ser alterado. Usar
a operação errada é rejeitado pela SEFAZ/prefeitura ou, pior, aceito e gera
inconsistência fiscal. Esta página cobre as três operações disponíveis na
API e quando usar cada uma.

| Operação                     | Resolve                                                              | Nota precisa estar                 | Disponível para    |
| ---------------------------- | -------------------------------------------------------------------- | ---------------------------------- | ------------------ |
| **Cancelamento**             | Desfazer uma nota inteira, dentro do prazo legal                     | `authorized`                       | NF-e, NFC-e, NFS-e |
| **Carta de correção (CC-e)** | Corrigir dados **não estruturantes** de uma NF-e já autorizada       | `authorized`                       | Apenas NF-e        |
| **Inutilização**             | Formalizar, junto à SEFAZ, que uma faixa de numeração não será usada | Números **nunca enviados** à SEFAZ | NF-e, NFC-e        |

## Cancelamento

Cancela uma nota **já autorizada**, dentro do prazo legal. O status final é
`canceled` (veja [Ciclo de vida da nota](/pages/guides/ciclo-de-vida-da-nota)).

| Modelo | Endpoint                            |
| ------ | ----------------------------------- |
| NF-e   | `DELETE /v1/product-invoices/{id}`  |
| NFC-e  | `DELETE /v1/consumer-invoices/{id}` |
| NFS-e  | `DELETE /v1/service-invoices/{id}`  |

O corpo da requisição (`CancelInvoiceRequestDto`) exige apenas um campo:

```json theme={null}
{ "reason": "Erro de digitação no CPF do destinatário" }
```

`reason` é obrigatório. A API aceita a partir de 1 caractere, mas os limites
que valem de fato são os da autoridade fiscal:

* **NF-e e NFC-e:** a SEFAZ exige a justificativa (`xJust`) com **15 a 255
  caracteres** — mais curto que isso é rejeitado.
* **NFS-e:** o limite é definido pela prefeitura/provedor e **varia por
  município** — não há um mínimo único. Use uma justificativa clara na mesma
  faixa (15+ caracteres).

Descreva o motivo real do cancelamento, não algo genérico.

<Warning>
  **Prazo legal.** O cancelamento de NF-e/NFC-e só é aceito pela SEFAZ dentro
  de uma janela de tempo após a autorização — de forma geral, **24 horas**,
  mas o prazo efetivo **varia por UF** e pode ser diferente para NFC-e ou
  para operações específicas (ex.: notas com transporte já iniciado). Depois
  do prazo, a SEFAZ rejeita o cancelamento e a correção do problema exige
  outros mecanismos (carta de correção, quando aplicável, ou nota
  complementar/de devolução). Confirme o prazo vigente para a UF da empresa
  antes de depender dele operacionalmente. Para NFS-e, o prazo e as regras de
  cancelamento são definidos pela prefeitura e variam por município.
</Warning>

<Note>
  Uma nota em `inContingent` (NFC-e em contingência offline) não pode ser
  cancelada até que a SEFAZ confirme a autorização definitiva — veja
  [Contingência](/pages/guides/contingencia).
</Note>

## Carta de correção (CC-e)

A carta de correção regulariza dados **acessórios** de uma NF-e já autorizada,
sem cancelá-la — por exemplo, uma informação complementar incorreta ou uma
descrição de item mal escrita. É exclusiva de **NF-e**.

```
POST /v1/product-invoices/{id}/corrections
```

O corpo (`ProductInvoiceCorrectionLetterRequestDto`) exige o texto da carta:

```json theme={null}
{ "letter": "Correção do texto da informação complementar: onde se lê X, leia-se Y." }
```

`letter` é obrigatório. A API aceita a partir de 1 caractere, mas a **SEFAZ
exige de 15 a 1000 caracteres** no texto da correção (`xCorrecao`). Cada
chamada gera um novo **evento** de correção — para consultar ou baixar uma
carta específica:

| Operação                  | Endpoint                                                  |
| ------------------------- | --------------------------------------------------------- |
| PDF do evento de correção | `GET /v1/product-invoices/{id}/corrections/{eventId}/pdf` |
| XML do evento de correção | `GET /v1/product-invoices/{id}/corrections/{eventId}/xml` |

<Warning>
  **O que a carta de correção NÃO pode alterar.** Por definição legal, a CC-e
  serve apenas para dados que não afetam o cálculo do imposto nem identificam
  as partes da operação. Não é aceito para corrigir:

  * Valores da operação ou de itens (preço, quantidade, totais)
  * Tributos (bases de cálculo, alíquotas, valores de impostos)
  * Dados do destinatário (nome, CPF/CNPJ, endereço)
  * Datas de emissão ou de saída/entrada da mercadoria
  * CFOP, quando isso muda a natureza da operação

  Qualquer um desses casos exige **cancelamento** (dentro do prazo) seguido
  de nova emissão com os dados corretos — ou, se o prazo de cancelamento já
  passou, os mecanismos previstos em lei para essa situação (nota
  complementar, nota de devolução etc., conforme o caso). Consulte a
  legislação vigente ou seu contador para o tratamento correto.
</Warning>

<Note>
  **NFC-e e NFS-e não têm carta de correção.** Não existe endpoint
  equivalente para `consumer-invoices` nem para `service-invoices` — veja
  [Emissão de NFC-e](/pages/guides/emissao-nfce) e [Emissão de
  NFS-e](/pages/guides/emissao-nfse). Para esses modelos, um erro em nota
  autorizada só se resolve por cancelamento (dentro do prazo) seguido de
  nova emissão.
</Note>

## Inutilização de numeração

Formaliza junto à SEFAZ que uma faixa de números de uma série **não será
usada** — normalmente após uma quebra de sequência (ex.: uma nota falhou
antes de ser enviada e o número ficou "pulado", ou houve um erro que impediu
o envio de um lote de números reservados). É diferente de cancelamento:
cancelamento desfaz uma nota que **chegou a ser autorizada**; inutilização
formaliza que certos números **nunca chegaram a ser usados**.

| Modelo | Endpoint                                                                                              |
| ------ | ----------------------------------------------------------------------------------------------------- |
| NF-e   | `POST /v1/product-invoices/disablement`                                                               |
| NFC-e  | `POST /v1/consumer-invoices/disablement`                                                              |
| NFS-e  | Não disponível — inutilização é um mecanismo específico da SEFAZ (NF-e/NFC-e); não existe para NFS-e. |

Corpo da requisição (`SefazInvoiceDisablementEditingDto`):

| Campo           | Obrigatório | Descrição                                                                                  |
| --------------- | ----------- | ------------------------------------------------------------------------------------------ |
| `series`        | Sim         | Série cuja faixa será inutilizada.                                                         |
| `initialNumber` | Sim         | Primeiro número da faixa.                                                                  |
| `finalNumber`   | Sim         | Último número da faixa.                                                                    |
| `reason`        | Sim         | Justificativa — a SEFAZ exige de **15 a 255 caracteres** (a API já valida o mínimo de 15). |

```json theme={null}
{
  "series": 1,
  "initialNumber": 1050,
  "finalNumber": 1052,
  "reason": "Quebra de sequência por falha de comunicação antes do envio"
}
```

O resultado (`InvoiceDisablementResultDto`) traz o protocolo da SEFAZ e o
campo `status` (`DisabledInvoiceStatus`):

| `status`       | Significado                                                               |
| -------------- | ------------------------------------------------------------------------- |
| `inProcessing` | Em processamento — a inutilização foi enviada e aguarda retorno da SEFAZ. |
| `registered`   | Registrada — a SEFAZ confirmou a inutilização da faixa.                   |
| `rejected`     | Rejeitada pela SEFAZ (ex.: faixa já usada, série inexistente).            |
| `error`        | Erro no processamento da solicitação.                                     |

<Note>
  A inutilização só é aceita para números que **nunca foram transmitidos** à
  SEFAZ. Se algum número da faixa já corresponde a uma nota emitida (mesmo
  que rejeitada e reemitida sob outro número), a SEFAZ rejeita a
  inutilização — nesse caso, o caminho é o cancelamento da nota específica,
  não a inutilização da faixa.
</Note>

## Próximos passos

* Estados da nota e quando `canceled`/`disabled` acontecem: [Ciclo de vida da nota](/pages/guides/ciclo-de-vida-da-nota)
* Comportamento de cancelamento durante contingência: [Contingência](/pages/guides/contingencia)
* Payload completo de NF-e (onde `series`/`number` são definidos na emissão): [Emissão de NF-e](/pages/guides/emissao-nfe)
* Acompanhar o resultado dessas operações por webhook: [Eventos e payload](/pages/webhooks/eventos-e-payload)