# Statuses (/en/docs/emision/estados) ## The seven public statuses [#the-seven-public-statuses] ``` ┌───────────► rejected (terminal) │ queued ──► sent ──────┼───────────► reparo (terminal-ish; válido pero observado) │ │ │ └───────────► accepted ──► annulled (una NC lo anuló) │ └──► failed ──(retry)──► queued ``` The last column is membership in the [consumption ledger](/en/docs/referencia/consumo), not price: it says whether the document gets recorded there. On a flat plan that is a count, not a charge. | `status` | Meaning | Terminal | In the consumption ledger | | ---------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | ------------------------- | | `queued` | We have it. Assigning a folio (the pre-authorised sequential number the document must carry), building and signing the XML — a document in `queued` may not have a folio yet | no | no | | `sent` | Transmitted to the SII, Chile's tax authority; we have a `track_id` and we are polling | no | no | | `accepted` | The SII has the document and the data matches | **yes** | **yes** | | `reparo` | The SII has it but flagged discrepancies. Legally issued; worth a look | yes | yes | | `rejected` | The SII rejected it. Not a valid document; the folio is burned | **yes** | no | | `failed` | We could not build, sign or transmit it. Retriable | no | no | | `annulled` | A credit note with code 1 annulled it (ours or a counterparty's) | **yes** | already recorded | > **Trap — reparo is not a rejection, and you still care** > > A document in `reparo` is legally issued and recorded in the ledger: the SII has it. What it says is > that the data you declared does not match exactly what the SII calculated. Check it — it is usually a > total, and it usually shows up again as a difference when you close the period. ## How the SII's signals map [#how-the-siis-signals-map] Two SII layers produce these statuses: the **envelope** status (per upload, by `track_id`) and the **per-document** status (`getEstDte`, by RUT + type + folio + date + amount). We read both and publish a single `status`. | SII signal | Layer | Public status | Note | | ------------------------------------ | --------- | -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | upload accepted, `track_id` returned | envelope | `sent` | | | `REC` / `EPR` | envelope | `sent` | Envelope received / in process. `EPR` on its own does **not** mean the document was accepted | | `SOK` | envelope | `sent` | Schema OK; the per-document verdict is still pending | | `RCT`, `RFR`, `RSC`, `RCH`, `SRH` | envelope | `rejected` | Rejection at the envelope level: its carátula (the header block), its schema, its signature. `rejection_reasons` carries the SII's code | | `DOK` (err 0) | document | **`accepted`** | *Document received by the SII, data matches.* The success state | | `DNK` (err 1) | document | `reparo` | Received, the data does not match. We re-query once with canonicalised parameters before publishing, so a `DNK` you see is a real discrepancy, not an artefact of the query | | `FAU` (err 3) | document | stays `sent` | Not at the SII yet; we keep polling | | `FNA` (err 4) | document | `rejected` | Document not authorised | | `FAN` (err 5) | document | `annulled` | Document annulled | | `EMP` (err 6) | document | `rejected` | Empresa not authorised to issue DTEs (*documentos tributarios electrónicos*, Chile's electronic tax documents) — an onboarding problem, which shows on the empresa too | | `TMD`/`TMC` (10/11) | document | `accepted` | A debit or credit note (ND/NC) modifies **text**; exposed as `sii.modified_by` | | `MMD`/`MMC` (12/13) | document | `accepted` | A debit or credit note modifies **amounts** | | `AND`/`ANC` (14/15) | document | `annulled` | A debit or credit note **annuls** it | | boleta `RPR` / `RLV` | document | `reparo` | Reparos from the boleta channel — the consumer-receipt DTE | | `001`/`002`/`003`, `-1`…`-4` | transport | no change | Token or transient errors. We re-authenticate and retry; you never see them | > **`EPR` does not mean accepted** > > It is the most common misreading of the SII. `EPR` means "envelope in process": the envelope arrived > and is being processed. The verdict that matters comes from the per-document layer, and the one you > want is `DOK`. ## A document's events [#a-documents-events] Every transition writes an event you can read and, if you have an endpoint, a webhook. ```bash curl https://api.facturia.cl/v1/documents/doc_01K2R7.../events \ -H "Authorization: Bearer $FACTURIA_KEY" -H "Facturia-Empresa: $EMPRESA" ``` ```json { "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" } } ] } ``` ## Rejection reasons [#rejection-reasons] Rejections come with a structured list, each entry carrying a stable Facturia code, the raw SII code and whether retrying might help. ```json "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 } ] ``` The codes you will run into most: | Facturia code | SII code | Cause | | ------------------------- | ---------------------------- | ---------------------------------------------------------------------------------------------------------------------- | | `schema_invalid` | `SCH-00001` | Envelope schema rejected | | `caratula_invalid` | `RCT` | Bad data in the carátula (often `FchResol` / `NroResol`) | | `ted_signature_invalid` | `TED-2-510` | The electronic stamp's signature does not match | | `field_invalid` | `HED-3-211` | A header field carries a value the SII rejects | | `signer_not_authorized` | upload estado 1 / `ESTADO 6` | The signing certificate is not an authorised user of the empresa | | `emisor_not_authorized` | `EMP` | Empresa not authorised to issue this document type | | `document_not_authorized` | `FNA` | Folio outside an authorised CAF (*código de autorización de folios*, the SII-signed block of folios), or a revoked CAF | | `totals_mismatch` | `DNK` | The amounts you sent differ from the ones the SII calculated | The full dictionary is in [Errors · Codes](/en/docs/errores/codigos), with a machine-readable copy at `GET /v1/error_codes` (no authentication). ## Polling vs. webhooks [#polling-vs-webhooks] Webhooks are the intended integration. If you have to poll anyway: * Do not call `GET /v1/documents/{document_id}` more often than every **10 seconds** for the first 2 minutes, then every 60 seconds. Typical time to a terminal status is 30 seconds to a few minutes; the SII can take hours during peaks or maintenance. * Better: query the list with `status=sent&created_at[gte]=…` once a minute and reconcile in bulk. * The `Facturia-Poll-After` header on the document response tells you the next useful moment, derived from our own scheduler.