El rechazo DTE SII rara vez es un misterio: casi siempre nace de un puñado de errores estructurales en el XML que se pueden detectar antes de enviar. Un DTE es un XML firmado digitalmente, y el SII valida tanto su forma como la coherencia interna entre el encabezado, los totales y el TED. Cuando uno de esos bloques no cuadra, el documento se rechaza. Acá están las causas más comunes y cómo anticiparlas.
Las cuatro causas más frecuentes de rechazo DTE SII
1. Folio fuera del rango del CAF
El CAF (Código de Autorización de Folios) que entrega el SII define un rango RNG con un folio desde (D) y un folio hasta (H). El folio del documento (F) debe estar dentro de [D, H]. Si emites con un folio agotado, repetido o que pertenece a otro CAF, el documento no es válido.
Además, el CAF no solo acota el rango: contiene el RUT del emisor y el tipo de DTE para el que fue autorizado. Usar un CAF de boleta (39) para timbrar una factura (33), o un CAF de otro RUT, produce un rechazo aunque el folio esté dentro del rango numérico.
2. Dígito verificador del RUT inválido
El RUT emisor (RE) y el RUT receptor (RR) deben tener su dígito verificador correcto según el algoritmo módulo 11 (factores 2 a 7 cíclicos; resultado 11 → "0", 10 → "K"). Un dígito mal calculado o un RUT mal tipeado —un cero de más, una K donde va un número— invalida el documento. Es uno de los errores más triviales de corregir y, a la vez, de los más comunes.
3. Totales descuadrados
En el bloque de Totales del encabezado, la aritmética tiene que cerrar:
neto + IVA + exento = total
IVA ≈ neto × 19%
Si el IVA viene mal calculado, si el exento no se suma al total, o si hay redondeos que no respetan la regla, el SII detecta la inconsistencia. Esto suele pasar cuando los totales se arman a mano o cuando el detalle (la suma de los ítems) no coincide con el monto neto declarado en el encabezado.
4. TED inconsistente con el encabezado
El TED (Timbre Electrónico) es lo que se codifica en el PDF417 de la representación impresa, y dentro lleva el bloque DD (Datos del Documento): RUT emisor (RE), tipo de DTE (TD), folio (F), fecha de emisión (FE), RUT receptor (RR), razón social del receptor (RSR), monto total (MNT), el primer ítem (IT1), el CAF y el timestamp (TSTED). Todo eso lo firma el emisor en el FRMT con SHA1withRSA.
El problema aparece cuando el TED y el encabezado no dicen lo mismo. Si el MNT del DD no coincide con el total del encabezado, o el F del TED difiere del folio del IdDoc, o el RE no es el mismo RUT del emisor, el documento queda inconsistente. El timbre debe ser un espejo exacto del encabezado.
Cómo detectarlas antes de enviar
Estas cuatro causas comparten algo: todas son verificables leyendo el XML, sin necesidad de mandarlo al SII. Una validación estructural revisa:
| Chequeo | Qué confirma |
|---|---|
| XML bien formado | El archivo abre y parsea sin errores |
| TED presente con su DD | Existe el timbre y sus campos obligatorios |
| DV del RUT (módulo 11) | RUT emisor y receptor son válidos |
| Consistencia DD ↔ CAF | Mismo RUT emisor y tipo de DTE |
| Folio dentro del rango | D ≤ F ≤ H |
| TED concuerda con encabezado | RUT, tipo, folio y monto coinciden |
| Totales cuadran | neto + IVA + exento = total; IVA ≈ neto × 19% |
Un detalle técnico que arruina muchas revisiones manuales: los XML de DTE suelen venir en ISO-8859-1, no en UTF-8. Si los abres como UTF-8, los acentos se rompen y la razón social del TED deja de coincidir visualmente con la del encabezado, generando falsas alarmas. Cualquier validación seria parte por leer el archivo con el encoding correcto.
Valida antes de emitir
La forma más barata de evitar un rechazo es revisar el XML antes de enviarlo, idealmente primero en el ambiente de certificación del SII y recién después en producción. Puedes correr todos los chequeos de arriba sobre tu archivo con el validador de XML DTE de Emitir: es gratis, corre en tu navegador y el XML no se sube a ningún servidor.
¿Quieres emitir DTE directo desde tu backend, con estas validaciones ya integradas? Súmate a la lista de espera.
Preguntas frecuentes
¿Por qué el SII me rechaza una factura electrónica?+
El SII rechaza un DTE cuando el XML no cumple sus validaciones: por ejemplo, un folio fuera del rango [D,H] que autoriza el CAF, un Timbre Electrónico (TED) con firma inválida, un RUT con dígito verificador incorrecto o problemas de codificación del archivo. El documento debe estar firmado y estructurado según el formato que exige el Servicio de Impuestos Internos.
¿Qué es el CAF y por qué causa rechazos de DTE?+
El CAF (Código de Autorización de Folios) lo entrega el SII y define un rango de folios RNG [D,H], la llave pública RSA del emisor (RSAPK) y la firma del SII (FRMA). Si el folio del documento queda fuera de ese rango [D,H], o usas un CAF que no corresponde al tipo de DTE, el Servicio de Impuestos Internos rechaza la emisión.
¿Por qué falla el Timbre Electrónico (TED) de mi DTE?+
El TED falla cuando su firma FRMT (SHA1withRSA del emisor) no valida correctamente sobre el bloque DD, que contiene RE, TD, F, FE, RR, RSR, MNT, IT1, CAF y TSTED. Cualquier diferencia entre los datos timbrados y los del documento, o una firma mal generada, hace que el SII rechace el DTE. El TED se imprime como PDF417.
¿El dígito verificador del RUT puede hacer que rechacen un DTE?+
Sí. El SII valida el RUT del emisor y del receptor, y su dígito verificador se calcula con módulo 11 (donde 11 equivale a 0 y 10 a K). Si el DV está mal calculado o el RUT no corresponde a un contribuyente válido, el Servicio de Impuestos Internos rechaza el documento. Conviene verificar emisor y receptor antes de emitir.
¿Cómo pruebo un DTE antes de emitirlo en producción para evitar rechazos?+
El SII tiene dos ambientes: certificación, donde resuelves un set de pruebas, y producción. Primero validas tus DTE en certificación para detectar errores de estructura, folios o firma antes de operar en producción. Además, en Emitir puedes usar el validador de XML DTE (/validar-xml-dte), que revisa el archivo en tu navegador sin subirlo a ningún servidor.
¿Influye la codificación del archivo XML en el rechazo del DTE?+
Sí. Los XML de DTE suelen venir en ISO-8859-1, y si guardas o transformas el archivo en otra codificación pueden corromperse caracteres como acentos o la ñ, afectando la firma y la validación del SII. Para revisar tu documento sin riesgo, Emitir ofrece un conversor de XML DTE a PDF (/conversor-xml-dte-a-pdf) que procesa el archivo localmente.