Verificar IBAN: cómo comprobar correctamente cualquier número de cuenta

Una transferencia está preparada, la remesa está a punto de enviarse y, aun así, la ejecución fracasa por una sola cadena de caracteres. No por el importe. No por el mandato. Sino por un IBAN con un pequeño error de entrada o una cuenta formalmente válida, pero prácticamente inutilizable.

Justo aquí surge un malentendido en muchas empresas. Quien comprueba un IBAN en línea suele dar por sentado que con ello también se asegura que el pago llegará realmente a buen término. Eso no es así. Al verificar un IBAN hay una diferencia entre corrección formal y usabilidad operativa. Para transferencias individuales privadas, el primer nivel suele bastar. Para adeudos SEPA, pagos recurrentes a proveedores y remesas masivas, no.

Por qué es decisiva una comprobación correcta del IBAN

Desde el 1 de febrero de 2014, el IBAN es obligatorio para todas las transferencias y adeudos en la zona SEPA, y en España sustituyó al antiguo Código Cuenta Cliente (CCC) como identificador de las cuentas. Desde entonces, para las transferencias SEPA basta con el IBAN: el BIC dejó de ser necesario. En la práctica, esto significa que el IBAN ya no es solo un campo adicional, sino el identificador central para ejecutar los pagos, tal y como recuerda el Banco de España al explicar qué se esconde tras los números de tu cuenta corriente.

El problema empieza donde las empresas confunden una comprobación en línea con una certeza real de pago. Muchas herramientas solo responden a la pregunta de si la cadena es formalmente plausible. No responden automáticamente si la cuenta es realmente utilizable en las operaciones, si los datos están actualizados o si la cuenta de destino es adecuada para el procedimiento deseado.

El error de razonamiento más común

Una secuencia típica es esta: un empleado toma un IBAN de un correo, un cliente lo teclea en un formulario o se importa una lista de proveedores desde Excel. El número pasa la comprobación estándar. Después, todos asumen que todo está limpio. El error solo aparece en la ejecución. Para entonces, el trabajo ya ha fluido dentro del proceso de pago.

Regla práctica: un dígito de control de IBAN superado todavía no es una señal de aprobación para una remesa crítica para el negocio.

Para las empresas, esto tiene consecuencias directas. Los pagos se retrasan. Los adeudos se devuelven. El equipo tiene que aclarar consultas, corregir registros y volver a crear ficheros de pago. A eso se suman posibles comisiones y, sobre todo, una fricción innecesaria con clientes, proveedores y la propia administración.

La validez formal no es lo mismo que la capacidad de pago

Los comprobadores gratuitos en particular son útiles cuando quieres comprobar rápidamente el formato de un solo número. No hay nada que objetar a eso. Lo que suele faltar es el segundo nivel: comprobar si la cuenta es coherente y si es adecuada para el proceso SEPA previsto.

Desde el punto de vista profesional, la pregunta decisiva no es, por tanto, si un IBAN “parece válido”. Lo decisivo es qué tipo de validación se necesita para el respectivo proceso de negocio. Para una comprobación manual puntual, una herramienta básica suele bastar. Para remesas, importaciones de ERP o flujos de pago automatizados, se necesita más.

La estructura de un IBAN español y el dígito de control

Quien quiera comprobar correctamente un IBAN español debería entender primero su estructura. Eso desmitifica el número de inmediato. Un IBAN español no es un bloque aleatorio de caracteres, sino que sigue una estructura fija.

El IBAN español tiene obligatoriamente 24 caracteres y consta del código de país ES, dos dígitos de control que validan todo el código, y los 20 dígitos del CCC: 4 dígitos de entidad, 4 de oficina o sucursal, 2 dígitos de control internos y 10 del número de cuenta. El código de entidad lo asigna el Banco de España, tal y como resume la explicación de BBVA sobre los 24 caracteres del IBAN en España.

Qué significan las partes individuales

