Guía ejemplo fichero norma 34 sepa xml: estructura, plantillas y ejemplos

Aunque pueda parecer algo del pasado, el fichero de Norma 34 (o AEB 34) sigue muy presente en muchos sistemas de gestión que aún lo utilizan para generar remesas. Sin embargo, aquí viene lo importante: para que los bancos puedan procesar los cobros, es obligatorio convertir este fichero al formato SEPA XML. Entender bien este cambio es clave para evitar que te devuelvan los recibos y para que tu operativa financiera no se detenga.

El fichero Norma 34 y por qué hay que convertirlo a SEPA XML

Durante muchos años, la Norma 34 (o Cuaderno 34 de la Asociación Española de Banca) fue el estándar de referencia en España para emitir remesas de adeudos domiciliados. Hablamos de un fichero de texto plano, con una estructura muy rígida y de longitud fija, que estaba pensado únicamente para funcionar dentro del sistema bancario español.

Todo esto cambió con la llegada de la Zona Única de Pagos en Euros (SEPA). El objetivo de SEPA era muy claro: unificar las transacciones en euros bajo un mismo paraguas de reglas y estándares técnicos, lo que de paso facilitaba enormemente las operaciones entre países.

La migración obligatoria al estándar SEPA XML

El formato que vino a reemplazar a la Norma 34 para los adeudos directos es el SEPA XML, concretamente el esquema conocido como pain.008.001.02. A diferencia de su antecesor, el XML es un formato mucho más versátil y completo, ya que se basa en la norma internacional ISO 20022.

Este cambio no es una sugerencia, es una obligación. Los bancos ya no aceptan ficheros en el antiguo formato AEB 34 para procesar los cobros. Por eso, cualquier empresa que siga generando remesas desde un ERP o un software antiguo tiene que, sí o sí, convertirlas al formato XML antes de enviarlas a la entidad bancaria.

Pasarse a SEPA, aunque obligatorio, trae consigo unas cuantas ventajas importantes:

• Cumplimiento normativo: Te aseguras de que tus remesas siguen la regulación europea, lo que evita rechazos automáticos por parte del banco.
• Menos errores: El formato XML tiene validaciones internas y campos de datos mucho más específicos, como el identificador del mandato, que ayudan a reducir los típicos fallos manuales.
• Mayor eficiencia: Al unificar todo bajo el estándar SEPA, la gestión de cobros se simplifica, sobre todo si tienes clientes en otros países de la zona euro.

Si quieres saber más sobre este formato heredado, te recomendamos leer nuestro artículo sobre qué es un fichero Norma 34 y por qué su conversión es tan importante a día de hoy.

La anatomía de un fichero de adeudos SEPA XML (Norma 34)

Para entender de verdad cómo se transforma la información de un fichero antiguo de Norma 34, no hay nada como meterse en las entrañas de un ejemplo de fichero SEPA XML. A primera vista, la cantidad de etiquetas y la estructura jerárquica pueden asustar un poco, pero en realidad todo sigue una lógica muy clara y ordenada.

Un fichero de adeudos directos SEPA (conocido técnicamente como pain.008.001.02) se organiza en tres grandes bloques. Cada uno tiene una misión concreta: desde identificar la remesa en su conjunto hasta desglosar cada uno de los cobros individuales. Dominar esta estructura es fundamental para saber si tus datos se han convertido correctamente y para poder solucionar cualquier problema.

Ojo al dato: un fichero SEPA XML bien construido es tu mejor seguro contra las devoluciones. Se estima que los errores en la generación de remesas cuestan a las pymes entre el 1 % y el 2 % del valor total, sumando comisiones bancarias y gastos de gestión.

Vamos a desglosar estos bloques para que veas qué información contienen y, sobre todo, por qué es tan importante.

Estructura principal de un fichero SEPA XML (pain.008.001.02)

Para tener una visión general, esta tabla resume los bloques principales que encontrarás en cualquier fichero de adeudos directos. Es una chuleta perfecta para identificar rápidamente dónde está cada tipo de información.

