¿Qué es un DTE? Los documentos tributarios electrónicos de Chile, explicados
Una guía para desarrolladores sobre el sistema de DTE en Chile: los ocho tipos de documento, folios y CAF, el timbre (TED), la firma, el ciclo de vida ante el SII y los errores que rompen las integraciones.
Si vendes algo en Chile, emites DTE. Cada factura, boleta y nota de crédito viaja a la autoridad tributaria como un archivo XML firmado. Para quienes desarrollan, es uno de esos dominios que parecen "generar un XML y hacer un POST" y resultan ser una cadena de reglas contables y criptográficas, donde una diferencia de redondeo de un peso o un archivo vencido lo detiene todo. Este artículo explica el sistema desde el punto de vista de un desarrollador: qué es un DTE, qué tipos vas a encontrar, el ciclo de vida por el que pasa cada documento y los errores que atrapan a la mayoría de las integraciones.
¿Qué es un DTE?#
Un DTE (Documento Tributario Electrónico) es un documento tributario emitido de forma electrónica: un archivo XML, firmado por el emisor, que el SII (Servicio de Impuestos Internos) recibe y valida. La facturación electrónica es obligatoria para las empresas en Chile, así que para la mayoría los DTE no son opcionales: son, simplemente, la forma de documentar las ventas.
La idea más importante es que el XML es el documento. El PDF que le envías por correo a un cliente, o la boleta que se imprime en la caja, es solo una representación. Esa representación lleva un código de barras con un resumen firmado del original, para que cualquiera pueda comprobar que el papel coincide con lo que se informó.
Cada DTE se identifica por tres valores: el RUT del emisor, el tipo de documento y el folio. El SII no acepta dos documentos que compartan los tres.
Los ocho tipos de documento que vas a encontrar#
Cada tipo tiene un código numérico, y la mayoría de las integraciones solo usa unos pocos:
| Código | Documento | Cuándo se usa |
|---|---|---|
| 33 | Factura electrónica | Ventas afectas a otras empresas |
| 34 | Factura no afecta o exenta electrónica | Ventas exentas de IVA |
| 39 | Boleta electrónica | Ventas a consumidores finales |
| 41 | Boleta exenta electrónica | Ventas exentas a consumidores finales |
| 46 | Factura de compra electrónica | La emite el comprador cuando el vendedor no puede |
| 52 | Guía de despacho electrónica | Traslado de mercadería, con o sin venta |
| 56 | Nota de débito electrónica | Aumentar o corregir un documento anterior |
| 61 | Nota de crédito electrónica | Anular, rebajar o corregir un documento anterior |
Las facturas muestran precios netos y suman el 19% de IVA; las boletas muestran precios con el IVA ya incluido. Las notas de crédito y débito nunca van solas: deben referenciar el documento que modifican.
El ciclo de vida de un DTE#
Todo documento, sea del tipo que sea, pasa por las mismas cinco etapas.
1. Folios y el CAF. No puedes numerar documentos libremente. El SII autoriza folios por rangos, por tipo de documento, emitiendo un CAF (Código de Autorización de Folios): un archivo XML con el rango, tu RUT, la firma del SII y una llave privada. Esa llave es la que prueba que cada folio que usas fue autorizado.
2. El TED. Cada documento lleva un TED (Timbre Electrónico DTE), un pequeño bloque que resume los campos clave (RUT, tipo, folio, fecha, total, primer ítem), incluye el CAF y se firma con la llave privada del CAF. El TED es lo que se imprime como código de barras PDF417.
3. La firma. Luego el documento completo se firma con XMLDSig usando un certificado digital emitido a una persona autorizada para firmar por la empresa. El TED prueba el folio; la firma prueba quién lo emitió.
4. El envío. Los documentos firmados viajan en un sobre llamado EnvioDTE. Antes de subirlo, el cliente se autentica con el mismo certificado firmando una semilla que entrega el SII y canjeándola por un token. El SII responde con un track id.
5. La aceptación. Recibir un envío no es aceptarlo. El SII valida de forma asíncrona el esquema, las firmas, el TED y sus reglas de negocio, y cada documento termina aceptado, aceptado con reparos o rechazado. Recién ahí el documento está realmente emitido.
Errores comunes#
Redondear el IVA línea por línea#
Los montos de un DTE son pesos enteros, y el IVA se calcula sobre el neto total, no por línea. Toma dos líneas de $2.450 netos cada una. Redondear el IVA por línea da 465,5 → 466 dos veces, o sea 932. Calcularlo sobre el neto total de $4.900 da 931. Un peso de diferencia basta para que la validación del SII observe el documento, y solo aparece con ciertos precios, por eso sobrevive a las pruebas.
import { calculateTotals } from 'dte-sdk'
calculateTotals([
{ name: 'Soporte mensual', quantity: 1, unitPrice: 2450 },
{ name: 'Hosting mensual', quantity: 1, unitPrice: 2450 },
])
// { net: 4900, exempt: 0, vatRate: 19, vat: 931, total: 5831 }Redondea el monto de cada línea a pesos enteros, súmalos y calcula el IVA una sola vez sobre el neto total. Nunca dejes que montos con decimales de punto flotante lleguen al XML.
Dejar vencer un CAF#
Los CAF tienen fecha de vencimiento. Hay equipos que piden un rango generoso, usan una parte y meses después descubren que los folios restantes ya no sirven. Ajusta tus solicitudes a tu volumen real, vigila la fecha de vencimiento y pide el siguiente CAF antes de que el actual se quede sin folios o sin tiempo.
Enviar al ambiente equivocado#
El SII opera un ambiente de certificación para pruebas y uno de producción para documentos reales, y no comparten nada: un CAF de certificación no sirve en producción. El error caro es el inverso: los documentos de prueba enviados a producción son documentos tributarios reales. Haz que el ambiente sea un parámetro explícito en cada llamada, nunca un valor por defecto.
Mezclar codificaciones#
El SII trabaja en ISO-8859-1. Una dirección como "Huérfanos" codificada en UTF-8 en un paso y en ISO-8859-1 en otro produce, en el mejor caso, texto ilegible y, en el peor, una firma inválida, porque la firma cubre los bytes exactos. Elige una codificación en el borde y mantenla.
Confundir "recibido" con "aceptado"#
Un track id significa que el envío llegó, nada más. Guárdalo junto al folio, consulta el estado hasta que se resuelva y recién entonces entrega el documento al cliente.
Cómo lo modela dte-sdk#
dte-sdk asigna una función a cada etapa del ciclo de vida, y sus tipos siguen el mismo orden: no puedes firmar un documento sin timbrar, ni enviar uno sin firmar.
import { createDte, stampDte, signDte, sendToSii, getStatus } from 'dte-sdk'
const dte = createDte({ type: 33, folio: 1024, issuer, receiver, items })
const stamped = stampDte(dte, caf) // TED, signed with the CAF key
const signed = await signDte(stamped, certificate) // XMLDSig with your certificate
const { trackId } = await sendToSii(signed, {
certificate,
environment: 'certification',
senderRut: '15.234.567-4',
resolution: { number: 0, date: '2026-09-01' },
})
const status = await getStatus(trackId, {
certificate,
environment: 'certification',
issuerRut: '76.123.456-0',
})createDte() valida RUT y montos y calcula los totales con las reglas de redondeo de arriba, así que la mayoría de los errores aparecen como un DteError tipado en tu código en vez de un rechazo del SII. stampDte() verifica que el folio esté dentro del rango del CAF, que el CAF corresponda al tipo de documento y al emisor, y que no esté vencido. environment no tiene valor por defecto. Los mensajes de error nunca incluyen RUT, montos, llaves ni contraseñas, así que es seguro registrarlos.
dte-sdk está en versión preliminar: la 0.0.2 publicada es un
placeholder, y el código de arriba muestra la API planificada para la 1.0,
que todavía puede cambiar.
Para seguir leyendo#
- Conceptos clave: tipos de documento, CAF, TED, certificados y estados del SII en más detalle
- Inicio rápido: emite una factura tipo 33 de punta a punta
calculateTotals(): cómo se calculan exactamente neto, exento, IVA y totalstampDte(): folios, validaciones del CAF y el TED- Ejemplo de nota de crédito: referencias y anulación de una factura
- Seguridad: manejo de llaves del CAF, certificados y datos personales