Componente	Función
ES	Identifica a España según el estándar ISO
Dígitos de control (IBAN)	Detectan errores de entrada en todo el número (módulo 97)
Entidad (4 dígitos)	Identifica la entidad de crédito (código del 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 concreta

El número de cuenta puede contener ceros a la izquierda. Precisamente eso es una fuente de error frecuente en el día a día cuando se trasladan datos de formatos heredados, de documentos en papel o de exportaciones de ERP.

Quien quiera profundizar en la derivación y el cálculo encontrará una explicación técnica limpia sobre cómo calcular un IBAN.

Cómo funciona el dígito de control

La lógica propiamente dicha reside en el método módulo 97 según ISO 13616. El principio es sobrio, pero muy eficaz. Los primeros cuatro caracteres se mueven al final, las letras se convierten en números y el resultado global debe dar un resto de 1 al dividir entre 97.

A primera vista parece matemático, pero en el día a día es sobre todo un mecanismo de seguridad contra los errores de entrada típicos. Los dígitos transpuestos, las posiciones olvidadas o los caracteres mal copiados se detectan a menudo antes de que el pago se envíe siquiera. Conviene no confundir este control con los dos dígitos de control internos del CCC, que se calculan con módulo 11 y verifican la coherencia de entidad, oficina y cuenta.

Un dígito de control no es decoración. Es el freno de errores incorporado del número de cuenta.

Por qué la entidad y la oficina siguen siendo importantes para el negocio

Muchos equipos tratan el IBAN como una caja negra completa. Para los procesos operativos, eso es poco práctico. En España, el código de entidad y el de oficina siguen siendo claramente visibles dentro del IBAN (posiciones 5 a 12). Eso es valioso, porque permite reconocer a qué entidad y sucursal pertenece la cuenta y si es sensata una comprobación adicional.

Para empresas con pagos recurrentes, esto es especialmente relevante cuando se migran datos heredados o cuando las cuentas llevan años en el sistema. El IBAN puede verse formalmente estable, pero el código de entidad contenido en él es un punto de control práctico que muchos comprobadores simples no cotejan de forma consistente.

Comprobación de IBAN manual y programática

Una vez entendido el mecanismo, un IBAN puede rastrearse incluso sin herramienta. Esto no está pensado para las operaciones diarias, pero ayuda a evitar errores de implementación. Ahí es exactamente donde fracasan muchos desarrollos propios.

La validación del IBAN español sigue estrictamente el algoritmo módulo 97, y un error técnico crítico reside en la falta de normalización de la entrada. Se refiere a casos como espacios no eliminados o una escritura inconsistente, que provocan una interrupción incluso antes del cálculo propiamente dicho. Por eso conviene apoyarse en la estructura oficial descrita por el Banco de España y la Asociación Española de Banca, que detallan la estructura del IBAN español y sus dígitos de control.

Cómo se realiza la comprobación manual

Tomemos un IBAN español como ejemplo, sin obsesionarnos con un número concreto. El proceso manual es siempre el mismo:

1. Limpiar la entrada Eliminar espacios, llevar todo a una escritura uniforme.

2. Mover los primeros cuatro caracteres ESpp... se convierte en ...ESpp.

3. Convertir las letras en números E se convierte en 14, S en 28.

4. Comprobar el número resultante contra 97 Solo si el resto al final es 1, el IBAN es formalmente válido.

El punto de la limpieza es más importante de lo que parece. Quien toma entradas directamente de formularios, ficheros CSV o copiar-pegar de correos debe prestar especial atención a espacios, separadores invisibles y caracteres especiales copiados por accidente.

Un proceso de comprobación práctico para desarrolladores

Para los sistemas, el regex por sí solo no basta. Un regex solo comprueba el formato básico. La validación propiamente dicha siempre necesita además el cálculo módulo 97.

import re

def validate_spanish_iban(iban):
    iban = iban.replace(" ", "").upper()

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

    rearranged = iban[4:] + iban[:4]
    converted = ""

    for ch in rearranged:
        if ch.isalpha():
            converted += str(ord(ch) - 55)
        else:
            converted += ch

    remainder = 0
    for digit in converted:
        remainder = (remainder * 10 + int(digit)) % 97

    return remainder == 1

JavaScript funciona con el mismo patrón:

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

  if (!/^ES\d{22}$/.test(iban)) {
    return false;
  }

  const rearranged = iban.slice(4) + iban.slice(0, 4);

  let converted = '';
  for (const ch of rearranged) {
    if (/[A-Z]/.test(ch)) {
      converted += (ch.charCodeAt(0) - 55).toString();
    } else {
      converted += ch;
    }
  }

  let remainder = 0;
  for (const digit of converted) {
    remainder = (remainder * 10 + parseInt(digit, 10)) % 97;
  }

  return remainder === 1;
}

Qué sale mal a menudo en los desarrollos propios

La mayoría de los errores son poco espectaculares. Precisamente por eso son tan caros en la operación.

• Falta de normalización Si no se eliminan los espacios o separadores, la comprobación fracasa innecesariamente pronto.