Bloque XML (Etiqueta)	Descripción del contenido	Ejemplo de campo clave
GrpHdr (Cabecera del Grupo)	Contiene los datos globales de la remesa. Actúa como la portada del fichero, identificando el lote completo de transacciones.	MsgId (Identificador del mensaje)
PmtInf (Información del Pago)	Agrupa un conjunto de adeudos bajo condiciones comunes, como la fecha de cobro o la cuenta del acreedor.	ReqdColltnDt (Fecha de cobro)
DrctDbtTxInf (Transacción Individual)	Detalla cada cobro individual: el importe, el deudor, su cuenta bancaria y la referencia del mandato asociado.	InstdAmt (Importe del adeudo)

Como puedes ver, la estructura va de lo general a lo particular, asegurando que toda la información esté organizada de forma lógica para que los sistemas bancarios la procesen sin errores.

El bloque de cabecera del grupo (GrpHdr)

Piensa en este bloque como la portada de tu remesa. Es lo primero que lee el sistema del banco y contiene la información que identifica todo el lote de transacciones que estás enviando.

Aquí te encontrarás con campos clave como: * Identificador del Mensaje (MsgId): Un código único que tú mismo asignas a la remesa. Es fundamental para poder rastrearla y diferenciarla de cualquier otra. Imagina que es el número de factura de todo tu lote de cobros. * Fecha y Hora de Creación (CreDtTm): El momento exacto en el que se generó el fichero, con el formato estricto AAAA-MM-DDThh:mm:ss. * Número de Transacciones (NbOfTxs): El recuento total de adeudos que incluye el fichero. Un simple contador. * Suma de Control (CtrlSum): El importe total que resulta de sumar todos los adeudos. El banco usa este dato como una doble verificación para asegurarse de que no se ha perdido ni modificado ninguna transacción por el camino.

El bloque de información del pago (PmtInf)

Justo después de la cabecera, aparece este segundo gran bloque. Su función es agrupar las transacciones que comparten unas mismas condiciones de pago. Por ejemplo, todos los recibos que se van a cobrar en la misma fecha y desde la misma cuenta bancaria de tu empresa irán dentro del mismo bloque PmtInf.

Dentro de este bloque, los datos más importantes son: * Identificador de la Orden de Pago (PmtInfId): Otra referencia única, pero esta vez para este grupo específico de pagos. * Método de Pago (PmtMtd): Para los adeudos directos, este campo siempre contendrá el valor DD (Direct Debit). * Fecha de Cobro Requerida (ReqdColltnDt): La fecha en la que quieres que el banco pase los recibos al cobro a tus clientes. * Datos del Acreedor (Cdtr): Aquí va tu nombre o razón social y tu identificador de acreedor SEPA. * Cuenta del Acreedor (CdtrAcct): Tu número de cuenta en formato IBAN.

El bloque de transacciones individuales (DrctDbtTxInf)

Llegamos al corazón del fichero. Anidado dentro de cada bloque PmtInf, encontrarás tantos bloques DrctDbtTxInf como recibos individuales quieras cobrar. Cada uno representa un único adeudo a un cliente concreto.

Este es el nivel de máximo detalle, donde se especifica toda la información del cobro: * Importe del Adeudo (InstdAmt): La cantidad exacta que se va a cargar al cliente. * Identificador del Mandato (MndtId): La referencia única del mandato SEPA que tu cliente firmó autorizando el cobro. Es un dato crítico. * Fecha de Firma del Mandato (DtOfSgntr): La fecha en la que se firmó esa autorización. * Datos del Deudor (Dbtr): El nombre y la dirección del cliente al que se le cobra. * Cuenta del Deudor (DbtrAcct): El IBAN de la cuenta bancaria de tu cliente. * Concepto del Recibo (RmtInf): Una descripción clara del cobro, como “Cuota mensual gimnasio” o “Factura AB-2024-05”.

Mapeo de campos: de la Norma 34 al XML de SEPA

