Qué es la RUM en SEPA
2026-07-21
La Referencia Única de Mandato (RUM) es un código alfanumérico único de 35 caracteres que identifica un único mandato de adeudo directo SEPA (la orden de domiciliación) y vincula cada cobro con la autorización legal del deudor. La asigna el acreedor, debe permanecer siempre igual para el mismo mandato y es técnicamente tan importante que los errores de longitud o de unicidad pueden provocar el rechazo del fichero XML SEPA o la devolución del recibo.
Si trabaja con una hoja de Excel para adeudos, conoce la situación típica. Los importes son correctos, los IBAN se ven limpios, las fechas de vencimiento están puestas y, aun así, el banco informa después escuetamente de que el fichero fue rechazado. A menudo el problema no es el importe, sino un identificador discreto que pasa desapercibido en segundo plano.
Justo aquí muchos equipos tropiezan con la pregunta: ¿qué es la RUM en el procedimiento SEPA? ¿Por qué es tan importante y por qué el camino desde un Excel usable hasta un fichero XML apto para el banco fracasa tan a menudo por su causa?
La RUM parece inofensiva en el día a día. En la práctica es uno de los puntos donde los procesos limpios se separan del trabajo manual propenso a errores. Quien prepara remesas de adeudos debe gestionar no solo importes y cuentas, sino también mantener para cada mandato una referencia limpia, única y permanentemente consistente.
Introducción: el obstáculo invisible en los pagos SEPA
Es fin de mes. Una compañera de administración exporta las partidas abiertas del ERP, añade los datos que faltan en Excel y construye con ello la siguiente remesa de adeudos. Todo parece plausible. Poco después llega la respuesta del banco: fichero rechazado.
El mensaje de error suele ser escueto y poco útil. Para alguien nuevo en el equipo, parece un caso técnico excepcional. Para un responsable financiero con experiencia, suele ser una señal de alarma: primero comprobar los datos maestros, luego los datos del mandato, luego la RUM.
Por qué se pasa por alto la RUM con tanta frecuencia
El importe, el nombre y el IBAN se ven de inmediato. La RUM, en cambio, no es un campo que reciba atención de forma automática en las hojas de Excel clásicas. Muchas hojas de cálculo han ido creciendo con el tiempo. Una columna se llama “Mandato”, otra “Ref”, una tercera “Referencia de cliente”. Entonces alguien construye un fichero XML a partir de ellas y solo se da cuenta durante el envío de que la lógica interna no era limpia.
Las situaciones de partida típicas son estas:
- Ficheros de Excel antiguos: un equipo copia registros de mes en mes y no se da cuenta de que la misma referencia se usa varias veces.
- Exportación de ERP sin asignación clara: el sistema entrega números de contrato, pero no separa limpiamente qué campo debería ser luego la referencia del mandato.
- Mantenimiento manual posterior: una persona añade valores a mano y cambia accidentalmente una referencia existente en un adeudo recurrente.
- Conversión de CSV a XML sin validación: el fichero se genera técnicamente, pero no se comprueba lo suficiente desde el punto de vista de negocio.
Regla práctica: cuando un fichero SEPA es rechazado “inesperadamente”, la causa no suele estar en el pago en sí, sino en la identidad del mandato.
Por tanto, la RUM no es una nota al margen. Es el ancla a través de la cual banco, mandato y cobro se encuentran. Quien la gestiona limpiamente reduce consultas, retrabajo y ciclos de corrección apresurados poco antes del vencimiento. Y no es un detalle menor: si la referencia no está correctamente cumplimentada, puede entenderse que la domiciliación no está autorizada y el deudor podrá devolver el recibo durante un plazo de hasta 13 meses.
De la lógica de la hoja de cálculo a la lógica bancaria
En Excel, los equipos piensan fila a fila. Un banco piensa en campos obligatorios estructurados dentro de un fichero XML. Esa es una diferencia importante. En la hoja de cálculo, un valor puede estar “presente de algún modo”. En el proceso SEPA, debe estar exactamente en el lugar correcto, en el formato correcto y con el significado correcto.
Por eso muchos procesos no fracasan por falta de cuidado, sino por una ruptura de medio. El departamento ve una lista. El banco ve un documento XML conforme a ISO 20022. En medio decide la calidad de la estructura de datos.
Qué es exactamente la Referencia Única de Mandato
La Referencia Única de Mandato, o RUM, es el identificador único de un único mandato de adeudo directo SEPA, es decir, de la orden de domiciliación firmada por el deudor. Puede imaginarla como el número de seguimiento de un envío. Solo que no sigue un paquete, sino el permiso de un cliente para que usted cobre importes de su cuenta.
La definición formal en la práctica
La RUM es un dato obligatorio de la orden de domiciliación, un código alfanumérico con una longitud máxima de 35 caracteres. El acreedor debe generarla y asignarla de forma única para cada mandato concreto. Sirve para identificar los adeudos asociados a ese mandato y para hacer la operación rastreable dentro del estándar ISO 20022, tal y como recogen las preguntas frecuentes sobre el mandato SEPA de sepaesp.es, el portal de referencia coordinado por el Banco de España.
Aún más importante es la segunda parte: esta referencia debe permanecer idéntica para el primer adeudo y todos los siguientes del mismo mandato recurrente. En España, el documento de mandato sigue el modelo actualizado en el folleto 50 de la serie de normas y procedimientos bancarios, tanto en su versión básica (CORE) como en la B2B. Si la referencia no está correctamente cumplimentada o se duplica, la operación puede no considerarse autorizada.
Qué aporta la RUM en la práctica
La RUM convierte un cobro en una operación asignable, verificable y fiable. Sin ella falta el vínculo técnico entre el adeudo y el mandato firmado.
Tres puntos son decisivos en el día a día:
- Unicidad: cada orden de domiciliación necesita su propia referencia.
- Persistencia: una RUM, una vez asignada, permanece inalterada durante toda la vida de ese mandato.
- Trazabilidad: en caso de consultas, devoluciones o reclamaciones, permite identificar exactamente el mandato afectado.
Una buena RUM no es creativa, sino fiable. No tiene que verse bonita. Tiene que ser única y permanente.
Un ejemplo sencillo
Tomemos un cliente con una cuota de socio recurrente. El mandato se firmó una vez. Para este mandato usted asigna una referencia, por ejemplo basada en su sistemática interna. Esta referencia no pertenece entonces a la factura del mes ni al cobro individual, sino al mandato en sí.
Muchos principiantes confunden precisamente esto. Piensan que cada adeudo necesita una RUM nueva. Es un error. Lo nuevo es la operación (el primer adeudo se marca como “FRST” y los siguientes como “RCUR”). Lo que permanece igual es la referencia del mandato subyacente.
Distinguir RUM, referencia de mandato e identificador de acreedor
En el día a día, se confunden a menudo RUM, referencia de mandato e identificador de acreedor. Es comprensible, porque los tres aparecen en el mismo mundo de las domiciliaciones. Sin embargo, para una documentación de procesos limpia, hay que separar claramente los roles.
La respuesta corta es: RUM y referencia de mandato son, en la práctica, lo mismo, mientras que el identificador de acreedor describe algo distinto. Una referencia identifica el mandato concreto. La otra identifica a su empresa como emisora del adeudo dentro de SEPA.
Los identificadores SEPA de un vistazo
| Característica | RUM / referencia de mandato | Identificador de acreedor |
|---|---|---|
| Qué se identifica | Un único mandato | El acreedor (el emisor de la remesa) |
| Para qué se necesita | Asignar el adeudo a la orden de domiciliación | Identificar de forma inequívoca al emisor en SEPA |
| Quién lo asigna | El acreedor que cobra | Se obtiene a través de la entidad bancaria (con base en el NIF/CIF) |
| ¿Permanece igual? | Sí, para este mandato | Sí, para la empresa (estable en el tiempo) |
| Pregunta típica | “¿Qué orden de domiciliación ampara este cobro?” | “¿Quién está cobrando aquí?” |
Dónde surge la confusión
En muchas empresas, el campo se llama “referencia de mandato” en Excel. En la documentación o en herramientas internacionales se lee con más frecuencia “RUM” o su equivalente inglés “UMR”. En el fondo se refiere a lo mismo. Lo técnicamente relevante es que el mandato se referencie de forma única.
El identificador de acreedor está al lado, en otro nivel. No le dice al banco qué mandato se refiere, sino de qué empresa procede el adeudo. Debe ser estable en el tiempo para permitir al deudor y a su entidad retroceder o devolver operaciones, reclamar y verificar la existencia de un mandato. Quien confunde los dos puede introducir datos formalmente, pero el fichero sigue siendo inverosímil desde el punto de vista de negocio.
Una ayuda mnemotécnica para nuevos miembros del equipo
Cuando incorporo a nuevos compañeros, uso esta distinción sencilla:
- RUM/referencia de mandato: la matrícula del mandato individual
- Identificador de acreedor: la identidad de empresa de quien cobra
Esto ayuda de inmediato, porque la dirección de la mirada se aclara. Una cosa es el contrato con el cliente. Otra, su empresa dentro del sistema SEPA.
Quien quiera clasificar el identificador de acreedor en detalle encontrará una visión limpia en la utilidad de identificador de acreedor SEPA.
Cuando todo en un fichero se ve correcto pero los mandatos no se pueden asignar limpiamente, a menudo no hay detrás una avería bancaria, sino una confusión entre la referencia de mandato y el identificador de empresa.
Dónde aparece la RUM en el fichero XML SEPA
Para el banco no cuenta su fichero de Excel, sino el fichero XML. Ese es el momento en que una lista se convierte en una remesa estandarizada. Allí la RUM no está en cualquier comentario, sino en un lugar técnicamente definido.
El campo relevante en el XML
En un adeudo directo SEPA (fichero pain.008 o cuaderno 19), la RUM aparece dentro del bloque de transacción. Se encuentra normalmente en el área del mandato bajo la etiqueta <MndtId>. Esa es la identificación del mandato, que le indica al banco en qué orden de domiciliación concreta se basa este cobro.
Un ejemplo simplificado tiene este aspecto:
<DrctDbtTxInf>
<PmtId>
<EndToEndId>FACTURA-2026-001</EndToEndId>
</PmtId>
<DrctDbtTx>
<MndtRltdInf>
<MndtId>MANDATO-CL4711</MndtId>
<DtOfSgntr>2026-01-15</DtOfSgntr>
</MndtRltdInf>
</DrctDbtTx>
</DrctDbtTxInf>
El asunto no es que tenga que escribir XML de memoria. Lo que importa es que entienda cómo una columna en Excel se convierte en un campo obligatorio en un fichero estrictamente estructurado.
Por qué este lugar es decisivo
Los bancos comprueban los ficheros XML de forma automática. El sistema no busca una referencia “en cualquier parte”, sino que la espera en el lugar previsto dentro de la estructura de datos. Si el campo está vacío, mal mapeado o rellenado con el valor de origen equivocado, el adeudo no se procesa limpiamente.
Por eso los pasos de conversión son tan delicados:
- El nombre de columna en Excel no basta: “Mandato” puede significar muchas cosas.
- El mapeo decide: la columna de origen correcta debe colocarse exactamente sobre
<MndtId>. - Los errores de formato no se quedan locales: un solo campo obligatorio puede inutilizar todo el fichero.
Para una estructura ilustrativa de un fichero de adeudos ayuda un ejemplo de fichero PAIN.008.001.02, porque allí la estructura XML se hace visible en su contexto.
La traducción práctica desde Excel
En la hoja de cálculo quizá tenga una columna llamada “referencia de mandato”. En el XML, el mismo contenido debe llegar como <MndtId>. Si su conversión no hace esta asignación limpiamente, la lógica de negocio está bien pensada, pero no es técnicamente efectiva.
Esta es la razón por la que las exportaciones simples a menudo no bastan. Generan un fichero. Pero no comprueban automáticamente si la información correcta acabó en el lugar correcto.
Fuentes de error comunes con la RUM y cómo evitarlas
La mayoría de los problemas de RUM no surgen de una lógica bancaria complicada, sino de pequeños errores de proceso. Eso es lo que los hace tan traicioneros. Un equipo trabaja correctamente, pero el mantenimiento de las referencias es inconsistente. Ahí es exactamente donde surgen rechazos, devoluciones y aclaraciones innecesarias.
Errores que veo con más frecuencia en la práctica
- Asignación duplicada: dos mandatos distintos reciben la misma RUM. Esto destruye la unicidad.
- Modificación posterior: en un adeudo recurrente se ajusta la RUM existente por motivos cosméticos.
- Entradas demasiado largas: una referencia crecida internamente encaja desde el punto de vista de negocio, pero supera el límite de 35 caracteres.
- Caracteres especiales problemáticos: valores de sistemas antiguos contienen caracteres que pueden causar problemas en el XML o en los procesos bancarios.
- Falta de mantenimiento previo: la referencia se improvisa poco antes del cobro.
El último punto en particular es peligroso. Si la RUM no se mantiene como parte fija del proceso de mandato, se convierte en una solución de urgencia en la remesa de cobro.
Por qué las devoluciones son especialmente críticas aquí
En el procedimiento de adeudo directo SEPA, la RUM es una pieza técnica clave para reclamaciones y gestión de devoluciones. Cuando un deudor devuelve un adeudo, la devolución se vincula directamente con la RUM específica. Esto permite a las entidades gestionar el mandato afectado y tratar de forma coherente los cobros futuros bajo la misma RUM. Por eso, la referencia debe ser estable en el tiempo, como recuerda la guía de buenas prácticas para la emisión de adeudos SEPA de CaixaBank.
Esto tiene una consecuencia práctica: un error de RUM no es solo un defecto cosmético en sus datos maestros. Puede influir en cómo se gestionan las devoluciones y los cobros posteriores, y el deudor dispone de un plazo de hasta 13 meses para devolver un recibo si la domiciliación no estaba correctamente autorizada.
Aviso importante: quien “reconstruye” manualmente las RUM tras una devolución a menudo no resuelve el problema de fondo. Con frecuencia solo desplaza un error de documentación a la siguiente remesa de cobro.
Una lógica de control sencilla para el día a día
Antes de que un fichero vaya al banco, al menos debería existir esta comprobación:
- ¿Es cada RUM única por mandato?
- ¿Ha permanecido inalterada la misma RUM en los cobros recurrentes?
- ¿Está la referencia dentro del límite de 35 caracteres?
- ¿Se mapeó el campo desde la fuente correcta?
- ¿Se han limpiado los datos heredados de Excel, CSV o los cuadernos AEB?
Quien no quiera hacer esta comprobación manualmente puede validar un fichero XML de antemano con el validador XML de adeudos directos SEPA frente a errores típicos de estructura y de campos obligatorios.
Prevención organizativa en lugar de reparación posterior
Una gestión limpia de la RUM no es un paso de corrección puntual. Pertenece al propio proceso de mandato. Esto significa:
- Asignarla al crear el mandato: no solo en el siguiente cobro.
- Guardarla en un sistema rector único: no en varias listas con versiones divergentes.
- Bloquear o documentar los cambios: para que nadie sobrescriba accidentalmente referencias existentes.
Una vez que lo configura limpiamente, el esfuerzo de conciliación dentro del equipo disminuye notablemente. Sobre todo, los nuevos compañeros trabajan entonces no con suposiciones, sino con reglas claras.
Trasladar la RUM desde Excel o cuadernos AEB a XML SEPA
El verdadero reto rara vez empieza en la definición de la RUM. Empieza en el traslado desde un conjunto de datos desordenado a un fichero XML formalmente correcto. Excel, CSV y las exportaciones de los antiguos cuadernos AEB (por ejemplo, el cuaderno 19 de adeudos) o del ERP suelen contener ya la información necesaria. Simplemente no está estructurada de forma consistente.
Cómo preparar sensatamente el fichero de origen
En la práctica, la preparación suele funcionar en cuatro pasos:
- Cree una columna fija para la RUM. No en notas de texto libre, no repartida en varias columnas auxiliares.
- Identifique cada mandato exactamente una vez. Un cliente puede tener varios mandatos. La RUM pertenece al mandato, no de forma general al número de cliente.
- Limpie los duplicados históricos. Sobre todo en listas de Excel copiadas, las referencias antiguas aparecen varias veces.
- Documente el mapeo. La columna “RUM” debe asignarse de forma única al campo XML
<MndtId>en la exportación.
Dónde se desborda el trabajo manual
Con volúmenes pequeños quizá aún domine el proceso manualmente. En cuanto hay varias fuentes implicadas, aumentan los riesgos. Entonces el equipo trabaja rápidamente con ficheros auxiliares, estados intermedios y distintas versiones de exportación. Ahí es exactamente donde se pierden la consistencia y la trazabilidad.
Un conversor especializado puede hacer esta transición mucho más limpia. GenerateSEPA es un ejemplo. El servicio está diseñado para trasladar formatos de Excel, CSV, JSON o los cuadernos AEB a ficheros XML SEPA válidos. Se pueden asignar columnas a los campos SEPA necesarios en lugar de construir el XML a mano. Quien quiera ver el flujo de trabajo encontrará una guía práctica para crear un fichero de adeudos directos SEPA desde Excel.
Desde la perspectiva de administración, el objetivo no es “generar XML”. El objetivo es que los datos de negocio aterricen de forma limpia, repetible y verificable en el campo XML correcto.
Una forma de trabajar robusta para equipos
Para pymes y equipos de administración, una regla sencilla ha demostrado su valía: la RUM se mantiene allí donde se gestionan los mandatos, y no solo donde se generan las remesas. La exportación a XML es entonces meramente la traducción técnica de un conjunto de datos ya limpio.
Esto ahorra rondas de corrección. Sobre todo, evita que alguien empiece, poco antes del vencimiento, a reunir referencias de distintas listas antiguas.
Conclusión: cómo la gestión de la RUM se vuelve un juego de niños
La pregunta qué es la RUM en SEPA suena al principio a jerga técnica. En la práctica trata de algo muy tangible: la identidad única de un mandato. Cuando esta identidad se mantiene limpiamente, los adeudos recorren el proceso de forma ordenada, rastreable y técnicamente estable.
Los mayores problemas no surgen en el reglamento, sino en la transición de datos de origen desordenados a un fichero XML estructurado. Precisamente por eso la RUM es tan a menudo el cuello de botella que se pasa por alto. Es pequeña, pero decisiva.
Quien trabaja con Excel, CSV o cuadernos AEB no debería tratar la RUM como una columna secundaria. Pertenece a los datos maestros del mandato, con asignación clara, mantenimiento consistente y mapeo fiable. Para comprobar el formato antes de generar el XML, puede usar el generador de mandatos SEPA y el validador XML de adeudos.
Si quiere trasladar adeudos directos o transferencias SEPA desde Excel, CSV, JSON o los cuadernos AEB a ficheros XML aptos para el banco, puede evaluar GenerateSEPA como servicio en la nube. La plataforma admite el mapeo de columnas a campos SEPA, procesa distintos formatos de entrada y ayuda a generar un fichero XML válido para el envío al banco a partir de conjuntos de datos existentes.
Preguntas frecuentes
- ¿Qué es la RUM en los adeudos directos SEPA?
- La Referencia Única de Mandato es el identificador único de un mandato de adeudo concreto. Vincula cada cobro con la autorización firmada del cliente.
- ¿Cuánto puede medir una RUM?
- Hasta 35 caracteres de texto libre, asignados por el acreedor. Debe permanecer igual para el mismo mandato en todos los cobros posteriores.
- ¿La RUM es lo mismo que el identificador de acreedor?
- No. La RUM identifica el mandato concreto. El identificador de acreedor identifica a tu empresa como originador SEPA.
- ¿Por qué los bancos rechazan XML por la RUM?
- Las causas típicas son referencias duplicadas, valores cambiados en adeudos recurrentes o mapeo incorrecto desde columnas de Excel al campo MndtId del XML.
