¿Cuál es la diferencia entre el End-to-End ID y la información de remesa?

Piensa en un pago como en un paquete. El End-to-End ID es el número de seguimiento que acompaña al pago a lo largo de la cadena, y debe ser un identificador único a nivel de pago. La información de remesa es la nota dentro del paquete que le dice al destinatario para qué es el pago, normalmente el número de factura. Uno existe para la trazabilidad y el otro para ayudar al beneficiario a conciliar, así que no deben confundirse ni fusionarse.

¿Qué columna de la hoja de cálculo debería mapearse a EndToEndId?

Mapea tu identificador único de pago interno a EndToEndId y mapea la referencia de factura o de pago de cara al proveedor a la información de remesa, normalmente Ustrd. Un solo pago a un proveedor puede cubrir varias facturas o un abono, así que el ID de pago interno debe seguir siendo único aunque cambie la referencia comercial. El error común es mapear una única columna de Referencia en todas partes porque la etiqueta suena bien.

¿Por qué las buenas referencias deben ser cortas?

Los campos de referencia suelen estar limitados por los límites de transferencia y de extracto, con algunas referencias de transferencia limitadas a unos 18 caracteres y los campos del extracto ACH aún más cortos. Las referencias demasiado largas se truncan, y el truncamiento reduce las tasas de casación posteriores. Los identificadores compactos, como un número de factura más una pista del cliente, suelen funcionar mejor que una frase completa, porque las palabras extra son lo primero que cortan los bancos.

¿Puede una mala referencia hacer que un pago falle?

A menudo el banco acepta el fichero igualmente, así que el pago se liquida, pero esa es la prueba equivocada. La prueba verdadera es si el pago puede casarse correctamente después de la liquidación. Una referencia vaga, duplicada o truncada crea ruido de conciliación, casación manual y consultas de seguimiento aunque el dinero se haya movido con éxito. La mayoría de los errores que se achacan al XML son en realidad problemas de datos de origen y de mapeo aguas arriba.

Número de referencia bancaria: guía para equipos financieros

Abres el extracto bancario después de una remesa de pagos y ves una lista de transacciones entrantes o salientes con etiquetas vagas. “Transferencia.” “Pago.” A veces solo el nombre de un proveedor cortado. El dinero se movió, pero el trabajo contable no. Alguien todavía tiene que averiguar qué factura se pagó, qué cuenta de cliente debe saldarse y si la referencia que exportó tu banco es la misma que empezó en tu hoja de cálculo.

Esa brecha es donde vive la mayor parte de la fricción de la conciliación.

Para las pymes que trabajan desde Excel o CSV, el problema no suele ser el pago en sí. Son los datos de referencia. Si el número de referencia bancaria falta, es incoherente o está mapeado en el campo XML SEPA equivocado, el pago puede liquidarse igualmente, pero tu casación posterior se vuelve un caos rápidamente. Entonces los equipos lo parchean con notas manuales, cadenas de correos y cuentas puente.

Un proceso limpio empieza antes. Empieza cuando decides qué referencia pertenece a tu fichero de origen, dónde debe situarse en el XML y cuánta información es seguro enviar por los canales bancarios sin truncamiento ni ambigüedad.

Qué es un número de referencia bancaria

El número de referencia bancaria existe por una razón. Ayuda a los equipos financieros a conectar una transacción con el documento de negocio correcto.

Un profesional analizando registros de transferencias bancarias en la pantalla de un portátil con una tabla clara de historial de pagos.

Cuando ves un pago en un extracto bancario, el número de referencia bancaria suele ser el identificador de pago adjunto a esa transacción. En el trabajo financiero del día a día, aparece en los extractos o informes de conciliación y se usa para casar un pago con la factura o la cuenta correcta. En muchos sistemas suele ser el texto adjunto a una transacción, mientras que en algunos formularios de pago específicos de cada país puede ser un campo más formal de unos 20 a 30 dígitos para la casación automatizada y el procesamiento de cuadernos de pago, como describe la explicación de Paytia sobre los números de referencia bancaria.