Pasar de la clásica Norma 34 al estándar SEPA XML es, en el fondo, como traducir un idioma. Se trata de coger la información que ya tenías y colocarla en el sitio correcto dentro de una estructura nueva. Entender esta correspondencia es fundamental para que la migración salga bien a la primera, sin errores que retrasen tus cobros.

El principal reto es que no siempre hay una equivalencia directa. El formato SEPA introduce nuevos campos que en la Norma 34 simplemente no existían, sobre todo los que tienen que ver con la gestión del mandato de domiciliación. Por ejemplo, un dato tan importante como la fecha de firma del mandato es obligatorio en SEPA, pero no se contemplaba en el antiguo formato AEB 34.

Correspondencia de campos Norma 34 vs. SEPA XML

Para que te hagas una idea clara de cómo funciona esta “traducción”, he preparado una tabla de referencia. Aquí puedes ver de un vistazo dónde va a parar cada dato de tu fichero original cuando lo conviertes a SEPA XML. Es una chuleta perfecta para resolver dudas rápidas.

Campo en Norma 34 AEB	Etiqueta XML correspondiente en SEPA	Observaciones importantes
NIF del Ordenante	<Id><OrgId><Othr><Id> dentro de Cdtr	Identifica a la empresa que emite el cobro.
Cuenta del Deudor	<DbtrAcct><Id><IBAN>	El formato cambia de CCC a IBAN, que es obligatorio en SEPA.
Importe del Recibo	<InstdAmt>	Debe especificarse con la divisa, por ejemplo, <InstdAmt Ccy="EUR">.
Referencia Domiciliación	<MndtId>	Pasa a ser el identificador único del mandato SEPA.
Concepto del Recibo	<RmtInf><Ustrd>	Es el texto que verá el cliente en su extracto bancario.

Como ves, la lógica es bastante directa para los campos básicos. El verdadero cambio viene con la información que SEPA añade para dar más seguridad y trazabilidad a las operaciones.

Campos nuevos y consideraciones clave

Más allá de la equivalencia directa, el formato XML de SEPA te va a pedir datos adicionales. Ignorar estos nuevos requisitos es la causa número uno por la que los bancos rechazan los ficheros de remesas. Presta atención, porque son obligatorios.

Los datos más importantes que tendrás que añadir y que no estaban en la Norma 34 son:

• Identificador del Acreedor SEPA: Es un código único que te identifica como emisor de adeudos en toda la zona SEPA. Si no lo tienes, te lo tiene que facilitar tu banco.
• Fecha de Firma del Mandato (DtOfSgntr): La fecha exacta en que tu cliente firmó la autorización. Este campo es absolutamente imprescindible.
• Tipo de Secuencia (SeqTp): Sirve para indicar si el cobro es recurrente (RCUR), el primero de una serie (FRST), el último (FNAL) o un pago único (OOFF).

Un mapeo correcto es la base para que la conversión funcione. Herramientas como ConversorSEPA hacen todo este trabajo por ti. Interpretan tu fichero de Excel, CSV o Norma 34, colocan cada dato en su etiqueta XML correspondiente y añaden los campos nuevos para generar un fichero SEPA válido al instante.

Plantillas y ficheros de ejemplo para descargar

Para que puedas empezar a trabajar y entender todo el proceso de forma práctica, hemos preparado un paquete de recursos listos para que los descargues. Con estos archivos, verás de manera muy clara cómo se pasa de los datos originales al fichero final que se presenta en el banco.

Aquí tienes un ejemplo de fichero norma 34 sepa xml en cada una de sus etapas. Te servirá para comparar las distintas estructuras, hacer pruebas en tus propios programas o, simplemente, usarlos como punto de partida para generar tus propias remesas.

Los ficheros que puedes descargar son los siguientes:

• Fichero original en Norma 34: Un archivo de texto plano (.txt) que es un ejemplo típico de lo que generaría un ERP o un sistema de gestión más antiguo.
• Plantilla de datos en Excel/CSV: Contiene exactamente la misma información que la remesa anterior, pero organizada en una hoja de cálculo, mucho más cómoda de manejar y editar.
• Fichero SEPA XML final: El archivo .xml que se obtiene tras la conversión, ya validado y con el formato correcto para que lo procese cualquier banco.

Este diagrama resume muy bien el flujo de conversión, partiendo de un fichero N34 para llegar a su equivalente en SEPA XML.

Como ves, el gráfico deja claro lo sencillo que resulta el proceso si se utiliza una herramienta de conversión adecuada. Se trata, al final, de transformar un formato que ya se ha quedado obsoleto en el estándar XML que exigen los bancos. Si necesitas más detalles, te recomiendo echar un vistazo a los formatos de ficheros que puedes subir para convertir.

Errores comunes y validaciones clave al generar el XML

Crear un ejemplo de fichero Norma 34 SEPA XML sin fallos a la primera es el ideal, pero la realidad es que los errores están a la orden del día. Un pequeño despiste es suficiente para que el banco rechace la remesa completa, lo que se traduce en retrasos en los cobros y, por supuesto, en costes administrativos que no tenías previstos.

Estos problemas suelen nacer de detalles que se pasan por alto, ya sea en los datos de origen o en la propia estructura del fichero. La buena noticia es que la mayoría son fallos típicos, fáciles de prever y, por tanto, de evitar. Por eso mismo, es crucial realizar una serie de validaciones antes de dar por bueno el archivo y enviarlo.

Piensa en estas comprobaciones como una lista de control de calidad. Repasarlas te ahorrará tiempo, dinero y la frustración de tener que andar corrigiendo y reenviando remesas.

Validaciones esenciales antes del envío

Antes de subir tu fichero XML a la banca online, no te la juegues. Asegúrate de que estos puntos críticos están perfectos, porque un fallo en cualquiera de ellos es motivo de rechazo casi seguro.

• Formato del IBAN: Parece obvio, pero es uno de los errores más frecuentes. Verifica que todos los IBAN son correctos, incluyendo el código del país (ES para España) y sus dos dígitos de control. Un solo IBAN mal formado y la transacción asociada quedará invalidada.
• Suma de control (CtrlSum): Matemáticas puras. El importe total que indicas en la cabecera del grupo (GrpHdr) tiene que ser exactamente la suma de todos los importes individuales de las transacciones (InstdAmt). Cualquier descuadre, aunque sea de un céntimo, hará saltar las alarmas del banco.
• Coherencia de las fechas: La fecha de cobro (ReqdColltnDt) siempre debe ser una fecha futura y realista. No te olvides de los plazos de presentación que te exige tu banco; por ejemplo, para adeudos CORE es habitual tener que enviar la remesa con al menos D-2 días hábiles de antelación.
• Identificadores únicos: El MsgId (el DNI del mensaje) y los PmtInfId (el identificador de cada bloque de pago) deben ser únicos para cada remesa. Si reutilizas identificadores de envíos anteriores, te arriesgas a que el sistema lo interprete como un duplicado y lo rechace de plano.

Un consejo práctico: La validación automática es tu mejor aliada en este proceso. En lugar de volverte loco revisando cientos de líneas de código a mano, herramientas como ConversorSEPA analizan el fichero en segundos. Detectan estos errores y muchos otros antes de que lleguen al banco. Esto no solo previene las devoluciones, sino que también recorta los costes operativos que genera la gestión de incidencias.

Contar con un buen validador te da la tranquilidad de que tu fichero es técnicamente sólido, permitiéndote centrarte en lo que de verdad importa: la gestión de tu negocio, no la resolución de problemas técnicos.

Automatiza la conversión de ficheros con la API de ConversorSEPA

Generar remesas a mano es una tarea lenta, repetitiva y, seamos sinceros, una fuente constante de errores que acaba costando tiempo y dinero. Si de verdad quieres optimizar la creación de un ejemplo de fichero Norma 34 SEPA XML o cualquier otra remesa, la automatización es el único camino. En ConversorSEPA te lo ponemos fácil con dos soluciones que se adaptan perfectamente a tu equipo, ya sea administrativo o más técnico.

