Validación de IBAN de forma sencilla – guía completa

Cuando una remesa vuelve justo antes del envío al banco, el problema no suele estar en el XML, sino mucho antes. Un IBAN se trató como un número en Excel, un número de cuenta de un cuaderno AEB antiguo no se rellenó limpiamente o el nombre del beneficiario ya no coincide con los datos de cuenta almacenados. Justo entonces la validación de IBAN deja de ser un complemento agradable para convertirse en una necesidad.

En la práctica, los procesos rara vez fracasan por la teoría. Fracasan por CSV importados, campos crecidos con el tiempo y suposiciones silenciosas en el código. Quien procesa transferencias o adeudos en volumen necesita, por tanto, más que una simple comprobación de formato. Lo que importa es la combinación de una comprobación de estructura, la lógica de dígitos de control, un manejo de errores limpio y, desde la llegada de la Verificación del Beneficiario (VoP), también la separación entre la validación técnica del IBAN y la verificación real del beneficiario.

Introducción a la validación de IBAN

Muchos equipos conocen el patrón. El departamento mantiene los datos de cuenta en Excel, el ERP exporta un CSV y luego una herramienta o script construye el fichero SEPA. Mientras todo esté limpiamente formateado, el proceso funciona. Pero en cuanto un IBAN se descoloca, viajan espacios o aparece un formato heredado de un cuaderno AEB, la remesa se bloquea o genera consultas con el banco.

Para las pymes en particular, esto no es un problema marginal. Los datos vienen de distintas fuentes, a menudo sin reglas de campo uniformes. Una comprobación visual manual no basta entonces. No reconoce ni un dígito de control formalmente erróneo ni un IBAN mal compuesto lógicamente con un número de cuenta trasladado de forma incompleta.

Regla práctica: la validación de IBAN no pertenece solo al último paso antes del envío. Pertenece a la importación, al procesamiento y al punto final de aprobación.

Lo que funciona de forma fiable en los proyectos es un proceso de varias etapas. Primero el sistema comprueba la sintaxis. Luego viene la comprobación módulo 97. Después la aplicación evalúa casos especiales como campos de cuadernos AEB antiguos, ceros a la izquierda y la coherencia entre código de entidad, oficina y número de cuenta. Quien trabaja así reduce no solo los errores técnicos, sino que también ahorra tiempo en aprobaciones y retrabajo.

Entender la estructura del IBAN

La mayoría de los errores surgen porque la estructura del IBAN suena familiar, pero se implementa de forma imprecisa en el uso diario. Para España, la estructura es estricta. El IBAN español tiene una longitud fija de 24 caracteres y empieza por ES, seguido de un dígito de control de dos posiciones que valida todo el IBAN, y de los 20 dígitos del antiguo Código Cuenta Cliente (CCC): 4 dígitos de entidad, 4 de oficina o sucursal, 2 dígitos de control internos y 10 del número de cuenta. Cualquier desviación invalida el código, tal y como explica el Banco de España en su artículo sobre qué se esconde tras los números de tu cuenta corriente.

Los campos de un IBAN español

Un IBAN español se puede descomponer así:

Componente	Contenido	Significado
Código de país	ES	Identifica a España
Dígito de control	dos dígitos	Valida la totalidad del IBAN (módulo 97)
Entidad	4 dígitos	Identifica la entidad de crédito (código asignado por el Banco de España)
Oficina	4 dígitos	Identifica la sucursal
DC del CCC	2 dígitos	Dígitos de control internos del CCC (módulo 11)
Número de cuenta	10 dígitos	Identifica la cuenta

El punto crítico es el número de cuenta. En sistemas antiguos suele estar almacenado más corto. Para el IBAN no puede quedarse así. Los números de cuenta más cortos deben rellenarse por la izquierda con ceros para que el CCC se forme correctamente. Aquí es exactamente donde ocurren la mayoría de los errores silenciosos en las migraciones desde cuadernos AEB antiguos.

Dónde causan problemas los formatos históricos

