Error 2500 de SIFEN: el QR no coincide con el XML (y a veces la culpa es de la firma)
Respuesta corta: el 2500 es la validación 279 del manual —
«la cadena de caracteres correspondiente al código QR no coincide con el archivo XML».
Casi siempre se diagnostica revisando el QR, y casi siempre está bien mirar ahí: lo
habitual es que fallen los totales del IVA.
Pero hay un 2500 distinto, el que viene acompañado de un
«Falla al evaluar». Ése no significa que los datos no coincidan:
significa que la comparación ni siquiera llegó a ejecutarse. Ahí no
mires el QR — mirá la firma.
Qué entra en el QR
El código QR no es decorativo: la SET lo recalcula desde tu XML y compara. Estos son los parámetros que entran en el hash, según el manual:
| Parámetro | Qué es |
|---|---|
nVersion | Versión de generación del QR |
Id | CDC del documento |
dFeEmiDE | Fecha y hora de emisión — en hexadecimal |
dRucRec / dNumIDRec | Identificación del receptor |
dTotGralOpe | Total general de la operación |
dTotIVA | Liquidación total del IVA |
cItems | Cantidad de ítems |
DigestValue | Hash de la firma digital del documento — también en hexadecimal |
IdCSC | Identificador del código entregado por el SIFEN |
Todo eso se concatena, se le aplica SHA-256 y el resultado va en hexadecimal. Fijate en la fila resaltada: el QR contiene el hash de tu propia firma. Esa dependencia es la que convierte un problema de firma en un error que se reporta como problema de QR.
El 2500 corriente: los totales
Si el 2500 llega limpio, lo más probable es que el QR esté bien construido
pero que los importes no cuadren con lo que la SET recalcula. El sospechoso habitual son
las columnas del IVA.
El caso que nos tocó: emitir un ítem con IVA al 5 % mientras se mandaban en cero las
columnas del 5 % en el grupo de subtotales. El IVA de ese ítem no caía en ninguna
columna, el total recalculado no coincidía, y salía 2500. La regla general que
sacamos: emitir siempre todas las columnas de subtotales, incluso en cero
— la SET recalcula sobre ellas y opera sobre nulo si faltan.
El 2500 raro: «Falla al evaluar»
Cuando el rechazo viene con un texto de error inesperado en vez de un desajuste concreto, el diagnóstico cambia por completo. Nos pasó, y perdimos un buen rato buscando en el QR algo que estaba bien.
La prueba que lo distingue
Es sencilla y vale para cualquier caso: rompé el QR a propósito. Cambiá un total por uno que sabés que no coincide, y volvé a enviar.
- Si te devuelve un desajuste distinto o más concreto, la regla está corriendo y tu problema es de datos.
- Si te devuelve exactamente el mismo error, la comparación no se está ejecutando. El problema está antes: en el setup de la regla, cuando intenta resolver los valores para recalcular.
La causa: el prefijo de la firma
Para recalcular el hash, la SET necesita extraer el DigestValue de tu XML. Lo
busca donde el manual dice que tiene que estar, y ahí aparece una regla del manual que es
fácil pasar por alto:
El manual prohíbe expresamente los prefijos de namespace, y añade una
«particularidad de la firma digital»: la declaración del namespace de la firma
debe hacerse en la propia etiqueta <Signature>.
Firmar con el clásico <ds:Signature> es válido según el estándar
XMLDSig, y de hecho la validación de firma lo acepta sin quejarse. Pero la regla del QR
busca el DigestValue asumiendo el namespace por defecto, sin prefijo: con
ds: no lo encuentra, y en vez de decir «no coincide», revienta.
<!-- Válido en XMLDSig, pero rompe la regla del QR -->
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo> … </ds:SignedInfo>
</ds:Signature>
<!-- Lo que espera SIFEN: namespace por defecto, declarado una vez.
Los hijos lo heredan y ninguno lleva prefijo. -->
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo> … </SignedInfo>
</Signature>Lo que hace difícil este error: tu firma es correcta. Verifica bien en local, y la validación de firma de la SET también la da por buena. Lo que se rompe es una regla posterior que busca el mismo dato por otro camino. Si estás dando vueltas al QR sin encontrar nada, revisá cómo declaraste el namespace de la firma.
Resumen para depurar
- ¿El
2500viene limpio? → totales, y sobre todo las columnas del IVA. - ¿Viene con un error inesperado? → hacé la prueba de romper el QR a propósito.
- ¿Sale el mismo error? → la regla no se ejecuta: mirá el namespace de la firma.
- Regla general: ningún prefijo de namespace en ninguna parte del documento.
Más de esta serie: el 0160 y el salto de línea · el 1264 y por qué es buena noticia · cancelar un DTE: plazos y firma.
Verificado el 26 de julio de 2026. La validación 279 (código
2500), la metodología de generación del código QR y la regla sobre prefijos de
namespace y la declaración del namespace de la firma, contra el Manual Técnico del SIFEN
versión 150 publicado por la DNIT. El comportamiento del rechazo y la prueba
discriminante, contra respuestas reales del servicio en julio de 2026. La documentación
técnica se actualiza: comprobá la versión vigente antes de dar algo por hecho.
Esto es información técnica de integración, no asesoramiento tributario. Para el criterio fiscal de tu caso, hablá con tu contador.