Para el día a día de los departamentos de finanzas y administración, nuestra plataforma web es la herramienta perfecta. Es tan sencillo como subir un fichero en Excel, CSV o incluso en el antiguo formato Norma 34. En cuestión de segundos, tienes tu fichero SEPA XML validado y listo para enviar al banco. Todo el proceso es muy visual e intuitivo, sin necesidad de pelearse con la complejidad técnica del XML.

Es la forma más directa y controlada de gestionar las remesas.

La interfaz es limpia y clara: seleccionas tu fichero de origen y la conversión se encarga del resto.

Integración total para desarrolladores con la API JSON

Ahora bien, si lo que buscas es la máxima eficiencia, la clave está en integrar la generación de remesas directamente en tus sistemas, ya sea un ERP, un CRM o un software a medida. Y aquí es donde la API JSON de ConversorSEPA entra en juego y marca una gran diferencia. Ofrecemos a los desarrolladores un endpoint sólido y fiable para automatizar todo el proceso de conversión de principio a fin.

¿Qué significa esto en la práctica? Que los ficheros se pueden generar y validar sin que nadie tenga que intervenir manualmente. Tu sistema envía los datos de la remesa a nuestra API y recibe de vuelta el fichero SEPA XML, ya corregido y listo para usar. Esta integración no solo ahorra una cantidad enorme de tiempo, sino que también garantiza que todo sea consistente, reduciendo los errores prácticamente a cero. Si quieres conocer los detalles técnicos, puedes consultar nuestra guía sobre cómo utilizar la API de ConversorSEPA.

“La automatización a través de una API no es solo una mejora de eficiencia; es una ventaja estratégica. Permite a las empresas escalar sus operaciones de cobro sin aumentar proporcionalmente su carga administrativa, liberando al equipo para que se centre en tareas de mayor valor.”

Las cifras no engañan: el volumen de transacciones digitales no para de aumentar. Solo en el primer semestre de 2025, las transferencias SEPA en España crecieron un 12,7% hasta alcanzar los 1.584 millones de operaciones, mientras que los adeudos directos sumaron 1.143 millones. Este volumen masivo pone de manifiesto la necesidad de herramientas de automatización como la nuestra, que convierte formatos heredados como la Norma 34 al XML requerido. Así se evitan errores que, según estimaciones del sector, pueden costar a las pymes entre el 1-2% del valor total de la remesa. Puedes leer más sobre este crecimiento en Europa Press.

Seguridad y flexibilidad en la automatización

Cuando se trata de datos bancarios, la seguridad no es negociable. En ConversorSEPA nos lo tomamos muy en serio y protegemos tu información con varias capas de seguridad:

• Cifrado de datos: Toda la comunicación, tanto con la API como con la plataforma web, viaja completamente cifrada.
• Borrado automático: Los ficheros que subes y los resultados que generamos se eliminan de forma permanente de nuestros servidores en tan solo 10 minutos. No guardamos nada.
• Flexibilidad de formatos: Nuestra API está diseñada para ser flexible y entender las particularidades de distintos ficheros de origen, adaptándose a lo que cada empresa necesita.

Esta combinación de sencillez para los usuarios de negocio y potencia para los desarrolladores es lo que convierte a ConversorSEPA en la solución ideal para modernizar y asegurar la gestión de tus remesas.

Preguntas frecuentes sobre ficheros Norma 34 y SEPA XML

Para redondear esta guía sobre cómo pasar de la Norma 34 al estándar SEPA, he querido recopilar las dudas más comunes que te encontrarás en el día a día. Piénsalo como una chuleta con respuestas rápidas, claras y al grano, para que no te quedes atascado.

Aquí vas a encontrar soluciones a los problemas típicos: desde entender qué narices diferencia un formato de otro, hasta saber cómo reaccionar cuando el banco te echa para atrás una remesa. Es el complemento ideal para tener siempre a mano.