Cuando un fichero de cuaderno AEB trabaja internamente todavía con campos separados o longitudes divergentes, no basta con concatenar los valores sin más. Solo una normalización correcta produce un CCC válido. En España conviene tener presentes dos niveles de control distintos: los dos dígitos de control internos del CCC, que se calculan con el algoritmo de módulo 11, y el dígito de control del propio IBAN, que se calcula con módulo 97. Una cadena formalmente plausible puede aún así apuntar a una cuenta cuyos dígitos de control internos no cuadran.

Un IBAN puede verse técnicamente limpio y aun así ser operativamente inutilizable si los datos de origen proceden de un conjunto antiguo con dígitos de control mal calculados.

Con datos trasladados, siempre miro dos cosas primero: si se han conservado los ceros a la izquierda y si el código de entidad y oficina son coherentes. Estas dos comprobaciones atrapan más errores en proyectos heredados que cualquier corrección manual posterior.

Realizar la comprobación módulo 97

La estructura por sí sola no basta. La siguiente comprobación dura es la comprobación módulo 97. Aquí, el resto de dividir el IBAN reordenado entre 97 debe ser exactamente 1, de lo contrario el IBAN se considera defectuoso. Este algoritmo está definido en la norma ISO 13616, la misma que fija la estructura del IBAN.

Como versión visual breve, ayuda esta ilustración:

El proceso sin magia

El algoritmo está estandarizado y es lo bastante simple como para implementarlo en cualquier lenguaje:

1. Mueve los primeros cuatro caracteres al final ESkk... se convierte en ...ESkk.

2. Convierte las letras en números A=10 hasta Z=35. Así, para E y S, queda 14 y 28.

3. Calcula el número resultante módulo 97 Para números grandes, lo mejor es procesar iterativamente como cadena.

4. Comprueba el resto Solo el valor de resto 1 es válido.

Qué sale mal en el software real

El error de implementación más común no es el algoritmo en sí, sino el preprocesamiento. Los desarrolladores no eliminan los espacios de forma consistente, dejan las minúsculas sin normalizar o convierten secuencias largas de dígitos en tipos de datos inadecuados para ello. En JavaScript esto es especialmente delicado cuando alguien trabaja con tipos numéricos en lugar de cadenas.

Un segundo error afecta a los números de cuenta procedentes de cuadernos AEB. Si falta el relleno a diez dígitos antes de construir el IBAN, toda la secuencia puede fracasar sintácticamente. Por eso siempre separo en los proyectos normalización, generación del IBAN y comprobación.

Si tu aplicación valida directamente contra datos en bruto, a menudo solo validas el estado de error. Normaliza primero, comprueba después.

Quien quiera probar una rutina de comprobación existente puede usar el validador IBAN de ConversorSEPA y comparar los resultados con su propia implementación. Para un contraste rápido es útil, pero no sustituye la lógica en tu propio flujo de datos.

Para ilustrar el camino de cálculo, este vídeo es útil:

Expresiones regulares y ejemplos de código

Regex es útil para la validación de IBAN, pero solo para la primera capa. Con ello compruebas la forma y los caracteres permitidos. Una validación real solo surge junto con reglas de longitud por país y el método módulo 97. Esto es especialmente relevante cuando tu sistema procesa más que IBAN españoles. El comprobador de IBAN de iban.com admite los 37 países miembros oficiales de SEPA y distingue estructuras de datos con reglas de longitud y de dígitos de control específicas de cada país.

Qué puede y qué no puede hacer regex

Para una comprobación aproximada de sintaxis de IBAN españoles basta un patrón como este:

^ES[0-9]{22}$

Para varios países la cosa se vuelve rápidamente inmanejable. Entonces es sensato un patrón más general:

^[A-Z]{2}[0-9]{2}[A-Z0-9]{1,30}$

Pero esto es solo un filtro de entrada. No dice nada sobre si la longitud encaja con el país o si el dígito de control es correcto.

Una breve clasificación:

• Bien adaptado para errores de forma tempranos como caracteres especiales, espacios o prefijos erróneos
• Mal adaptado para reglas detalladas específicas de cada país
• Inadecuado para la lógica de suma de control propiamente dicha

JavaScript para clientes y frontends de API

En el navegador o en Node.js suele bastar una combinación de normalización, comprobación de país y cálculo iterativo del módulo.

