# Document types (/en/docs/emision/tipos) ## The supported types [#the-supported-types] | `tipo_dte` | Document | Prices are | Notes | | ---------- | ------------------------------------------------------------------------------ | ------------------------ | --------------------------------------------------------- | | 33 | Factura electrónica (afecta) — the ordinary invoice, IVA (Chile's VAT) charged | net | Cedible | | 34 | Factura no afecta o exenta | net | Every line exempt | | 39 | Boleta electrónica (afecta) — what a consumer gets | **gross (IVA included)** | Receptor optional (`66666666-6`) | | 41 | Boleta exenta | **gross** | Receptor optional | | 46 | Factura de compra | net | You withhold the IVA. The `sfg` channel does not issue it | | 52 | Guía de despacho — the note that travels with the goods | net | Needs a `dispatch` block. Both channels issue it | | 56 | Nota de débito | net | Needs a reference | | 61 | Nota de crédito | net | Needs a reference | Not in v1: exportación (110/111/112), liquidación factura (43) and boleta de honorarios (an entirely different regime at the SII, Chile's tax authority). > **Boletas travel another road, and you never notice** > > Boletas (39/41) use a different transport from facturas — REST instead of SOAP, batched, with their own > token and their own certification. All of that is invisible to you: same endpoint, same fields, same > statuses. ## References [#references] A reference points at another document. Notas de crédito (61) and notas de débito (56) require one; everywhere else it is optional. ```json "references": [ { "tipo_dte": 33, "folio": 412, "date": "2026-08-14", "code": 3, "reason": "Corrige montos" } ] ``` | `code` | Meaning | | ------ | ----------------------------- | | `1` | Voids the referenced document | | `2` | Corrects text | | `3` | Corrects amounts | References to documents that are not DTEs (*documentos tributarios electrónicos*, Chile's electronic tax documents) — a purchase order, a contract — use the SII's `tipo_dte` codes in the 800 range and omit `code`: ```json "references": [ { "tipo_dte": 801, "folio": "OC-99213", "date": "2026-08-01", "code": null, "reason": "Orden de compra" } ] ``` `references[].date` is optional: when omitted, it takes the document's own `issue_date`. `references[].folio` accepts a number or a string; a number is converted to its decimal string, because `` is `xs:string` in the SII schema — a folio, the sequential number that identifies a document, could never be numeric when it reads `OC-99213`. ## Guía de despacho (52) [#guía-de-despacho-52] It needs a `dispatch` block. Both channels issue it: `sfg` (Portal MIPYME) through its form, and `mercado` through the certified engine, which writes the DTE's `IndTraslado` and its `Transporte` block. What changes between channels is not whether you can issue one, but which `dispatch` fields fit in each — at the end of this section. ```bash curl -sS https://api.facturia.cl/v1/documents \ -H "Authorization: Bearer $FACTURIA_KEY" -H "Facturia-Empresa: $EMPRESA" \ -H "Content-Type: application/json" \ -d '{ "tipo_dte": 52, "receptor": { "rut": "76543212-K", "address": { "street": "Ruta 5 Sur km 12", "comuna": "San Bernardo", "city": "Santiago" } }, "dispatch": { "transfer_type": "venta", "carrier": { "rut": "11111111-1", "plate": "KJHZ42", "driver_rut": "13456789-9", "driver_name": "Ana Rojas" }, "requester_rut": "76543212-K" }, "items": [{ "description": "Pallet de insumos", "quantity": 4, "unit_price": 120000 }] }' ``` `dispatch.transfer_type` is the SII's `IndTraslado`: it says what kind of movement the guía documents, and it is required (`422 dispatch_incomplete` when missing). There is no default: the SII's own form opens with "the operation constitutes a sale" already ticked, which is exactly what you do not want to inherit when you are moving stock between your own warehouses. | `transfer_type` | `IndTraslado` | What it is | | ---------------------- | ------------- | ---------------------------------- | | `venta` | 1 | The operation constitutes a sale | | `venta_por_efectuar` | 2 | Sales still to be made | | `consignacion` | 3 | Consignments | | `entrega_gratuita` | 4 | Free delivery | | `traslado_interno` | 5 | Internal transfers | | `otros` | 6 | Other transfers that are not sales | | `devolucion` | 7 | Return guía | | `traslado_exportacion` | 8 | Transfer for export (not a sale) | | `venta_exportacion` | 9 | Sale for export | Only `venta` and `venta_exportacion` are sales: in the rest the guía states the value of the goods for the purposes of the transfer and generates no tax debit. **The two channels behave differently about amounts.** On the `mercado` channel a zero or nominal amount is a legitimate document and we do not refuse it — the SII accepted exactly one (an internal-transfer guía for $0) on 2026-08-21. On the `sfg` channel every line must carry a price greater than 0 and the document must total more than 0, or the request is refused with `422 sfg_guia_zero_amount`: the portal validates its guía form with the *factura* validations, whatever the class of transfer, and says so in its own words — "Precio del primer item del detalle debe ser mayor a 0 … Valor Total Factura debe igual a la suma del Monto neto + IVA y mayor que 0". It is a rule of the portal, not of the tax, which is why it applies to one channel only. The transport block is optional (a guía the receptor collects itself names no carrier). `dispatch.destination` is a delivery address different from `receptor.address`. The `mercado` channel accepts it and writes it into the DTE's `Transporte` block. The `sfg` channel refuses it with `422 dispatch_not_available_for_channel`: the portal's guía form carries a single address, so a different destination could not be printed — put it in `receptor.address`. It takes the same object as `receptor.address` (`street` / `comuna` / `city`); the SII caps them at 70 / 20 / 20 characters, and anything longer is refused with `400 field_too_long`, never truncated. The RUTs in the `dispatch` block — `requester_rut`, `carrier.rut`, `carrier.driver_rut` — are stored in the SII's own form, so `76.123.456-7` or a lower-case check digit is accepted and normalised on the way in, exactly like `receptor.rut`. `dispatch.dispatch_type` is the SII's `TipoDespacho`: on whose account the goods are dispatched, and to whose premises they go. It is **optional** — unlike `transfer_type` it does not change what the document means, so a guía without it is a complete guía. | `dispatch_type` | `TipoDespacho` | What it is | | ------------------------- | -------------- | --------------------------------------------------------------------------------------------------------------------------- | | `receiver_account` | 1 | Dispatched on the account of the document's receptor: your customer, or the seller when the document is a factura de compra | | `issuer_to_customer_site` | 2 | On the emisor's account, to the customer's premises | | `issuer_to_other_site` | 3 | On the emisor's account, to other premises (delivery to a building site, a third party's warehouse) | The `mercado` channel writes it into the DTE's `IdDoc/TipoDespacho`. The `sfg` channel refuses it with `422 dispatch_not_available_for_channel`: the portal's guía form has a single transfer selector, the one for the class of movement, and no `TipoDespacho` field at all, so the value could not be printed. > **`dispatch.dispatch_type` changed vocabulary** > > It used to publish `emisor_propio` / `emisor_arrendado` / `receptor`, which said who owned the > *vehicle* moving the goods — a question the SII does not ask and that could not be written into any > field of the DTE, so the field was refused on both channels and never reached a document. It was > redefined on the SII's own semantics instead of publishing a second field; the three old values are > `400 invalid_field` today. To say who moves the goods, use `dispatch.carrier`. ## Nota de crédito (61) and nota de débito (56) [#nota-de-crédito-61-and-nota-de-débito-56] Standalone, that is, without going through the convenience endpoint: ```bash curl -sS https://api.facturia.cl/v1/documents \ -H "Authorization: Bearer $FACTURIA_KEY" -H "Facturia-Empresa: $EMPRESA" \ -H "Content-Type: application/json" \ -d '{ "tipo_dte": 61, "receptor": { "rut": "76543212-K", "giro": "Venta al por mayor de alimentos", "address": { "street": "Los Militares 5001, of. 302", "comuna": "Las Condes", "city": "Santiago" } }, "references": [{ "tipo_dte": 33, "folio": 412, "date": "2026-08-14", "code": 3, "reason": "Corrige montos" }], "items": [{ "description": "Ajuste de precio", "quantity": 1, "unit_price": 120000 }] }' ``` If what you want is to annul a factura, the shortcut is [`POST /v1/documents/{document_id}/credit_note`](/en/docs/emision/acciones#anular-un-documento). ## Factura de compra (46) [#factura-de-compra-46] You are the withholding agent. ```bash curl -sS https://api.facturia.cl/v1/documents \ -H "Authorization: Bearer $FACTURIA_KEY" -H "Facturia-Empresa: $EMPRESA" \ -H "Content-Type: application/json" \ -d '{ "tipo_dte": 46, "receptor": { "rut": "55555555-5", "legal_name": "Google Cloud EMEA Ltd", "foreign": true }, "items": [{ "description": "Google Ads — julio 2026", "quantity": 1, "unit_price": 1000000 }], "withholding": { "iva": "total" } }' ``` `55555555-5` is the SII's generic RUT — Chile's taxpayer id — for unregistered foreign suppliers. `withholding.iva: "total"` produces fully withheld IVA: the debit lands in code 39 of the F29 (the monthly tax return) and the credit in 519/520. Only `total` can be issued today: it is the only `` the engine knows how to declare. Sending `"partial"`, or a `rate` other than `19`, is refused with `422 withholding_not_supported`. The retención sits in `totals.other_taxes` as a **negative** number (for example `-1891` when the IVA withheld is `1891`) — the only way for `total = net + exempt + iva + other_taxes` to stay true on a document that withholds. The automation that spots these charges and proposes the document is in [Taxes · Tipo 46](/en/docs/impuestos/tipo-46). ## Boletas (39/41) and the anonymous consumer [#boletas-3941-and-the-anonymous-consumer] Boletas can go without a receptor. When there is none, the document goes to the anonymous end consumer `66666666-6` — a RUT that is valid in production too, and only for boletas. ```bash curl -sS https://api.facturia.cl/v1/documents \ -H "Authorization: Bearer $FACTURIA_KEY" -H "Facturia-Empresa: $EMPRESA" \ -H "Content-Type: application/json" \ -d '{"tipo_dte":39,"items":[{"description":"Café","quantity":2,"unit_price":2500}]}' ``` > **Trap — On a boleta, unit_price is gross** > > `prices_include_tax` is `true` by default for 39 and 41. The `2500` in the example is 2.500 pesos with > IVA included, not 2.500 plus IVA. If your system stores net prices, set > `"prices_include_tax": false` explicitly and we normalise. > > On a factura (33/34/56/61/46) it is the other way round: the SII's ``/`` is always > NET (`DTE_v10.xsd`: `MontoItem` is net unless `MntBruto` is present, which this API never sends). If you > send `"prices_include_tax": true` on a factura, the price is normalised DOWNWARD at the door: the > `items` we return, the PDF and the `` show the net price (`11990` → `10075.6303`), and the > total can land one peso away from the gross you quoted, because everything is computed from the > already-rounded net price.