# Payloads: liquidación, compra y exportación > Payloads completos y verificados para los tipos de DTE 43 (liquidación-factura), 46 (factura de compra), 110 (factura de exportación), 111 y 112 (notas de exportación) — cada ejemplo fue emitido de verdad en el sandbox y aceptado. Las reglas por tipo están codificadas máquina-legibles en el contrato OpenAPI como unión discriminada por tipo_dte (EmitirDTERequestPorTipo). Los tipos comunes (33, 34, 39, 41, 52, 56, 61) están cubiertos en el [Quickstart](/comienza/quickstart/) y en [Tipos de DTE](/referencia/tipos-de-dte/). Esta página completa los cinco tipos restantes con **payloads completos y medidos**: cada ejemplo de esta página fue emitido tal cual contra `POST /api/v1/billing/dte` en el sandbox, llegó a estado `aceptado` (SII simulado, `estado_sii: "DOK"`) y su XML fue verificado. Los montos de respuesta que ves aquí son los que devolvió la API. Las reglas generales (header `Idempotency-Key` obligatorio, flujo asíncrono `firmado → aceptado`, polling con `GET /api/v1/billing/dte/{id}`) son las mismas de siempre — ver [Emisión](/referencia/emision/). > **Las reglas por tipo, máquina-legibles:** > Todo lo que esta página explica en prosa está codificado en el > [contrato OpenAPI](/referencia/contrato-openapi/) como **unión discriminada > por `tipo_dte`**: el schema `EmitirDTERequestPorTipo` de > [`/openapi.yaml`](/openapi.yaml) tiene una variante por tipo (las 12) que > declara los campos condicionales obligatorios (`tipo_doc_liq` en 43, > `ind_traslado` en 52, `referencias` en 56/61/111/112, `export_data` en > 110-112, `ind_servicio` en boletas) y la semántica de precios > (`x-simplo-price-semantics`: bruto en boletas, neto en el resto). Donde el > sandbox es más permisivo que el SII real, la variante lo dice en > `x-simplo-sandbox-leniency`. Si tu integración valida contra el schema, > estas reglas se aplican solas. ## 43 — Liquidación-factura La emite un consignatario/comisionista al **mandante** (el receptor). Dos reglas propias del tipo, ambas validadas por la API: - **Cada línea de `detalle` requiere `tipo_doc_liq`** — el código del tipo de documento que se está liquidando (ej. `"33"` facturas, `"39"` boletas). Omitirlo responde `400 LIQUIDACION_TPO_DOC_LIQ_REQUERIDO`. - **`comisiones` exige `tipo_movim` `"C"` (comisión) u `"O"` (otros cargos), con `glosa`.** Otro valor responde `400 LIQUIDACION_COMISION_INVALIDA`. El total del documento **descuenta las comisiones**: `monto_total = neto + IVA − (val_com_neto + val_com_exe + val_com_iva)`. ```bash curl -X POST https://api.simplo.cl/api/v1/billing/dte \ -H "X-Api-Key: $SIMPLO_API_KEY" \ -H "Content-Type: application/json" \ -H "Idempotency-Key: $(uuidgen)" \ -d '{ "tipo_dte": 43, "receptor": { "rut": "76543210-3", "razon_social": "COMERCIAL MANDANTE SPA", "giro": "VENTA AL POR MAYOR", "direccion": "AVENIDA PRINCIPAL 100", "comuna": "SANTIAGO", "ciudad": "SANTIAGO" }, "detalle": [ { "tipo_doc_liq": "33", "nombre": "Ventas del período por cuenta del mandante", "cantidad": 1, "precio": 500000 } ], "comisiones": [ { "tipo_movim": "C", "glosa": "Comisión de venta 10%", "tasa_comision": 10, "val_com_neto": 50000, "val_com_exe": 0, "val_com_iva": 9500 } ] }' ``` Resultado medido: `201` con `estado: "firmado"`, y al consultar el detalle tras la aceptación: `monto_neto: 500000`, `iva: 95000`, `monto_total: 535500` (595.000 − 59.500 de comisiones). En el XML el documento va como ``, cada línea lleva ``, la sección `` detalla cada movimiento y `Totales` incluye el resumen `` con `ValComNeto`/`ValComIVA`. ## 46 — Factura de compra La emite el **comprador**; el `receptor` es el **proveedor** al que le compras. El caso típico es retención total de IVA (cambio de sujeto): declara `impuestos_retenciones` con `tipo_imp: 15` y la tasa — la API calcula la retención sobre el neto y la **descuenta del total**. ```bash curl -X POST https://api.simplo.cl/api/v1/billing/dte \ -H "X-Api-Key: $SIMPLO_API_KEY" \ -H "Content-Type: application/json" \ -H "Idempotency-Key: $(uuidgen)" \ -d '{ "tipo_dte": 46, "receptor": { "rut": "77112223-K", "razon_social": "AGRICOLA PROVEEDOR LIMITADA", "giro": "CULTIVO DE CEREALES", "direccion": "CAMINO RURAL KM 12", "comuna": "MELIPILLA", "ciudad": "MELIPILLA" }, "detalle": [ { "nombre": "Compra de trigo a productor primario", "cantidad": 100, "precio": 1200, "unidad": "QQM" } ], "impuestos_retenciones": [ { "tipo_imp": 15, "tasa_imp": 19 } ] }' ``` Resultado medido: `monto_neto: 120000`, `iva: 22800`, y como el IVA queda **totalmente retenido** (`tipo_imp: 15`), `monto_total: 120000` — igual al neto. En el XML, `Totales` lleva el bloque `` con `TipoImp 15 / TasaImp 19 / MontoImp 22800`. ## 110 — Factura de exportación Documento **exento** con moneda extranjera y datos de aduana en `export_data`. Reglas medidas: - **`precio` va en la moneda del documento** (entero — ej. `12` = USD 12). El total sale en `monto_exento`/`monto_total` en esa moneda; el IVA es 0. - **`tpo_moneda` usa los nombres de la tabla de monedas de Aduana del SII**: `"DOLAR USA"`, `"EURO"`, `"LIBRA EST"`, `"YEN"`, … Un código ISO como `"USD"` responde `400 EXPORT_MONEDA_INVALIDA`. - **Incluye siempre `tpo_cambio`** (pesos por unidad de la moneda). Con él, el XML lleva el bloque `` con el total en `PESO CL` (`MntTotOtrMnda`) que el SII real exige para cuadrar el encabezado. ⚠️ El **sandbox acepta** una exportación en moneda extranjera **sin** `tpo_cambio` (medido: `201`), pero el **SII real rechaza** ese documento («Encabezado No Cuadra»). No omitas el campo porque el sandbox te lo permita. - Los campos de aduana aceptan **etiqueta o código numérico**: `clausula_venta: "CIF"` → `CodClauVenta 1` (una cláusula desconocida responde `400 EXPORT_CLAUSULA_INVALIDA`), `pais_recep: "USA"` → `CodPaisRecep 225`, `puerto_embarque: "SAN ANTONIO"` → `CodPtoEmbarque 906`. Un puerto que no está en la tabla (ej. `"MIAMI"`) viaja como texto libre en `IdAdicPtoDesemb`. - Para el receptor extranjero usa el RUT genérico `55555555-5`. ```bash curl -X POST https://api.simplo.cl/api/v1/billing/dte \ -H "X-Api-Key: $SIMPLO_API_KEY" \ -H "Content-Type: application/json" \ -H "Idempotency-Key: $(uuidgen)" \ -d '{ "tipo_dte": 110, "receptor": { "rut": "55555555-5", "razon_social": "OVERSEAS TRADING LLC", "giro": "IMPORTACION DE ALIMENTOS", "direccion": "1200 HARBOR BLVD, MIAMI FL", "ciudad": "MIAMI" }, "detalle": [ { "nombre": "Cajas de arándanos frescos 2,5 kg", "cantidad": 500, "precio": 12 } ], "export_data": { "tpo_moneda": "DOLAR USA", "tpo_cambio": 945.3, "modalidad_venta": 1, "clausula_venta": "CIF", "total_clausula": 6000, "via_transporte": 1, "puerto_embarque": "SAN ANTONIO", "puerto_desembarque": "MIAMI", "pais_recep": "USA", "pais_dest": "USA", "peso_bruto": 1350.5, "unidad_peso_bruto": 6, "tipo_bulto": "PALLET", "total_bultos": 25 } }' ``` Resultado medido: `monto_exento: 6000`, `monto_total: 6000` (USD), `iva: 0`. El XML sale bajo `` con el bloque `` (códigos ya mapeados) y `` `TpoCambio 945.3` / `MntTotOtrMnda 5671800`. ## 111 y 112 — Notas de débito y crédito de exportación Igual que 56/61, **requieren `referencias`** (omitirlas responde `400 "referencia is required for document type 111"`), y como todo documento de exportación llevan `export_data` con `tpo_moneda` y `tpo_cambio`. Emite primero la 110 y referencia su **folio y fecha reales**. Nota de débito de exportación (111) — cargo adicional sobre la 110: ```bash curl -X POST https://api.simplo.cl/api/v1/billing/dte \ -H "X-Api-Key: $SIMPLO_API_KEY" \ -H "Content-Type: application/json" \ -H "Idempotency-Key: $(uuidgen)" \ -d '{ "tipo_dte": 111, "receptor": { "rut": "55555555-5", "razon_social": "OVERSEAS TRADING LLC", "giro": "IMPORTACION DE ALIMENTOS", "direccion": "1200 HARBOR BLVD, MIAMI FL", "ciudad": "MIAMI" }, "detalle": [ { "nombre": "Flete marítimo adicional no facturado", "cantidad": 1, "precio": 350 } ], "referencias": [ { "tipo_doc_ref": "110", "folio_ref": 1042, "fecha_ref": "2026-09-02", "codigo_ref": 3, "razon_ref": "Corrige monto: flete adicional" } ], "export_data": { "tpo_moneda": "DOLAR USA", "tpo_cambio": 945.3 } }' ``` Nota de crédito de exportación (112) — devolución parcial sobre la 110: ```bash curl -X POST https://api.simplo.cl/api/v1/billing/dte \ -H "X-Api-Key: $SIMPLO_API_KEY" \ -H "Content-Type: application/json" \ -H "Idempotency-Key: $(uuidgen)" \ -d '{ "tipo_dte": 112, "receptor": { "rut": "55555555-5", "razon_social": "OVERSEAS TRADING LLC", "giro": "IMPORTACION DE ALIMENTOS", "direccion": "1200 HARBOR BLVD, MIAMI FL", "ciudad": "MIAMI" }, "detalle": [ { "nombre": "Devolución 40 cajas arándanos dañadas", "cantidad": 40, "precio": 12 } ], "referencias": [ { "tipo_doc_ref": "110", "folio_ref": 1042, "fecha_ref": "2026-09-02", "codigo_ref": 3, "razon_ref": "Corrige monto: devolución parcial" } ], "export_data": { "tpo_moneda": "DOLAR USA", "tpo_cambio": 945.3 } }' ``` Resultados medidos: 111 → `monto_total: 350`; 112 → `monto_total: 480` (40 × 12), ambos `aceptado`, ambos con la `` al folio real de la 110 y su bloque `` en el XML. Reemplaza `folio_ref: 1042` y `fecha_ref` por el folio y la fecha que te devolvió la emisión de tu 110. Dos comportamientos medidos que debes conocer: - **Una 111 que referencia una 112 con `codigo_ref: 3` es rechazada**: `400 REFERENCIA_CODIGO_INVALIDO` («use codigo_ref=1») — para anular una nota de crédito de exportación referencia con `codigo_ref: 1`. - **La API verifica que el folio de exportación referenciado exista**, igual que en 56/61: una 111/112 apuntando a un folio 110 inexistente de tu empresa responde `400 REFERENCIA_INVALIDA` (el SII real la rechazaría con `REF-3-750`, quemando el folio). Mismo alcance que 56/61: solo se verifican referencias a tipos electrónicos gestionados por Simplo; documentos emitidos fuera de Simplo (p. ej. pre-migración) no son verificables y pasan sin chequear. ## Errores propios de estos tipos (medidos) | `code` | Status | Cuándo | | ----------------------------------- | ------ | ----------------------------------------------------------------------- | | `LIQUIDACION_TPO_DOC_LIQ_REQUERIDO` | 400 | Tipo 43 con alguna línea de `detalle` sin `tipo_doc_liq` | | `LIQUIDACION_COMISION_INVALIDA` | 400 | Tipo 43 con comisión sin `glosa` o con `tipo_movim` distinto de `C`/`O` | | `EXPORT_MONEDA_INVALIDA` | 400 | `tpo_moneda` fuera de la tabla de Aduana (ej. `"USD"`) | | `EXPORT_CLAUSULA_INVALIDA` | 400 | `clausula_venta` que no es cláusula Incoterm de Aduana ni código | | `REFERENCIA_CODIGO_INVALIDO` | 400 | 111 referenciando una 112 con `codigo_ref: 3` | | `REFERENCIA_INVALIDA` | 400 | 56/61/111/112 referenciando un tipo+folio que no existe para tu empresa | | `BAD_REQUEST` (referencia) | 400 | 111/112 sin `referencias` | ## Relacionado - [Tipos de DTE](/referencia/tipos-de-dte/) — los 12 tipos y sus requisitos - [Emisión](/referencia/emision/) — endpoint, idempotencia y flujo asíncrono - [Estados](/referencia/estados/) — ciclo de vida hasta `aceptado` - [Errores](/referencia/errores/) — clases de error y reintentos --- Versión HTML: https://docs.simplo.cl/referencia/payloads-por-tipo/ · Índice para agentes: https://docs.simplo.cl/llms.txt