Por qué les importa a los equipos financieros

Un miembro júnior del equipo a menudo piensa en la referencia como una simple nota. Ese es el modelo mental equivocado.

Una buena referencia forma parte de la estructura de control en torno a la aplicación de cobros. Permite que tu ERP, tu importación bancaria o tu herramienta de conciliación distinga un pago de otro sin que alguien lea cada línea manualmente. Si dos clientes pagan importes parecidos el mismo día, la referencia suele ser la única pista fiable que te dice a dónde pertenece el dinero.

Regla práctica: Si un pago no puede casarse con la referencia y el importe juntos, la referencia no está haciendo suficiente trabajo.

Eso importa en ambos lados del libro mayor:

Cuentas por cobrar: Los clientes usan la referencia que solicitaste para que tu equipo pueda saldar correctamente las facturas abiertas.
Cuentas por pagar: Tu equipo envía la referencia solicitada por el proveedor para que su equipo pueda identificar lo que pagaste.
Tesorería y auditoría: Las referencias claras facilitan el rastreo cuando alguien pregunta por qué se envió un pago o cómo se asignó el efectivo.

Cómo se ve en la práctica

El formato varía. Algunas referencias son números de factura cortos. Otras combinan un código de cliente y un ID de factura. En entornos de pago estructurados, el campo es más rígido y más importante de lo que mucha gente cree.

Para los equipos SEPA, esto también se solapa con los identificadores de transacción dentro del propio fichero de pago. El campo llamado End-to-End ID en los pagos SEPA no es lo mismo que un memorando informal tecleado en un portal bancario. Uno está pensado para identificar el pago a lo largo de la cadena. El otro puede llevar el significado comercial de para qué es el pago.

Esa distinción es donde se tuercen muchos ficheros de pago impulsados por hojas de cálculo.

Tipos clave de números de referencia bancaria explicados

No todos los números de referencia sirven al mismo propósito. Los equipos financieros a menudo usan un mismo término para varios campos distintos, y luego se preguntan por qué el proveedor vio un valor mientras el extracto bancario mostraba otro.

Una infografía que explica cuatro números de referencia bancaria clave, incluyendo SEPA, SWIFT y los detalles de pago del extracto.

La distinción sencilla que ayuda

Piensa en un pago como en un paquete.

El End-to-End ID es el número de seguimiento. Acompaña al pago a lo largo del recorrido.

La información de remesa (remittance information) es la nota dentro del paquete. Le dice al destinatario para qué es el pago.

Si los mezclas, el pago puede moverse igualmente, pero la información que tu beneficiario necesita para conciliar puede faltar o quedar enterrada en el campo equivocado.

Las categorías principales que encuentran los equipos

Tipo	Qué hace	Uso típico
Referencia del extracto o detalles del pago	Describe la transacción tal como aparece en extractos o exportaciones	Casar pagos durante la conciliación
End-to-End ID	Identifica una instrucción de pago a lo largo de la cadena SEPA	Trazabilidad entre remitente, banco y destinatario
Información de remesa	Lleva el contexto de negocio, como los números de factura	Ayuda al beneficiario a aplicar el pago
Referencia de transacción generada por la red	Identifica la transacción dentro de una red de pagos	Seguimiento y verificación

La confusión suele venir de asumir que las cuatro son intercambiables. No lo son.

Los campos SEPA que más importan

En los ficheros de pago de las pymes, estos son los dos campos que merece la pena tratar con cuidado:

End-to-End ID (<EndToEndId>)
Úsalo para un identificador único a nivel de pago. Debe mantenerse estable para esa transacción y ayudar a rastrearla si alguien necesita investigar más adelante.
Información de remesa (<RmtInf>, a menudo <Ustrd>)
Úsala para el significado de negocio del pago. Lo más habitual es el número de factura, la referencia de un abono, la cuenta del cliente o una combinación compacta de esos elementos.

Si un proveedor dice: “Por favor, indique la factura 45678 en el pago”, esa instrucción suele pertenecer a la información de remesa, no a tu ID de seguimiento interno.