function validateSpanishIBAN(input) {
  const iban = input.replace(/\s+/g, '').toUpperCase();

  if (!/^ES[0-9]{22}$/.test(iban)) {
    return { valid: false, reason: 'Error de formato' };
  }

  const rearranged = iban.slice(4) + iban.slice(0, 4);
  const converted = rearranged.replace(/[A-Z]/g, ch => (ch.charCodeAt(0) - 55).toString());

  let remainder = 0;
  for (const digit of converted) {
    remainder = Number(String(remainder) + digit) % 97;
  }

  return { valid: remainder === 1, reason: remainder === 1 ? null : 'Dígito de control incorrecto' };
}

En lo que me fijo en el frontend:

• Conservar cadenas en lugar de conversión numérica
• Eliminar los espacios pronto
• Separar los mensajes de error entre error de formato y error de dígito de control

Python para backends y procesos por lotes

Python es muy adecuado para tareas de importación, procesamiento de ficheros y pipelines de datos.

import re

def validate_spanish_iban(value: str) -> dict:
    iban = re.sub(r"\s+", "", value).upper()

    if not re.fullmatch(r"ES\d{22}", iban):
        return {"valid": False, "reason": "Error de formato"}

    rearranged = iban[4:] + iban[:4]
    converted = "".join(str(ord(ch) - 55) if ch.isalpha() else ch for ch in rearranged)

    remainder = 0
    for digit in converted:
        remainder = int(f"{remainder}{digit}") % 97

    return {"valid": remainder == 1, "reason": None if remainder == 1 else "Dígito de control incorrecto"}

Tratar limpiamente los formatos AEB históricos

Con datos de cuadernos AEB antiguos, el arte no está en el regex, sino en la lógica previa. Para ello suelo colocar un pequeño paso de normalización antes de la validación propiamente dicha:

• Leer entidad y oficina por separado y llevarlas a su longitud (4 + 4)
• Rellenar el número de cuenta por la izquierda con ceros hasta 10 dígitos
• Solo entonces ensamblar el CCC completo
• Solo después calcular el módulo 97 del IBAN

Si tu sistema admite varios países, vale la pena una tabla de países en lugar de reglas codificadas en duro. Eso se mantiene mantenible. Un regex monstruoso, no.

Validación por lotes y manejo de errores

Las comprobaciones individuales están bien. En la práctica llegan listas. Ficheros de Excel, exportaciones CSV, cargas JSON de un ERP o stock heredado mixto de cuadernos AEB. Quien procesa estos datos en serie sin registro se está construyendo un trabajo de investigación posterior.

Qué demuestra su valía en tareas por lotes

Siempre trato el procesamiento por lotes como un pipeline con valores de estado claros. No solo válido o no válido, sino más bien importado, normalizado, formalmente no válido, sospechoso en cuanto al fondo y listo para aprobación. Así una ejecución se puede repetir limpiamente sin tocar todo de nuevo.

Para ficheros grandes, estas reglas funcionan bien:

• Usar chunking en lugar de cargar ficheros enteros de golpe en memoria
• Almacenar el valor original y la forma normalizada, para que las correcciones sigan siendo rastreables
• Registrar códigos de error en lugar de devolver solo “no válido”
• Construir tareas repetibles, para que las filas corregidas puedan comprobarse de nuevo

Casos de error típicos en el día a día

No todo IBAN no válido es un error de tecleo. Algunos registros fallan porque Excel truncó ceros a la izquierda. Otros porque en un ERP todavía viven definiciones de campo antiguas. Y desde la nueva Verificación del Beneficiario, un IBAN formalmente correcto a menudo ya no basta para las transferencias.

Muchos procesos existentes no tienen en cuenta la Verificación del Beneficiario (VoP), obligatoria en toda la UE desde el 9 de octubre de 2025 en virtud del Reglamento (UE) 2024/886, según la cual los bancos deben cotejar el nombre del beneficiario con el IBAN antes de ejecutar una transferencia. Si esta comprobación no cuadra, la operación puede detenerse o el usuario recibir una alerta, tal y como explica el Banco de España en su nota sobre el nuevo servicio gratuito de verificación del beneficiario. Para los pagos por lotes (ficheros de remesas), la VoP es opcional para el usuario no consumidor.

