Como leer un mensaje de rechazo del SIFEN
Cuando transmitis un DTE al SIFEN y la validacion falla, el Web Service devuelve una respuesta XML con un codigo de estado y un mensaje descriptivo. Entender la estructura de esta respuesta es el primer paso para resolver cualquier error.
La respuesta de rechazo tiene dos elementos clave: el codigo de respuesta (un numero que categoriza el tipo de error) y el mensaje de respuesta (una descripcion en texto del problema). A veces, el mensaje incluye el campo especifico que fallo y el valor esperado.
Consejo practico
Antes de buscar soluciones, copia el codigo de error exacto y el mensaje completo. No intentes adivinar el problema solo por el comportamiento. El codigo te dice precisamente que campo o validacion fallo. Si tu software de facturacion no te muestra el codigo, revisa los logs de la comunicacion con el Web Service.
Los errores se agrupan en categorias predecibles. Vamos a cubrir cada una con ejemplos reales y soluciones concretas. Si necesitas entender primero como funciona el sistema de facturacion electronica en Paraguay, te recomendamos empezar por esa guia.
1. Errores de estructura XML
Son los mas comunes para quienes estan empezando con la facturacion electronica o migrando de un software a otro. El XML del DTE debe cumplir estrictamente con el esquema XSD definido por la DNIT.
Tags malformados o fuera de orden
Que significa: el XML tiene etiquetas sin cerrar, mal anidadas, o en un orden que no corresponde al esquema XSD. El parser del SIFEN es estricto: no tolera variaciones en la secuencia de elementos.
Causa tipica: concatenacion manual de strings para armar el XML en vez de usar un generador de XML validado. Tambien ocurre cuando se copian fragmentos de un documento a otro sin respetar la estructura.
Solucion: valida tu XML contra el esquema XSD oficial de la DNIT antes de enviarlo. Cualquier editor XML o libreria de programacion puede hacer esta validacion en milisegundos. Si el error persiste, compara tu XML linea por linea con un ejemplo valido de la documentacion tecnica del SIFEN.
Campos obligatorios faltantes
Que significa: uno o mas campos requeridos por el esquema no estan presentes en el XML. El SIFEN tiene campos que son obligatorios para todos los DTE y campos que son obligatorios segun el tipo de documento o la condicion de venta.
Causa tipica: confundir campos opcionales con obligatorios, especialmente en el grupo gCamCond (condiciones de la operacion). Por ejemplo, si la condicion de pago es a credito (iCondOpe=2), el grupo gPagCred es obligatorio. Si es contado (iCondOpe=1), el grupo gPagCont es obligatorio.
Solucion: revisa el Manual Tecnico del SIFEN, seccion de campos obligatorios por tipo de DTE. Presta atencion a las condiciones: muchos campos son "obligatorios si..." (obligatorios solo cuando otro campo tiene un valor especifico). Tu software debe implementar estas reglas condicionalmente.
Formato de datos incorrecto
Que significa: un campo tiene el tipo de dato equivocado. Ejemplo: un campo numerico con letras, una fecha en formato DD/MM/YYYY cuando el SIFEN espera YYYY-MM-DD, o un monto con coma decimal en vez de punto.
Causa tipica: diferencias de formato entre el sistema local (que puede usar formatos paraguayos como DD/MM/YYYY o coma decimal) y el estandar XML del SIFEN (ISO 8601 para fechas, punto para decimales).
Solucion: verifica que todas las fechas esten en formato YYYY-MM-DDTHH:MM:SS (ISO 8601), los montos usen punto decimal, y los campos numericos no contengan separadores de miles. Revisa especialmente los campos dFeEmiDE (fecha de emision) y los montos en gTotSub.
2. Errores de certificado digital
El certificado digital es el equivalente electronico de tu firma. Sin un certificado valido, ningun DTE puede ser transmitido. Estos errores son criticos porque no se resuelven editando el XML.
Certificado vencido
Que significa: tu certificado digital expiro. Los certificados tienen una fecha de validez (generalmente 1 o 2 anhos). Despues de esa fecha, el SIFEN rechaza automaticamente cualquier documento firmado con ese certificado.
Causa tipica: falta de seguimiento de la fecha de vencimiento. Muchos contribuyentes se enteran cuando ya no pueden emitir facturas.
Solucion: renueva tu certificado con un prestador de servicios de certificacion autorizado por la DNIT. El proceso puede tomar varios dias, asi que se recomienda iniciar la renovacion al menos un mes antes del vencimiento. Marca la fecha de vencimiento en tu calendario con un recordatorio anticipado.
Formato de certificado incorrecto
Que significa: el archivo del certificado no esta en el formato que espera tu software de facturacion. Los formatos comunes son .pfx (PKCS#12) y .p12. Algunos software tambien aceptan .pem o .cer, pero la clave privada necesita estar incluida para firmar.
Causa tipica: exportar el certificado en un formato sin la clave privada, o usar un certificado de prueba en produccion.
Solucion: asegurate de que el certificado incluya la clave privada (formato .pfx o .p12) y que la contrasena de acceso sea correcta. Si tu prestador te entrego un .cer (solo clave publica), solicitale el archivo completo con clave privada.
Firma digital no valida
Que significa: el XML fue modificado despues de firmarlo, o la firma se aplico incorrectamente. El SIFEN verifica la integridad de la firma: si un solo caracter del XML cambia despues de la firma, la validacion falla.
Causa tipica: editar el XML manualmente despues de firmarlo (por ejemplo, para corregir un campo). Tambien puede ocurrir si el software no implementa correctamente el estandar XMLDSig.
Solucion: nunca modifiques el XML despues de firmarlo. Si necesitas corregir algo, modifica el XML primero, luego firma, luego envia. Si el problema persiste, verifica que tu implementacion de XMLDSig use canonicalizacion C14N y el algoritmo de hash correcto (SHA-256).
3. Errores de CDC (Codigo de Control)
El CDC es un identificador unico de 44 caracteres que se genera con un algoritmo especifico. Cada caracter importa. Un error en el CDC impide la identificacion y rastreo del documento.
Digito verificador incorrecto
Que significa: el ultimo digito del CDC (digito verificador, calculado con modulo 11) no coincide con los datos del documento. El SIFEN recalcula el digito verificador y lo compara con el que enviaste.
Causa tipica: un campo de entrada cambio despues de generar el CDC (por ejemplo, se modifico el numero de documento o la fecha), pero el CDC no se regenero.
Solucion: regenera el CDC completamente cada vez que modifiques cualquier dato del documento. Verifica que tu implementacion del modulo 11 use los factores correctos segun la especificacion de la DNIT. Nunca hardcodees o reutilices un CDC.
CDC duplicado
Que significa: ya existe un DTE aprobado en el SIFEN con el mismo CDC. Cada CDC es unico en todo el sistema.
Causa tipica: reenviar un documento que ya fue aprobado (tal vez por no haber recibido la confirmacion), o un error en la secuencia de numeracion que genera el mismo numero de documento dos veces.
Solucion: consulta el estado del CDC original en el SIFEN. Si ya fue aprobado, no necesitas reenviarlo. Si es un problema de numeracion, corrige la secuencia en tu sistema para que genere numeros unicos. Antes de reenviar, siempre consulta si el documento ya existe.
4. Errores de plazo de transmision
El SIFEN establece un plazo maximo de 72 horas entre la fecha de emision del documento (dFeEmiDE) y el momento de transmision al Web Service. Este plazo es estricto y no tiene excepciones automaticas.
Documento fuera de plazo (72 horas excedidas)
Que significa: pasaron mas de 72 horas entre la fecha de emision que figura en el DTE y el momento en que lo transmitiste al SIFEN. El sistema rechaza automaticamente cualquier documento fuera de este plazo.
Causa tipica: emitir documentos offline y no sincronizar a tiempo. Tambien puede ocurrir si el reloj del servidor local esta desfasado con respecto al reloj del SIFEN, o si hubo problemas de conectividad prolongados.
Solucion: no podes "arreglar" un DTE fuera de plazo. Necesitas emitir un nuevo DTE con fecha actual y transmitirlo dentro de las 72 horas. Para prevenir este error, configura tu sistema para que intente la transmision inmediata y tenga reintentos automaticos. Sincroniza el reloj del servidor con NTP.
Caso especial: contingencia. Si el SIFEN estuvo caido y no pudiste transmitir dentro del plazo, la DNIT puede habilitar un periodo de contingencia. En ese caso, los documentos emitidos durante la caida se transmiten despues con un codigo de contingencia que justifica el retraso. Consulta la resolucion vigente sobre contingencia del SIFEN.
5. Errores de validacion de campos
Estos son errores de logica de negocio: el XML esta bien formado y firmado correctamente, pero los datos no cumplen con las reglas fiscales del SIFEN.
Formato de RUC invalido
Que significa: el RUC del emisor o del receptor no cumple con el formato esperado. El RUC paraguayo tiene un formato especifico: numero base + digito verificador separado por guion (por ejemplo, 80012345-6).
Causa tipica: incluir puntos de miles en el RUC, omitir el digito verificador, o usar un RUC de prueba en produccion.
Solucion: el RUC debe ir sin puntos ni separadores de miles, con el digito verificador incluido. Verifica que el RUC este activo en el registro de la DNIT. Para receptores ocasionales (consumidor final), usa el RUC generico segun la normativa vigente.
Condicion de pago inconsistente (gCamCond)
Que significa: los campos del grupo gCamCond (condiciones comerciales de la operacion) tienen valores que se contradicen entre si. Por ejemplo: iCondOpe indica "contado" (1) pero el XML incluye el grupo gPagCred (pago a credito), o viceversa.
Causa tipica: no mantener la coherencia entre el tipo de condicion de operacion y los subgrupos de pago. Tambien ocurre cuando se cambia la condicion de pago sin actualizar los subgrupos correspondientes.
Solucion: si iCondOpe=1 (contado), incluí solo gPagCont. Si iCondOpe=2 (credito), incluí solo gPagCred con las cuotas y plazos. Nunca incluyas ambos grupos simultaneamente. Revisa que el monto total de pagos coincida con el total del documento.
Descuadre de montos (totales no coinciden)
Que significa: el SIFEN recalcula los totales a partir de los items y detecta una diferencia con los totales que declaraste en gTotSub. La suma de (cantidad x precio unitario) de los items, menos descuentos, mas IVA, debe coincidir exactamente con los campos de totales.
Causa tipica: errores de redondeo, calcular el IVA sobre el total en vez de item por item, o no restar los descuentos antes de calcular el impuesto.
Solucion: calcula el subtotal y el IVA item por item, luego suma. El SIFEN tolera una diferencia de redondeo minima (generalmente 1 guarani por item), pero cualquier diferencia mayor causa rechazo. Usa numeros enteros (guaranies sin decimales) para evitar problemas de redondeo. Verifica que los descuentos se apliquen antes del calculo del IVA.
6. Errores de conectividad y red
No todos los problemas son del XML. A veces la comunicacion con el Web Service del SIFEN falla por razones tecnicas.
Timeout o conexion rechazada
Que significa: tu sistema no pudo establecer conexion con el Web Service del SIFEN, o la conexion se interrumpio antes de recibir la respuesta.
Causa tipica: el SIFEN esta en mantenimiento o con alta demanda, problemas de internet del lado del contribuyente, o firewall que bloquea la comunicacion SSL al endpoint del SIFEN.
Solucion: implementa reintentos automaticos con intervalos crecientes (retry con backoff exponencial). Verifica que tu firewall permita conexiones HTTPS al endpoint del SIFEN. Si el problema persiste por horas, consulta el canal oficial de la DNIT para verificar si hay mantenimiento programado. Mientras tanto, tus documentos quedan en cola para reenvio.
Respuesta incompleta o ilegible
Que significa: el SIFEN respondio, pero la respuesta esta truncada o no se puede parsear como XML valido.
Causa tipica: la conexion se corto durante la recepcion de la respuesta, o hay un proxy intermedio que modifica la respuesta.
Solucion: no asumas que el documento fue rechazado. Consulta el estado del CDC en el SIFEN antes de reenviar. Si el documento ya fue aprobado y lo reenvias, vas a recibir un error de CDC duplicado. Primero consulta, despues decide si reenviar.
Tabla de referencia rapida
Para consulta rapida, esta tabla resume los errores mas frecuentes con su solucion en una linea:
| Categoria | Error | Solucion rapida |
|---|---|---|
| XML | Tag malformado | Validar contra XSD antes de enviar |
| XML | Campo obligatorio faltante | Revisar Manual Tecnico, campos condicionales |
| XML | Formato de fecha incorrecto | Usar YYYY-MM-DDTHH:MM:SS (ISO 8601) |
| Certificado | Certificado vencido | Renovar con prestador autorizado |
| Certificado | Firma invalida | No modificar XML despues de firmar |
| CDC | Digito verificador incorrecto | Regenerar CDC con modulo 11 |
| CDC | CDC duplicado | Consultar estado antes de reenviar |
| Plazo | 72 horas excedidas | Emitir nuevo DTE con fecha actual |
| Validacion | RUC invalido | Sin puntos, con digito verificador |
| Validacion | gCamCond inconsistente | Alinear iCondOpe con subgrupo de pago |
| Validacion | Montos descuadrados | Calcular IVA item por item, sin decimales |
| Red | Timeout | Reintentar con backoff. Verificar firewall |
Buenas practicas para evitar rechazos
La mayoria de los rechazos del SIFEN son prevenibles. Estas practicas reducen drasticamente la tasa de error:
Valida antes de enviar
Toda transmision al SIFEN deberia ser precedida por una validacion local contra el XSD. Si tu XML no pasa la validacion local, no lo envies. Ahorra tiempo, ancho de banda y frustración.
Usa el entorno de pruebas primero
El SIFEN tiene un entorno de test separado del de produccion. Proba todos los tipos de documento (factura, NCE, NDE) en test antes de ir a produccion. Los errores en test no tienen consecuencia fiscal. Si necesitas emitir una Nota de Credito Electronica (NCE), probala primero en el entorno de test.
Implementa reintentos automaticos
Los errores de red son inevitables. Tu sistema tiene que poder reintentar automaticamente (con intervalos crecientes) sin generar duplicados. Antes de cada reintento, consulta si el CDC ya existe en el SIFEN.
Monitorea el vencimiento del certificado
Un certificado vencido paraliza toda tu operacion de facturacion electronica. Agenda la renovacion con 30 dias de anticipacion. No esperes al ultimo momento.
Loguea todo
Guarda el XML enviado, la respuesta del SIFEN, el timestamp, y el codigo de resultado. Cuando un error ocurre, estos logs te dicen exactamente que paso. Sin logs, estas adivinando.
Cuando el problema no es tuyo
No todos los rechazos son causados por errores del contribuyente. El SIFEN, como cualquier sistema, tiene momentos de inestabilidad:
- Mantenimiento programado: la DNIT anuncia ventanas de mantenimiento donde el servicio no esta disponible. Consulta los canales oficiales.
- Alta demanda: en fechas limite (fin de mes, vencimiento de declaraciones), el servicio puede saturarse. Los timeouts aumentan.
- Actualizaciones del esquema: cuando la DNIT actualiza el XSD o las reglas de validacion, los documentos que antes pasaban pueden ser rechazados. Mantene tu software actualizado.
En estos casos, la solucion es esperar y reintentar. Tu sistema debe estar preparado para operar en modo offline temporalmente y sincronizar cuando el servicio se restablezca, siempre dentro del plazo de 72 horas. Entender el contexto general de la facturacion electronica en Paraguay ayuda a anticipar estos desafios.
Preguntas frecuentes
Fakturas.app ayuda a estudios contables a recibir, organizar y exportar facturas de sus clientes. Todo desde un solo dashboard.
Conocer planes