• Solo formato, sin dígito de control Un regex como ES más 22 dígitos no basta. Así se aceptan valores que parecen formales pero son matemáticamente erróneos.

• Conversión de letras errónea La asignación A=10 hasta Z=35 debe implementarse correctamente (para ES, E=14 y S=28).

Quien comprueba un IBAN en el código nunca debería confiar solo en el patrón visible. El patrón reconoce la forma. El dígito de control reconoce el error.

Para las herramientas internas se aplica, por tanto, un principio sencillo: si el volumen es pequeño, una función propia sólida puede bastar. En cuanto los datos de pago vienen de varias fuentes o se procesan automáticamente, el riesgo de casos especiales aumenta rápidamente.

Herramientas en línea y los límites de la comprobación gratuita

Los comprobadores de IBAN gratuitos en la web tienen su lugar. Para consultas individuales en el día a día son prácticos. Un empleado comprueba rápidamente un número de cliente, la administración verifica un dato de un correo o un equipo de ventas quiere ver si una cuenta es formalmente plausible.

Revisa las utilidades publicadas en la página de utilidades SEPA y elige conscientemente según el propósito. Para una simple comprobación individual, el validador IBAN o la herramienta Comprobar IBAN, que además muestran la entidad y datos básicos, son más útiles que un simple “válido/no válido”.

Para qué sirven estas herramientas

Uso	¿Adecuado?	Por qué
Comprobación individual manual	Sí	Rápida, sin configuración
Control antes de la entrada de datos	Sí, con limitaciones	Buena como primer obstáculo
Comprobación masiva desde Excel o ERP	Más bien no	Demasiado manual y no escalable
Minimización de riesgos en el proceso de pago	No por sí sola	La comprobación formal no basta

El verdadero inconveniente no está en la calidad de estas herramientas, sino en el alcance de su comprobación. Un comprobador gratuito suele responder solo a la pregunta sintáctica. Sin embargo, para las empresas suele ser decisiva la pregunta operativa: ¿se puede ejecutar de forma fiable el proceso SEPA previsto con esta cuenta?

La brecha de negocio

Comprobar solo longitud y dígito de control no garantiza que la operación llegue a buen término. Una cuenta puede estar cerrada, pertenecer a otro titular o no admitir el procedimiento previsto. Y desde el 9 de octubre de 2025 se añade una capa más: la Verificación del Beneficiario (VoP), obligatoria en toda la UE, comprueba que el nombre del beneficiario coincide con el IBAN antes de ejecutar la transferencia.

Este es el punto que muchas empresas subestiman. Un IBAN puede ser formalmente limpio y aun así fracasar en el proceso, porque la cuenta no está operativa como asume el equipo o porque el nombre del titular no coincide con el registrado. Con la VoP, si el resultado es “no coincidente” o “casi coincidente” y aun así se continúa, el dinero se envía al IBAN indicado y podría no llegar al beneficiario deseado.

Una comprobación web gratuita es un filtro. No es un sustituto de un proceso de pago robusto.

Cuándo bastan las herramientas gratuitas y cuándo no

En mi opinión, un comprobador web basta en tres situaciones: en comprobaciones individuales, en consultas internas y en la primera comprobación de plausibilidad de nuevos datos maestros. No basta cuando las remesas se crean automáticamente, cuando los adeudos se ejecutan en serie o cuando la empresa quiere reducir sistemáticamente comisiones, devoluciones y retrabajo operativo.

En cuanto los datos de pago ya no se comprueban individualmente a mano, la diferencia entre “formalmente correcto” y “utilizable con seguridad en el proceso” se vuelve económicamente relevante.

Automatización con una API para la máxima seguridad

Las empresas que generan regularmente ficheros SEPA o toman datos de pago de ERP, tienda, CRM o Excel deberían automatizar la comprobación. No por comodidad, sino porque así se atrapan los errores más comunes exactamente donde surgen: antes del envío al banco.

Las API de validación de IBAN no comprueban solo los dígitos de control, sino también si un IBAN tiene un código de entidad y un número de cuenta nacionales válidos y qué compatibilidad SEPA ofrece la entidad para modos como B2B, COR1, SCC, SCT y SDD, tal y como explica la descripción de la API de validación de iban.com.

Qué hace mejor una API

La mayor ventaja no es la velocidad. Es la consistencia. Cada IBAN entrante pasa por las mismas reglas. Esto reduce las excepciones manuales, los errores de interpretación y los problemas de datos silenciosos que, de otro modo, solo saldrían a la luz en la remesa.