Una comprobación por lotes sin un registro de errores limpio es solo una vía rápida hacia un largo retrabajo manual.

Mi consejo es claro: separa la validación técnica de la aprobación de negocio. La primera etapa comprueba estructura y dígito de control. La segunda evalúa formatos heredados, nombres de beneficiario y necesidad de corrección. Ahí es exactamente donde un validador se convierte en un proceso robusto.

Integrar en sistemas y usar APIs

Para la integración hay dos vías limpias. O bien validas directamente con bibliotecas en tu propio stack, o externalizas partes de la comprobación a un servicio de API. Ambas tienen su lugar.

Biblioteca o API

Las bibliotecas directas encajan bien cuando necesitas control total. Funcionan sin dependencia de red, se integran a fondo en las tareas de importación y son ideales para simples comprobaciones de formato y de dígito de control.

Las API REST tienen sentido cuando quieres llevar la validación a varios sistemas sin mantener la lógica dos veces en todas partes. Esto es especialmente práctico cuando también se necesitan datos bancarios, asignación de BIC o conversión desde cuadernos AEB. Un ejemplo es GenerateSEPA, que convierte ficheros de Excel, CSV, JSON y los cuadernos AEB en XML SEPA y también proporciona una API JSON para la integración técnica.

Qué cuenta en entornos de producción

Desde octubre de 2025, los bancos deben verificar automáticamente nombre e IBAN del beneficiario antes de autorizar una transferencia SEPA. Para clasificar los procesos en torno a este requisito, es útil consultar el proceso de verificación de cuenta bancaria en el blog de GenerateSEPA.

Para la implementación técnica, me fijo en estos puntos:

• Autenticación con una gestión clara de claves
• Timeouts y reintentos solo donde tengan sentido desde el punto de vista de negocio
• Modelos de respuesta con códigos de error legibles por máquina
• Planificación de SLA para ventanas de pago críticas

Una API no es un sustituto de la calidad de datos interna. Es un punto de integración limpio. Si los datos de entrada llegan sin estructurar desde cuadernos AEB, el preprocesamiento debe resolverse igualmente de forma limpia en tu propio sistema.

Resumen y buenas prácticas

La validación de IBAN funciona de forma fiable cuando está construida en varias etapas. Primero viene la normalización de los datos, luego la comprobación de estructura, después la lógica módulo 97 y, finalmente, el tratamiento de negocio de formatos heredados, dígitos de control del CCC y verificación del beneficiario. Quien usa solo regex atrapa solo una parte de los errores.

La lista de comprobación breve para el día a día:

• Normaliza siempre las entradas
• Rellena correctamente los números de cuenta a 10 dígitos
• Nunca sustituyas el módulo 97 por regex
• Registra las tareas por lotes con códigos de error
• Trata la Verificación del Beneficiario por separado de la comprobación pura del IBAN

---

Si quieres trasladar ficheros de Excel, CSV, JSON o de los cuadernos AEB a procesos SEPA limpios, GenerateSEPA es una opción práctica. El servicio convierte el stock en XML SEPA válido, admite comprobaciones de IBAN y encaja con equipos que quieren procesar remesas recurrentes sin una instalación local.

---

Preguntas frecuentes

¿Qué diferencia hay entre comprobación de sintaxis y módulo 97?

La sintaxis revisa longitud, caracteres y estructura. El módulo 97 valida los dígitos de control sobre el IBAN normalizado. Juntos detectan la mayoría de errores de entrada y exportación.

¿Por qué fallan muchas validaciones en la normalización?

Espacios, minúsculas o celdas numéricas de Excel cambian la cadena antes del cálculo. Limpia la entrada primero y luego valida; si no, las herramientas marcan IBAN válidos como incorrectos.

¿Qué significa VoP para la validación de IBAN?

La Verificación del Beneficiario añade la comprobación nombre-cuenta en el banco del beneficiario. Trátala aparte de la lógica pura de módulo 97.

¿Cómo validar listas grandes de IBAN con eficiencia?

Usa trabajos por lotes con códigos de error legibles por máquina, registro por fila y pasos distintos de normalización, validación y export para evitar retrabajo manual antes del banco.

---

Artículos relacionados