Un pago puede ser rastreable sin ser fácil de conciliar. Eso ocurre cuando el End-to-End ID está relleno pero el campo de remesa no contiene la referencia comercial que el beneficiario espera.

Más allá de SEPA

Otras vías de pago usan sus propios equivalentes operativos. En las grandes redes de pago, un número de referencia de transacción identifica de forma única cada pago. Por ejemplo, Fedwire usa un Federal Wire Reference Number, también llamado Fed Reference Number o número IMAD/OMAD, creado cuando se inicia la transferencia. La orientación del sector describe estos identificadores como de normalmente 16 a 22 dígitos, lo que refleja las exigencias de trazabilidad de los sistemas de pago de alto valor, como se expone en esta descripción de Qualia sobre los Federal Wire Reference Numbers.

Ese es un contexto útil porque refuerza un punto operativo básico. Algunas referencias existen para ayudar a los sistemas a rastrear el pago. Otras existen para ayudar a las personas y a los sistemas contables a entender para qué era el pago.

La misma separación también aparece en los cobros recurrentes. Si tu equipo gestiona adeudos directos, la referencia del adeudo directo SEPA juega un papel distinto al de los detalles de remesa de texto libre que puedes usar en las transferencias.

Dónde encontrar el número de referencia correcto

La mayoría de los problemas de referencia empiezan antes de que exista el fichero XML. Alguien copió el campo equivocado del documento de origen.

En las facturas de proveedor

Empieza por la propia factura. Los proveedores no siempre etiquetan la referencia de pago de forma coherente, así que tu equipo tiene que leer con intención.

Busca primero uno de estos elementos:

Referencia de pago: El proveedor te dice explícitamente qué indicar.
Número de factura: A menudo se usa cuando no se da una referencia de pago separada.
Número de cuenta de cliente: Común con suministros, telecomunicaciones, leasing y proveedores de servicios recurrentes.
Código de pago estructurado: En algunos mercados, el proveedor proporciona una referencia numérica formal en lugar de texto libre.

Si la factura incluye tanto un número de factura como una “referencia a indicar en el pago”, usa la referencia de pago. No asumas que son intercambiables.

En las remesas y extractos de clientes

Cuando entra dinero, la referencia puede aparecer de forma distinta según el canal. En un portal bancario puede mostrarse como “detalles”. En otra exportación puede estar repartida en campos narrativos. En un paquete de contabilidad puede aterrizar en las columnas de memorando, referencia o descripción.

Un hábito útil es comparar tres vistas de la misma transacción:

La factura original o la solicitud de pago
Los detalles de la transacción en el portal bancario
El libro mayor importado o la pantalla de conciliación

Esa comparación te muestra qué campo sobrevive al recorrido y cuál se pierde o se altera.

Si tu personal no puede señalar la misma referencia en la factura, en el banco y en el libro mayor, tu proceso todavía tiene un problema de mapeo.

Qué enseñar a los nuevos miembros del equipo

Dales un orden de precedencia estricto. Evita las conjeturas.

Usa la referencia de pago solicitada por el proveedor si existe.
Si no, usa el número de factura.
Si se pagan varias facturas juntas, usa una referencia de lote compacta y envía la remesa detallada por separado si tu proceso lo permite.
Nunca sustituyas una referencia externa solicitada por una etiqueta interna que solo tu empresa entiende.

Esa única disciplina evita mucho tráfico de correos del tipo “te hemos pagado, pero no lo has asignado”.

Crear y mapear referencias en tus ficheros de pago

Esta es la parte que importa cuando construyes ficheros SEPA desde Excel o CSV. Un número de referencia bancaria no es útil a menos que el valor de tu hoja de cálculo aterrice en el campo XML correcto.

Empieza por el diseño del fichero de origen

Antes de subir nada a una herramienta de conversión o a una plantilla bancaria, da forma a la hoja de cálculo para que cada fila responda a tres preguntas separadas:

¿A quién se paga?
¿Cuánto se paga?
¿Qué referencia debe viajar con el pago?

