Estás enviando un DTE al SII y el envío vuelve rechazado en la validación de schema con el mensaje "Invalid Character". No es un problema de tu folio, ni de tu giro, ni de los montos: es un problema de codificación de caracteres en el XML. Este es uno de los rechazos más frustrantes porque el documento se ve "bien" al abrirlo, pero el SII lo descarta antes de mirar siquiera la firma.
En esta guía explicamos por qué ocurre, por qué el SII exige ISO-8859-1 (y no UTF-8), qué entidades XML debes escapar y cómo solucionarlo de forma definitiva.
Qué significa "Invalid Character" en la validación de schema
Cuando envías un DTE, el SII valida el envío en un orden estricto:
- Validar Schema — la estructura del XML contra el esquema oficial.
- Validar Firma Digital — la firma electrónica del documento.
- Validar Timbre Electrónico (TED) — el timbre del SII.
El error "Invalid Character" ocurre en el paso 1. Significa que el parser del SII encontró un carácter que no puede interpretar dentro del texto del XML. Como el envío se detiene en schema, nunca llega a revisar tu firma ni tu TED, aunque ambos estén perfectos.
Hay dos causas que producen este rechazo, y conviene tratarlas por separado:
- Caracteres estructurales sin escapar (
&,<,>,",') dentro de un campo de texto. - Codificación incorrecta del archivo (UTF-8 en vez de ISO-8859-1), que corrompe acentos y eñes.
ISO-8859-1 vs UTF-8: por qué importa el set de caracteres
El instructivo técnico del SII define que los XML de DTE deben usar el set de caracteres ISO-8859-1 (también conocido como Latin-1). Esto no es opcional: acentos, eñes y caracteres especiales deben codificarse según ISO-8859-1.
El problema típico aparece cuando tu backend o tu editor guarda o transforma el XML en UTF-8. En UTF-8, una letra como á o ñ ocupa dos bytes; en ISO-8859-1 ocupa uno solo. Si la declaración del documento dice ISO-8859-1 pero los bytes están en UTF-8 (o viceversa), los acentos y la ñ se corrompen.
La declaración correcta en la cabecera del XML debe ser:
<?xml version="1.0" encoding="ISO-8859-1"?>Y los bytes del archivo deben estar realmente en ISO-8859-1, no solo declarados. Una declaración que no coincide con el contenido es una de las fuentes más comunes de rechazo.
El efecto colateral sobre la firma digital
Hay una consecuencia que muchos developers descubren tarde: la codificación afecta la firma. El digest de la firma digital se calcula sobre el string exacto del XML. Si generas el documento, lo firmas, y luego lo reabres o lo transformas a otra codificación —cambiando los bytes de un acento o de la ñ—, el digest deja de coincidir.
El resultado: aunque arregles el schema, el documento puede caer en el paso 2 (firma digital). Por eso la regla práctica es fijar la codificación ISO-8859-1 desde la generación del XML y no volver a tocar los bytes después de firmar.
Entidades XML predefinidas: la tabla del SII
Cinco caracteres tienen significado estructural en XML y no pueden aparecer literalmente dentro del texto de un campo. Deben reemplazarse por su entidad XML predefinida. Esta es la tabla exacta que define el SII:
| Carácter | Entidad (nombre) | Entidad (numérica) |
|---|---|---|
& |
& |
& |
< |
< |
< |
> |
> |
> |
" |
" |
" |
' |
' |
' |
Puedes usar cualquiera de las dos formas (nombre o numérica). El carácter más problemático en la práctica es el ampersand (&), porque aparece naturalmente en razones sociales.
Ejemplo exacto del SII
El propio SII usa este ejemplo. Una razón social escrita literalmente como:
Empresas A&B Limitada(21 caracteres) debe codificarse en el XML como:
Empresas A&B Limitada(25 caracteres). Fíjate que el & literal se transformó en &. Si lo dejas sin escapar, el parser interpreta &B como el inicio de una entidad inválida y dispara el rechazo "Invalid Character".
Lo mismo aplica a los demás caracteres. Un campo de glosa que contenga < o >:
<!-- INCORRECTO: rompe el schema -->
<DscItem>Perfil < 50mm</DscItem>
<!-- CORRECTO -->
<DscItem>Perfil < 50mm</DscItem>Cómo solucionarlo
- Declara y guarda en ISO-8859-1. Asegúrate de que la cabecera diga
encoding="ISO-8859-1"y que el archivo se escriba realmente con esa codificación, no solo que la declare. - Escapa las cinco entidades antes de armar el XML. Reemplaza
&,<,>,"y'por sus entidades en todos los campos de texto (razón social, glosas, direcciones, nombres). Hazlo a nivel de cada valor, no sobre el documento completo, para no escapar dos veces los símbolos que ya forman parte de la estructura. - Codifica acentos y eñes según ISO-8859-1. El resto de los caracteres especiales —acentos, eñes— se representan con el byte correspondiente de Latin-1.
- No transformes la codificación después de firmar. Genera, escapa, firma y envía sin reabrir el archivo en otro encoding.
- Valida antes de enviar. Revisa la estructura y la codificación del XML antes de mandarlo al SII.
Para ese último paso, puedes usar el validador de XML DTE de Emitir: revisa la estructura y el encoding del documento directamente en tu navegador, sin subir el XML a ningún servidor. Si quieres entender cómo se abre y se lee un XML de factura electrónica, revisa también cómo abrir un XML de factura electrónica, y si el rechazo no fuera por codificación, repasa por qué el SII rechaza un DTE.
Cierre
El error "Invalid Character" casi siempre se reduce a dos cosas: un carácter estructural sin escapar como entidad XML, o un archivo guardado en la codificación equivocada. Respetar ISO-8859-1 desde la generación y escapar las cinco entidades predefinidas resuelve el rechazo de schema, y de paso protege la firma digital.
Emitir es la API que genera y firma el XML del DTE correctamente codificado desde tu backend, manejando ISO-8859-1 y el escape de entidades por ti. Actualmente estamos en lista de espera: súmate a la lista de espera para acceder cuando abramos.
Preguntas frecuentes
¿Por qué el SII rechaza mi DTE con el error 'Invalid Character'?+
Porque el XML contiene un carácter que no fue escapado como entidad XML predefinida. Caracteres como &, <, > rompen la estructura del documento y el SII detiene el envío en el paso de validación de schema, antes incluso de revisar la firma.
¿Por qué los XML de DTE deben usar ISO-8859-1 y no UTF-8?+
El instructivo técnico del SII define ISO-8859-1 (Latin-1) como el set de caracteres del documento. Acentos, eñes y demás caracteres especiales deben codificarse según ISO-8859-1. Si guardas el XML en UTF-8 se corrompen los acentos y la ñ.
¿Cómo escribo el carácter & dentro de la Razón Social?+
Debes reemplazarlo por la entidad & (o &). Por ejemplo, 'Empresas A&B Limitada' se codifica como 'Empresas A&B Limitada'.
¿Por qué cambiar la codificación afecta la firma digital del DTE?+
El digest de la firma se calcula sobre el string exacto del XML. Si reabres o transformas el documento en otra codificación y se alteran los bytes de acentos o la ñ, la firma deja de coincidir y el SII la rechaza en el segundo paso de validación.
¿En qué orden valida el SII el envío de un DTE?+
Primero valida el schema, luego la firma digital y por último el timbre electrónico (TED). El error 'Invalid Character' cae en el primer paso, el de schema.
¿Cómo reviso mi XML antes de enviarlo al SII?+
Puedes usar el validador de XML DTE de Emitir, que revisa estructura y codificación directamente en tu navegador sin subir el archivo a ningún servidor.