¿Cuál es la diferencia principal entre un fichero Norma 34 y un SEPA XML?

La gran diferencia está en su estructura y en dónde funcionan. El fichero de Norma 34 es un formato de texto plano, de toda la vida, con una longitud fija para cada línea. Se diseñó para funcionar solo dentro de España y, seamos sinceros, es una tecnología que ya se ha quedado muy atrás.

En cambio, un fichero SEPA XML es un estándar europeo basado en la norma internacional ISO 20022. Su estructura usa etiquetas, como una página web, lo que le da una flexibilidad enorme y permite meter mucha más información. A día de hoy, el SEPA XML es el único formato que aceptan los bancos para procesar adeudos directos en toda la Zona Única de Pagos en Euros.

¿Qué es exactamente el identificador del mandato en un fichero SEPA?

El identificador del mandato, que en el fichero XML verás como <MndtId>, no es más que una referencia única para la autorización de cobro que te firmó el cliente. Es, por así decirlo, el DNI de ese permiso.

Esta referencia la pones tú como empresa y no se puede repetir para la misma combinación de cliente y contrato. Es un campo vital que tienes que guardar a buen recaudo junto con la fecha de la firma, porque ambos datos son obligatorios en cada cobro que lances.

Por si te sirve de referencia, en la vieja Norma 34 este dato se llamaba “Referencia de la domiciliación”. La clave ahora es que con SEPA, la gestión y el seguimiento de estos mandatos son mucho más estrictos.

¿Por qué mi banco me ha rechazado un fichero SEPA XML?

Que el banco te devuelva una remesa es un fastidio, pero la buena noticia es que casi siempre se debe a errores de formato o de datos que se pueden evitar fácilmente. Las causas más habituales de un rechazo son:

• Errores en el IBAN: Un dígito de control mal calculado o un formato que no es válido y esa transacción queda fuera al instante.
• Las cuentas no cuadran: Si el importe total que pones en la cabecera (CtrlSum) no coincide con la suma de todos los adeudos, el banco rechazará el fichero entero.
• Formato de fecha incorrecto: Todas las fechas tienen que ir sí o sí en formato AAAA-MM-DD. Sin excepciones.
• Caracteres “raros”: Usar la “ñ” o cualquier otro símbolo no estándar puede dar problemas si el fichero no está codificado correctamente en UTF-8.
• Faltan datos del mandato: Olvidarse del identificador del mandato o de su fecha de firma es un error crítico que invalida el cobro.

Lo más inteligente es usar un validador automático o una herramienta especializada antes de enviar nada al banco. Es la mejor forma de cazar estos fallos y asegurarte de que la remesa entra a la primera.

¿Qué diferencia hay entre el esquema SEPA CORE y el B2B?

Cuando preparas un fichero de adeudos, tienes que elegir entre dos esquemas. La decisión depende de a quién le vayas a cobrar.

• Esquema CORE: Es el básico y el que se usa el 99% de las veces. Te sirve para cobrar a cualquier cliente, ya sea un particular, un autónomo o una empresa. Lo importante es que ofrece un plazo de devolución de hasta 8 semanas sin dar explicaciones, y de hasta 13 meses si el cobro no estaba autorizado.
• Esquema B2B (Business-to-Business): Como su nombre indica, está pensado solo para cobrar a otras empresas o autónomos. Su gran diferencia es que el cliente renuncia al derecho de devolución. Esto hace que los plazos para presentar los cobros sean más cortos, pero a cambio te exige llevar un control de los mandatos mucho más riguroso.

---

¿Harto de pelearte con la complejidad de los ficheros SEPA y los rechazos del banco? Con ConversorSEPA, puedes transformar tus ficheros de Excel, CSV o Norma 34 en un XML validado y listo para enviar en segundos. Automatiza tus remesas y ahorra tiempo y dolores de cabeza. Prueba ConversorSEPA gratis y simplifica tus cobros desde hoy mismo.

---

Artículos relacionados