# Estados

> El ciclo de vida de un DTE en la API de Simplo — los 9 estados públicos, desde borrador hasta el veredicto del SII.

El campo `estado` de un DTE avanza por este pipeline (los valores se
serializan exactamente como se muestran):

```
borrador → generado → firmado → enviando → procesando → aceptado
                                  │                   ↘ rechazado
                                  │                   ↘ con_reparos
                                  ↘ error_envio
```

## Los 9 estados

| `estado`      | Significado                                                       |
| ------------- | ----------------------------------------------------------------- |
| `borrador`    | Creado pero aún no firmado                                        |
| `generado`    | Documento construido, previo a la firma                           |
| `firmado`     | Firmado digitalmente; lo que retorna `emit`. Pendiente de envío   |
| `enviando`    | Aceptado por la plataforma, esperando procesamiento del SII       |
| `procesando`  | El SII recibió el envío; el veredicto final está pendiente        |
| `aceptado`    | Aceptado por el SII — el documento es tributariamente válido      |
| `rechazado`   | Rechazado por el SII — corrige la causa y emite un documento nuevo |
| `con_reparos` | Aceptado por el SII con observaciones                             |
| `error_envio` | El envío al SII falló de forma **definitiva** (no es un reintento pendiente) |

Los estados terminales son `aceptado`, `rechazado`, `con_reparos` y
`error_envio`.

> **`error_envio` corta tu polling:**
> `error_envio` es terminal y **no significa veredicto del SII**: el documento
> nunca llegó a ser evaluado. Se llega ahí cuando el envío fracasa sin
> recuperación — el caso típico es quedarse sin folios (CAF agotado) a la hora de
> enviar. Si tu bucle de polling sólo espera `aceptado`/`rechazado`/`con_reparos`,
> **no termina nunca**.
>
> El motivo viene en `sii_status.glosa` en texto libre, **no** como un `code`
> estructurado; `tracking` queda en `null`. Regístralo, alerta a un humano y
> resuelve la causa (subir CAF, revisar el certificado) antes de reintentar la
> emisión con una `Idempotency-Key` nueva.

Un DTE rechazado nunca se muta en el lugar: emites un documento nuevo (y normalmente
una nota de crédito si hay que corregir uno ya aceptado — ver
[Tipos de DTE](/referencia/tipos-de-dte/)).

## Cómo seguir el veredicto

```ts
const current = await simplo.dtes.retrieve(dte.id);
current.estado;             // 'procesando' | 'aceptado' | 'rechazado' | 'error_envio' | ...
current.tracking?.track_id; // track ID del envío al SII
```

Sigue el veredicto del SII vía `dte.tracking` (track ID del envío y
contadores) y `dte.sii_status` (respuesta fina del SII), con polling de
`GET /api/v1/billing/dte/{id}`. (La entrega de
[webhooks](/referencia/webhooks/) aún no está activa.)

Regla práctica: `emit` retorna con `firmado` — trata ese estado como "en
vuelo", persiste `dte.id`, y resuelve el estado final de forma asíncrona por
polling. No bloquees el flujo de tu usuario esperando la aceptación del SII.

---

Versión HTML: https://docs.simplo.cl/referencia/estados/ · Índice para agentes: https://docs.simplo.cl/llms.txt