Para los equipos técnicos, además vale la pena una documentación de API que encaje directamente en los procesos existentes. Una referencia práctica para ello es la documentación técnica de API de GenerateSEPA, cuando los ficheros de pago y la comprobación de IBAN deben integrarse en un flujo de trabajo automatizado.

Criterios importantes al elegir

• ¿La solución comprueba solo el módulo 97 o también los datos bancarios? Esto separa los comprobadores simples de los servicios aptos para producción.

• ¿Proporciona información adicional para los procedimientos SEPA? Esto es especialmente relevante para los procesos de adeudo y los flujos dependientes de la entidad.

• ¿Se puede disparar la comprobación antes de la exportación o importación del XML? Solo entonces detienes los errores lo bastante pronto.

Quien quiera ver cómo se construyen tales procesos en la práctica en torno a los ficheros SEPA también puede ver este breve ejemplo:

El beneficio operativo es claro. La API no sustituye la decisión profesional en el equipo financiero. Pero le quita al equipo la comprobación técnica recurrente y convierte los controles caso por caso en un estándar reproducible.

Buenas prácticas para pagos SEPA sin errores en 2026

Quien comprueba los IBAN limpiamente reduce no solo los riesgos de error. Construye un proceso de pago más estable. Para 2026 sigue siendo válida la misma regla básica: no todo IBAN formalmente correcto es automáticamente una cuenta operativa y segura.

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

• Comprobar el IBAN en la entrada Los errores deberían hacerse visibles en el formulario, en la importación o en la actualización de datos maestros. No solo en la remesa.

• Combinar dos niveles Primero la comprobación formal, luego el cotejo con los datos y los requisitos del procedimiento SEPA previsto, incluida la Verificación del Beneficiario.

• No asegurar los procesos masivos manualmente En cuanto se procesan listas de Excel, CSV o ERP, la comprobación manual es demasiado propensa a errores.

• Cuestionar los datos heredados con regularidad Los datos maestros crecidos con el tiempo a menudo parecen limpios, aunque nunca se hayan comprobado.

• Distinguir entre válido y activo Una comprobación de IBAN confirma en primer lugar la corrección formal. No es automáticamente la prueba de que una cuenta esté activa o siga siendo utilizable sin fricciones en el contexto de negocio deseado.

Qué funciona en la práctica

Las empresas van más seguras con un modelo escalonado. Al frente del proceso está una comprobación de plausibilidad inmediata. Detrás, para pagos críticos para el negocio, sigue una validación técnica más profunda. Y al final del todo, la exportación al formato SEPA debería trabajar solo con datos ya comprobados.

Quien deja que los pagos se “prueben” solo en el envío traslada el control de calidad al punto más caro del proceso.

Para equipos pequeños, una separación clara entre la comprobación caso por caso y el procesamiento masivo productivo suele bastar. Para organizaciones en crecimiento vale la pena un flujo de trabajo consistente, en el que datos maestros, validación y generación de ficheros se piensen juntos. Ahí es exactamente donde surge el mayor beneficio de verificar el IBAN de forma limpia.

---

Si generas ficheros SEPA desde Excel, CSV, JSON o los cuadernos AEB y quieres integrar la comprobación de IBAN directamente en el proceso, GenerateSEPA es una opción objetiva. La plataforma convierte los datos de pago en XML SEPA, admite flujos de trabajo automatizados mediante API e integra validaciones para que las cuentas defectuosas no salgan a la luz solo al enviar al banco.

---

Preguntas frecuentes

¿Una comprobación de IBAN en línea garantiza que el pago tendrá éxito?

No necesariamente. Las herramientas en línea suelen responder solo a la corrección formal. Si la cuenta está activa y es apta para tu proceso SEPA puede requerir comprobaciones de negocio y del banco adicionales.

¿Cuáles son las partes de un IBAN español?

ES más dos dígitos de control del IBAN, cuatro dígitos de entidad, cuatro de oficina, dos de control del CCC y diez del número de cuenta. Los ceros a la izquierda en la cuenta son válidos y frecuentes en datos heredados.

¿Qué error afecta a muchos IBAN españoles no válidos?

Una parte importante falla porque no se normalizó la cadena — espacios o mayúsculas inconsistentes — antes de aplicar módulo 97.

¿Cómo deberían asegurar las empresas los pagos masivos?

Combina validación en la entrada, comprobaciones automatizadas de listas y exportes que solo usen registros ya verificados. Así el control de calidad se aleja del paso más costoso.

---

Artículos relacionados