Eso significa que tus datos de origen deberían tener normalmente una columna dedicada al contenido de la referencia. No la entierres dentro de un campo de comentarios con texto extra. No confíes en que los usuarios la tecleen de forma distinta cada mes.

Para los pagos salientes, una hoja limpia suele incluir columnas como nombre del proveedor, IBAN, importe, número de factura, referencia del proveedor e ID de pago interno. Aunque algunos valores se solapen, mantenlos separados en la hoja de cálculo. La separación te da opciones al mapear.

Qué poner dónde

La mayor decisión práctica es decidir qué columna de la hoja de cálculo se mapea a EndToEndId y cuál se mapea a la información de remesa.

Usa esta regla:

Pon tu identificador único de pago interno en EndToEndId
Pon la referencia de factura o de pago de cara al proveedor en la información de remesa, normalmente Ustrd

Si usas el número de factura como ambos campos, puedes salir del paso en casos simples. Pero con el tiempo eso crea duplicación evitable y dificulta la gestión de excepciones. Un solo pago a un proveedor puede cubrir varias facturas, un abono o una diferencia de liquidación. Tu identificador de pago interno debería seguir siendo único incluso cuando cambie la referencia comercial.

Mapeo de datos de Excel a campos de referencia SEPA

Tus datos (columna de Excel)	Campo SEPA recomendado	Propósito
ID de pago interno	EndToEndId	Trazabilidad única de la instrucción de pago
Número de factura del proveedor	RmtInf / Ustrd	Le dice al beneficiario qué factura se está pagando
Código de cuenta del proveedor	RmtInf / Ustrd si es necesario	Añade desambiguación cuando el número de factura por sí solo no basta
ID de la remesa (lote)	Normalmente no de cara al beneficiario	Control interno, no un sustituto del texto de remesa
Notas libres	Úsalas con moderación en Ustrd	Solo si son concisas y relevantes para la conciliación

Qué funciona bien para las pymes

Un formato práctico para los cobros es una referencia compacta y legible, como código de cliente más código de factura. El patrón exacto importa menos que la coherencia. El equipo financiero debería poder interpretarla rápidamente, y el cliente debería poder copiarla sin confusión.

Para los pagos, no inventes tu propio estilo cuando el proveedor ya te ha dicho qué enviar. Refleja la referencia esperada por el proveedor lo más fielmente posible.

Cuando los equipos maduran su proceso, a menudo documentan las reglas de referencia junto a soluciones de contabilidad financiera más amplias, porque la calidad de la conciliación depende tanto del diseño del proceso como de la generación del fichero. La configuración más limpia es aquella en la que la aprobación de facturas, la preparación de pagos y la creación del fichero bancario preservan todas la misma lógica de referencia.

Mapear de CSV a XML SEPA

El paso operativo es directo:

Exporta tu lista de pagos desde Excel o CSV.
Identifica la columna exacta que contiene la referencia de cara al beneficiario.
Mapea esa columna al campo de remesa SEPA.
Mapea una columna única separada a EndToEndId.
Valida antes de generar el XML final.

El error que veo con más frecuencia es mapear una única columna de “Referencia” en todas partes porque la etiqueta suena bien. En la práctica, una etiqueta puede ocultar dos significados: una clave de pago interna y una referencia de conciliación del proveedor.

Si conviertes hojas de cálculo de forma rutinaria, una herramienta que soporte el mapeo de campos desde ficheros planos a XML SEPA ayuda a reducir la edición manual. Un ejemplo es la conversión de CSV a XML SEPA, donde el paso operativo importante no es solo la conversión del fichero, sino asignar cada columna de origen al campo SEPA correcto.

Atajo del controller: Si el destinatario necesita leerlo para asignar el pago, pertenece a la información de remesa. Si tu equipo necesita rastrear la instrucción de principio a fin, pertenece a EndToEndId.

ConversorSEPA es una opción usada para este tipo de flujo. Convierte formatos Excel, CSV, JSON y AEB heredados en XML SEPA y permite a los usuarios mapear columnas a campos SEPA antes de exportar.

