Estados
Los siete estados públicos, cómo se mapean las dos capas de señales del SII, y qué significa cada rechazo.
Los siete estados públicos
┌───────────► rejected (terminal)
│
queued ──► sent ──────┼───────────► reparo (terminal-ish; válido pero observado)
│ │
│ └───────────► accepted ──► annulled (una NC lo anuló)
│
└──► failed ──(retry)──► queuedstatus | Significado | Terminal | Facturable |
|---|---|---|---|
queued | Lo tenemos, con folio asignado, armando y firmando el XML | no | no |
sent | Transmitido al SII; tenemos un track_id y estamos consultando | no | no |
accepted | El SII tiene el documento y los datos coinciden | sí | sí |
reparo | El SII lo tiene pero marcó discrepancias. Legalmente emitido; conviene revisar | sí | sí |
rejected | El SII lo rechazó. No es un documento válido; el folio se quemó | sí | no |
failed | No pudimos armarlo, firmarlo o transmitirlo. Reintentable | no | no |
annulled | Una nota de crédito con código 1 lo anuló (nuestra o de una contraparte) | sí | ya facturado |
Trampa
reparo no es un rechazo, y aun así te importa
Un documento en reparo está legalmente emitido y es facturable: el SII lo tiene. Lo que dice es que
los datos que declaraste no coinciden exactamente con lo que el SII calculó. Revísalo — normalmente
es un total, y normalmente aparece de nuevo como diferencia al cerrar el período.
Cómo se mapean las señales del SII
Dos capas del SII producen estos estados: el estado del sobre (por subida, por track_id) y el
estado por documento (getEstDte, por RUT + tipo + folio + fecha + monto). Consultamos ambas y
publicamos un solo status.
| Señal SII | Capa | Estado público | Nota |
|---|---|---|---|
subida aceptada, track_id devuelto | sobre | sent | |
REC / EPR | sobre | sent | Envío recibido / en proceso. EPR por sí solo no significa que el documento fue aceptado |
SOK | sobre | sent | Esquema OK; el veredicto por documento sigue pendiente |
RCT, RFR, RSC, RCH, SRH | sobre | rejected | Rechazo a nivel de sobre (carátula, esquema, firma). rejection_reasons lleva el código del SII |
DOK (err 0) | documento | accepted | Documento recibido por el SII, datos coinciden. El estado de éxito |
DNK (err 1) | documento | reparo | Recibido, los datos no coinciden. Volvemos a consultar una vez con los parámetros canonicalizados antes de publicar, así que un DNK que ves es una discrepancia real, no un artefacto de la consulta |
FAU (err 3) | documento | sigue en sent | Todavía no está en el SII; seguimos consultando |
FNA (err 4) | documento | rejected | Documento no autorizado |
FAN (err 5) | documento | annulled | Documento anulado |
EMP (err 6) | documento | rejected | Empresa no autorizada a emitir DTE — un problema de puesta en marcha, que también se refleja en la empresa |
TMD/TMC (10/11) | documento | accepted | Existe una ND/NC que modifica texto; se expone en sii.modified_by |
MMD/MMC (12/13) | documento | accepted | Existe una ND/NC que modifica montos |
AND/ANC (14/15) | documento | annulled | Una ND/NC lo anula |
boleta RPR / RLV | documento | reparo | Reparos del canal de boletas |
001/002/003, -1…-4 | transporte | sin cambio | Errores de token o transitorios. Reautenticamos y reintentamos; nunca los ves |
`EPR` no significa aceptado
Es el error de lectura más común contra el SII. EPR es «envío en proceso»: el sobre llegó y se está
procesando. El veredicto que importa es el de la capa por documento, y el que buscas es DOK.
Los eventos de un documento
Cada transición escribe un evento que puedes leer y, si tienes un endpoint, un webhook.
curl https://api.facturia.cl/v1/documents/doc_01K2R7.../events \
-H "Authorization: Bearer $FACTURIA_KEY" -H "Facturia-Empresa: $EMPRESA"{
"object": "list",
"data": [
{ "type": "document.created", "at": "2026-08-14T13:04:11Z", "detail": { "folio": 412 } },
{ "type": "document.sent", "at": "2026-08-14T13:04:19Z", "detail": { "track_id": "0252083112" } },
{ "type": "document.accepted", "at": "2026-08-14T13:06:55Z", "detail": { "estado": "DOK", "num_atencion": "8812394" } }
]
}Motivos de rechazo
Los rechazos traen una lista estructurada, cada entrada con un código estable de Facturia, el código crudo del SII y si reintentar podría ayudar.
"rejection_reasons": [
{
"code": "ted_signature_invalid",
"sii_code": "TED-2-510",
"message": "Firma del timbre electrónico incorrecta",
"hint": "El DD del timbre fue alterado entre la firma y el envío.",
"retriable": false
}
]Los códigos que más te vas a encontrar:
| Código Facturia | Código SII | Causa |
|---|---|---|
schema_invalid | SCH-00001 | Esquema del sobre rechazado |
caratula_invalid | RCT | Datos de la carátula mal (frecuentemente FchResol / NroResol) |
ted_signature_invalid | TED-2-510 | Firma del timbre no coincide |
field_invalid | HED-3-211 | Un campo de cabecera lleva un valor que el SII rechaza |
signer_not_authorized | envío estado 1 / ESTADO 6 | El certificado firmante no es usuario autorizado de la empresa |
emisor_not_authorized | EMP | Empresa no autorizada a emitir este tipo de documento |
document_not_authorized | FNA | Folio fuera de un CAF autorizado, o CAF revocado |
totals_mismatch | DNK | Los montos enviados difieren de los que calculó el SII |
El diccionario completo está en Errores · Códigos, con una copia legible por
máquina en GET /v1/error_codes (sin autenticación).
Polling vs. webhooks
Los webhooks son la integración prevista. Si igual tienes que hacer polling:
- No consultes
GET /v1/documents/{document_id}más seguido que cada 10 segundos durante los primeros 2 minutos, y luego cada 60 segundos. El tiempo típico a un estado terminal es de 30 segundos a unos pocos minutos; el SII puede tardar horas en peaks o mantención. - Mejor: consulta el listado con
status=sent&created_at[gte]=…una vez por minuto y reconcilia en bloque. - El header
Facturia-Poll-Afteren la respuesta del documento te dice el próximo momento útil, derivado de nuestro propio scheduler.