15 errores comunes en XML SEPA y cómo corregirlos
Una guía completa sobre los errores de validación más frecuentes en SEPA pain.001 y pain.008, con soluciones prácticas para cada uno.
Por qué se rechazan los archivos XML SEPA
Los archivos XML SEPA (pain.001 para transferencias de crédito y pain.008 para adeudos directos) siguen esquemas ISO 20022 estrictos definidos por el European Payments Council (EPC). Incluso pequeñas desviaciones de la estructura esperada causan que los bancos rechacen lotes completos de pagos. Comprender los errores comunes ahorra tiempo y evita costosos retrasos en los pagos.
Esta guía cubre los 15 errores XML SEPA más frecuentes que encuentran los equipos de tesorería, contables y desarrolladores en toda Europa. Cada error incluye la causa raíz, el elemento XML involucrado y una solución probada.
Ya sea que uses SAP, Oracle o un ERP personalizado, estos patrones se aplican universalmente a todos los archivos de pago conformes con SEPA.
Errores de esquema y estructura
Estos errores ocurren cuando la estructura XML no coincide con el esquema XSD del EPC.
1. Espacio de nombres o versión de esquema incorrectos
El elemento root <Document> debe declarar el espacio de nombres correcto para su versión pain.001 (p.ej. urn:iso:std:iso:20022:tech:xsd:pain.001.001.09). Mezclar espacios de nombres de diferentes versiones causa un error de validación XSD inmediato.
2. Campos obligatorios de GrpHdr faltantes
El bloque GroupHeader (GrpHdr) requiere MsgId, CreDtTm, NbOfTxs, CtrlSum e InitgPty. Omitir cualquiera de estos campos — especialmente CtrlSum — hace que el archivo falle la validación de esquema antes de que el banco procese las instrucciones de pago.
3. Codificación XML no válida o BOM
El XML SEPA debe usar codificación UTF-8. Los archivos con BOM (Marca de Orden de Bytes), UTF-16 o codificación Windows-1252 son rechazados. Asegúrate de que tu herramienta de exportación escriba UTF-8 puro sin BOM.
4. Elementos en orden incorrecto
Los esquemas ISO 20022 imponen un ordenamiento estricto de los elementos. Por ejemplo, en PmtInf, el PmtMtd debe aparecer antes que ReqdExctnDt. Intercambiar posiciones de elementos — incluso si todos los datos están presentes — causa un error de validación de esquema.
5. MsgId duplicado entre archivos
Cada archivo SEPA debe tener un MsgId único. Si tu sistema reutiliza el mismo MsgId para diferentes lotes de pago, los bancos rechazarán el duplicado como un posible ataque de repetición. Usa marcas de tiempo o UUIDs para garantizar la unicidad.
Errores de IBAN y BIC
Los errores en los identificadores de cuenta son la razón más común de rechazos SEPA.
6. Suma de verificación IBAN no válida (mod-97)
Los IBANs usan un algoritmo mod-97 para sus dígitos de verificación (posiciones 3-4). Un solo error de dígito hace que la suma de verificación falle. Valida siempre los IBANs programáticamente antes de incluirlos en tu archivo SEPA. ValidateFin verifica cada IBAN en tu archivo automáticamente.
7. Longitud de IBAN no coincide para el país
Cada país tiene una longitud de IBAN fija (p.ej. DE=22, FR=27, BE=16, NL=18). Un IBAN con el número incorrecto de caracteres para su prefijo de país es inmediatamente inválido.
8. BIC obsoleto o no válido
Los códigos BIC/SWIFT pueden quedar obsoletos después de fusiones bancarias. Usar un BIC obsoleto causa fallos de enrutamiento. Para pagos SEPA dentro del EEE, el BIC es opcional desde 2016 — considera omitirlo y dejar que el banco lo derive del IBAN.
Errores de importe y moneda
Errores de validación financiera que causan rechazos a nivel de lote.
9. CtrlSum no coincide con el total de transacciones
El CtrlSum en GrpHdr debe ser exactamente igual a la suma de todos los valores InstdAmt en el archivo. Incluso una diferencia de redondeo de 0,01€ hace que se rechace el archivo completo. Usa aritmética decimal precisa, no de punto flotante.
10. Moneda no EUR en archivo SEPA
Las Transferencias de Crédito SEPA solo admiten EUR. Si tu archivo contiene importes en GBP, CHF u otras monedas, el banco lo rechazará. Usa un canal de pago internacional separado para transferencias no EUR.
11. Formato de importe con separador decimal incorrecto
El XML SEPA usa un punto (.) como separador decimal, no una coma. El valor debe tener exactamente 2 decimales: <InstdAmt Ccy="EUR">1500.00</InstdAmt>. Valores como "1500" o "1.500,00" son inválidos.
Errores de fecha e identificador
Errores comunes en campos de fecha y referencia.
12. Fecha de ejecución pasada o no válida
El ReqdExctnDt debe ser un día laborable actual o futuro. La mayoría de los bancos rechazan fechas en el pasado y fechas con más de 30 días de anticipación. Las fechas de fin de semana se desplazan al lunes, pero algunos bancos las rechazan directamente.
13. Caracteres no válidos en EndToEndId
El campo EndToEndId (máx. 35 caracteres) solo permite un conjunto restringido: a-z, A-Z, 0-9 y algunos caracteres especiales (/, -, ?, :, (, ), ., +, espacio). Caracteres como #, @, é, ü son rechazados.
14. Identificador de acreedor faltante para SDD
SEPA Direct Debit (pain.008) requiere un Identificador de Acreedor (CI) válido en CdtrSchmeId. Este es un registro específico de cada país (p.ej. ICS en Francia, Gläubiger-ID en Alemania). Sin él, todo el lote SDD falla.
15. Recuento NbOfTxs no coincide
El campo NbOfTxs en GrpHdr debe coincidir con el número real de elementos CdtTrfTxInf (o DrctDbtTxInf) en el archivo. Una discrepancia — a menudo causada por generación parcial del archivo — causa un rechazo inmediato.
Valida tus archivos SEPA al instante
ValidateFin detecta los 15 errores listados arriba — y más. Sube tu archivo pain.001 o pain.008 y obtén retroalimentación inmediata sobre conformidad con el esquema, validación de IBAN, consistencia de importes y codificación de caracteres.
Abrir validador SEPAPreguntas frecuentes
¿Cuál es el error XML SEPA más común?
El error más común es una suma de verificación IBAN no válida (fallo mod-97). Esto representa aproximadamente el 30% de todos los rechazos de archivos SEPA. Valida siempre los IBANs antes de generar tu archivo de pago.
¿Puedo corregir errores SEPA sin regenerar el archivo completo?
Depende del error. Las correcciones simples como corregir un IBAN o ajustar CtrlSum se pueden hacer editando directamente el XML. Sin embargo, los errores estructurales (orden de elementos incorrecto, espacio de nombres faltante) generalmente requieren regeneración desde el sistema fuente.
¿ValidateFin verifica los 15 errores?
Sí. ValidateFin valida tu archivo SEPA contra los esquemas XSD del EPC, verifica cada IBAN con mod-97, comprueba la consistencia de CtrlSum, valida la codificación de caracteres y marca todos los problemas estructurales. La validación se ejecuta completamente en tu navegador — no se sube ningún archivo.
¿Por qué mi banco rechaza un archivo que pasó la validación XSD?
La validación XSD solo verifica la estructura XML. Los bancos también aplican reglas de negocio: fechas de ejecución válidas, CtrlSum correcto, MsgId único e IBAN/BIC apropiados. ValidateFin verifica tanto el esquema como las reglas de negocio.
¿Los códigos de error SEPA están estandarizados?
Sí. Los bancos usan códigos de motivo ISO 20022 (p.ej. AC01 para IBAN incorrecto, AM05 para duplicado, AG01 para tipo de transacción prohibido). El EPC mantiene una lista completa en el documento de Códigos de Motivo SEPA.
¿Cómo prevengo errores SEPA en mi ERP?
Implementa validación de IBAN en la entrada de datos, usa una biblioteca XML SEPA (no concatenación de cadenas) para la generación de archivos, valida el archivo de salida antes de enviar y siempre prueba primero con la herramienta de validación de tu banco.
¿Qué pasa cuando se rechaza un archivo SEPA?
El banco devuelve un informe de estado pain.002 con códigos de motivo de rechazo para cada transacción fallida. Debes corregir los errores y reenviar el archivo completo o el bloque de pago afectado.
¿Pueden los problemas de codificación de caracteres ser silenciosos?
Sí. Algunos caracteres (como comillas tipográficas " " o guiones em —) parecen correctos en pantalla pero están fuera del conjunto de caracteres SEPA. Causan rechazos sin una señal visual obvia. ValidateFin marca estos problemas de codificación invisibles.
¿Hay diferencia en el manejo de errores entre pain.001.001.03 y .09?
Las versiones más nuevas (09, 11) tienen una validación más estricta. Algunos campos que eran opcionales en 03 ahora son obligatorios. Las restricciones del conjunto de caracteres son las mismas. ValidateFin valida contra la versión específica declarada en tu archivo.
¿Cuánto tiempo tengo para corregir un archivo SEPA rechazado?
No hay un plazo estándar, pero los retrasos de pago se acumulan. La mayoría de los equipos de tesorería apuntan a corregir y reenviar en 4 horas hábiles. La pre-validación con ValidateFin elimina la mayoría de los escenarios de rechazo.