Evitar errores comunes con los números de referencia

Muchos equipos asumen que los problemas de referencia son menores porque el banco acepta el fichero igualmente. Esa es la prueba equivocada. La prueba verdadera es si el pago puede casarse correctamente después de la liquidación.

Una infografía que ilustra errores comunes en los números de referencia y buenas prácticas para evitarlos en los pagos.

Errores que generan ruido en la conciliación

El primer mal hábito es usar valores vagos como “pago”, “factura” o solo el nombre del proveedor. Esas referencias apenas tienen valor desambiguador. Pueden parecer legibles, pero no ayudan cuando varias transacciones comparten el mismo importe o contraparte.

El segundo es sobrecargar el campo. Los campos de referencia suelen estar limitados por los límites de transferencia y de extracto. Una fuente del sector señala que las referencias de pago de las transferencias pueden estar limitadas a 18 caracteres, mientras que los campos de presentación del extracto ACH pueden ser tan cortos como 16 caracteres para el nombre de la empresa y 10 caracteres para la descripción del apunte. Las referencias mal diseñadas se truncan, y el truncamiento reduce las tasas de casación posteriores, como se explica en esta discusión de WorldRemit sobre las referencias de transferencias bancarias.

Un tercer problema es mezclar texto de negocio con puntuación o hábitos de formato copiados de las hojas de cálculo. Aunque un fichero valide, los símbolos extra, los saltos de línea o el espaciado incoherente pueden hacer que la narrativa resultante del extracto sea más difícil de interpretar.

Mejores hábitos

Usa referencias que sean cortas, lo bastante únicas para la situación y estables entre sistemas.

Prefiere identificadores compactos: Número de factura más una pista de cliente o cuenta suele funcionar mejor que una frase.
Mantén un significado por campo: No uses el mismo campo para notas internas de flujo de trabajo y referencias de pago externas.
Valida antes de enviar: Comprueba cómo aparecerá el valor después de exportar, no solo cómo se ve en Excel.

Más corto y más claro suele ganar a más largo y “más informativo”. Las palabras extra son a menudo lo primero que los bancos cortan.

Soluciones prácticas para fallos comunes

Error	Consecuencia	Mejor enfoque
Texto genérico como “pago”	Casación manual y consultas de seguimiento	Usa la referencia de la factura o la solicitada por el proveedor
Cadenas de referencia muy largas	Truncamiento en el extracto o en la ruta de la transferencia	Conserva solo el dato mínimo desambiguador
Una referencia reutilizada en muchos pagos	Pista de auditoría ambigua	Haz que cada instrucción de pago sea identificable de forma única
Códigos solo internos enviados al proveedor	El proveedor no puede asignar el cobro	Envía la referencia comercial externa que espera

La disciplina con las referencias también afecta a los cobros y al seguimiento de morosos. Si tu libro mayor contiene cobros medio casados o mal aplicados porque las referencias eran débiles, los informes de antigüedad se vuelven menos fiables. Los equipos que trabajan en gestionar facturas vencidas con eficacia suelen descubrir que el control de crédito se vuelve más fácil cuando las referencias de pago son coherentes desde el principio.

Juntándolo todo: un ejemplo práctico de SEPA

Toma una fila de pago sencilla de un fichero Excel.

Proveedor	IBAN	Importe	ID de pago interno	Referencia de factura
Supplier Corp	DE00EXAMPLEIBAN	EUR 250.00	PAY-2025-0001	INV-987

El punto importante no es el importe. Es cómo se separan los dos valores de referencia. PAY-2025-0001 es tu identificador de transacción interno. INV-987 es lo que el proveedor necesita ver para aplicar el pago.

Cómo se mapea en el XML

Un fragmento XML SEPA simplificado tendría este aspecto:

<CdtTrfTxInf>
` ` ` PAY-2025-0001` ` ` ` 250.00` ` ` ` Supplier Corp` ` ` ` ` ` DE00EXAMPLEIBAN` ` ` ` ` ` INV-987` ` </CdtTrfTxInf>`

Qué hace cada línea

<EndToEndId> lleva la identidad de seguimiento del pago a lo largo del proceso SEPA. Tu equipo puede buscarlo más adelante si el banco, el proveedor o el auditor preguntan por esa transferencia concreta.

<Ustrd> lleva la referencia comercial. Esa es la parte que con más probabilidad ayudará al equipo financiero del proveedor a saldar la factura sin escribirte para pedir respaldo.

Si intercambiaras esos valores, el fichero podría aceptarse igualmente. Pero el proveedor vería PAY-2025-0001 en lugar de INV-987, lo que puede no significar nada para él. Ese es el tipo de error que crea retrasos de conciliación aunque el propio pago tenga éxito.

La lógica de la hoja de cálculo al fichero

Un administrativo júnior debería poder explicar el mapeo en una frase:

La columna “ID de pago interno” va a EndToEndId
La columna “Referencia de factura” va a RmtInf/Ustrd

Esa es toda la disciplina. Mantén separados el identificador del pago y el significado de la remesa.

Para los adeudos directos, la estructura del XML cambia, y los ejemplos difieren de las transferencias. Si tu equipo también trabaja con cobros, revisar un ejemplo de fichero PAIN.008 ayuda a aclarar cómo aparecen las referencias y los campos relacionados con el mandato en ese tipo de mensaje.

Cuando los datos de origen están limpios, el XML SEPA deja de parecer técnico. Se convierte en una traducción controlada de columnas de hoja de cálculo a campos legibles por el banco. La mayoría de los errores de pago que se achacan a “el XML” son en realidad errores de datos de origen y de mapeo aguas arriba.

Si tu equipo construye ficheros de pago SEPA desde hojas de cálculo y quiere reducir los errores de mapeo manual, ConversorSEPA es una opción práctica. Convierte formatos Excel, CSV, JSON y bancarios heredados en XML SEPA, te permite mapear columnas a los campos requeridos y ayuda a mantener coherentes las referencias de pago antes de que el fichero vaya al banco.

Preguntas frecuentes

¿Cuál es la diferencia entre el End-to-End ID y la información de remesa?: Piensa en un pago como en un paquete. El End-to-End ID es el número de seguimiento que acompaña al pago a lo largo de la cadena, y debe ser un identificador único a nivel de pago. La información de remesa es la nota dentro del paquete que le dice al destinatario para qué es el pago, normalmente el número de factura. Uno existe para la trazabilidad y el otro para ayudar al beneficiario a conciliar, así que no deben confundirse ni fusionarse.
¿Qué columna de la hoja de cálculo debería mapearse a EndToEndId?: Mapea tu identificador único de pago interno a EndToEndId y mapea la referencia de factura o de pago de cara al proveedor a la información de remesa, normalmente Ustrd. Un solo pago a un proveedor puede cubrir varias facturas o un abono, así que el ID de pago interno debe seguir siendo único aunque cambie la referencia comercial. El error común es mapear una única columna de Referencia en todas partes porque la etiqueta suena bien.
¿Por qué las buenas referencias deben ser cortas?: Los campos de referencia suelen estar limitados por los límites de transferencia y de extracto, con algunas referencias de transferencia limitadas a unos 18 caracteres y los campos del extracto ACH aún más cortos. Las referencias demasiado largas se truncan, y el truncamiento reduce las tasas de casación posteriores. Los identificadores compactos, como un número de factura más una pista del cliente, suelen funcionar mejor que una frase completa, porque las palabras extra son lo primero que cortan los bancos.
¿Puede una mala referencia hacer que un pago falle?: A menudo el banco acepta el fichero igualmente, así que el pago se liquida, pero esa es la prueba equivocada. La prueba verdadera es si el pago puede casarse correctamente después de la liquidación. Una referencia vaga, duplicada o truncada crea ruido de conciliación, casación manual y consultas de seguimiento aunque el dinero se haya movido con éxito. La mayoría de los errores que se achacan al XML son en realidad problemas de datos de origen y de mapeo aguas arriba.