¿Qué es un IBAN virtual?

Un IBAN virtual (vIBAN) es un número de cuenta bancaria internacional real y direccionable, emitido desde un rango dedicado y enrutado hacia una única cuenta maestra. Acepta pagos como cualquier otro IBAN —el pagador le envía una transferencia SEPA ordinaria desde su propio banco—, pero no mantiene saldo propio. Su función es la identificación: como cada IBAN virtual se asigna exactamente a un pagador o a una finalidad, un pago que llega a él ya indica quién lo envió y para qué es. El dinero se concentra automáticamente en la cuenta maestra; el IBAN virtual es la etiqueta del pago, no un segundo lugar donde vive el dinero.

Esa única propiedad —un IBAN por pagador— es toda la idea. Para entender por qué merece un artículo, empecemos por el problema que elimina.

El problema real: asociar el dinero a cada pagador

Imagina una empresa que cobra por transferencia bancaria en una sola cuenta: alquileres, suscripciones, facturas. Todos los abonos llegan al mismo IBAN, y la única pista sobre quién ha pagado es lo que el pagador haya escrito en el campo de concepto. Los conceptos se escriben mal, se truncan en algún punto de la cadena o se dejan en blanco. Una transferencia de 49,00 € con un concepto ilegible aún no son 49,00 € de ingresos reconocidos: es una incidencia. Alguien tiene que averiguar a qué cliente y a qué factura corresponde antes del cierre contable.

Con poco volumen, es una molestia. Con volumen de plataforma, es un departamento. Los motores de conciliación puntúan las facturas candidatas según importe, fecha y texto aproximado del concepto; lo que no logran asignar pasa a una cola manual. Y el fallo es estructural: cuando dos suscriptores pagan el mismo importe el mismo día sin concepto, ningún motor puede distinguirlos, porque la información que los diferenciaría nunca estuvo en el pago.

Un IBAN por pagador: identidad por diseño

Un programa de IBAN virtuales invierte el planteamiento. En lugar de pedir a cada pagador que etiquete bien su pago, le das a cada uno su propia dirección. Cada inquilino, suscriptor o vendedor de un marketplace paga a un IBAN que es solo suyo. El campo de concepto puede ser erróneo, estar vacío o estar en otro alfabeto: el abono se identifica igualmente, porque la identidad la lleva el número de cuenta.

El número de cuenta es un portador mucho mejor que el concepto. Un IBAN incluye sus propios dígitos de control, de modo que un IBAN mal escrito falla la validación en el banco del pagador antes de enviar la transferencia. Un concepto mal escrito pasa sin problema y se convierte en tu problema. Trasladar la identidad del campo de texto libre a la dirección mueve la comprobación de errores de tu back office al banco emisor.

Para el pagador no cambia nada: paga a un IBAN desde su app bancaria, como siempre. Toda la novedad está en el lado receptor: el pago llega ya etiquetado, y el campo de concepto vuelve a ser lo que siempre debió ser, una nota y no un sistema de identificación.

Cuando cada pagador paga a su propio IBAN, un pago entrante solo puede significar una cosa. El problema de la conciliación no se resuelve: deja de existir.

Dónde vive realmente el dinero

Por debajo, hay exactamente una cuenta maestra por divisa. Los IBAN virtuales se emiten desde rangos dedicados al programa y cada abono enviado a cualquiera de ellos se liquida en la cuenta maestra. No hay saldos por pagador que gestionar ni procesos de barrido de fin de día que trasladen fondos de miles de cuentas pequeñas a una sola: la concentración se produce por enrutamiento, no mediante transferencias adicionales que luego habría que conciliar por su cuenta.

Esto es también lo que hace que un IBAN virtual sea real y no un truco. Es direccionable desde cualquier banco, se compensa como cualquier transferencia SEPA y aparece en el extracto del propio pagador como la cuenta a la que pagó. Le falta justo lo que arrastra una cuenta completa: un saldo propio y un ciclo de vida más allá de la asignación y la baja.

Lo que un IBAN virtual no es

No es una subcuenta: una subcuenta mantiene saldo, requiere fondeo y desfondeo, y multiplica los libros que operas. No es un número de referencia virtual: estos siguen viajando en el campo de concepto y siguen dependiendo de que los pagadores copien bien las cadenas. Y no es un monedero: no se almacena nada en el propio vIBAN. Es una dirección con enrutamiento detrás: la construcción más estrecha que hace que un pago entrante se identifique por sí mismo.

Las devoluciones llegan con su motivo

Los pagos no solo llegan. Las cuentas se cierran, los bancos rechazan abonos y los pagadores reclaman transferencias. En un mundo con una única cuenta de cobro, una devolución es una pequeña investigación: qué pago ha vuelto, de quién era y si el asiento contable con el que se concilió debe revertirse.

En un programa de vIBAN, una devolución es un dato. Incluye su código de motivo, llega como un evento payment.returned asociado al mismo IBAN virtual que usó el abono original y tiene su propio apunte en el extracto. Sabes de quién era el pago y por qué ha vuelto antes de que nadie abra una incidencia. Las devoluciones pasan a ser filas que tramitar, no misterios que perseguir.

Una cola de excepciones, no un equipo de conciliación

Ningún diseño concilia el cien por cien de nada. Llegan abonos a vIBAN dados de baja. Hay duplicados. Alguien, de algún modo, paga directamente a la cuenta maestra. El objetivo no es que las excepciones sean imposibles, sino que sean raras y contables. En la demo de vIBAN de Protocore, el 99,6 % de los abonos se concilian automáticamente; el resto pasa a una cola de revisión con todo el historial del pagador adjunto, de modo que tratar una excepción parte del contexto y no de un extracto bancario y una hoja de cálculo.

Esa diferencia redefine el equipo. Una operación de conciliación crece con el volumen de pagos: más abonos, más abonos sin asignar, más personas. Un proceso de excepciones crece con el volumen de excepciones, que el diseño ya ha empujado hacia cero. Las personas que conservas trabajan anomalías reales, no conceptos reescritos. En nuestro stack, esa cola vive en Protocore Center (/products/center), la consola de operaciones donde cada acción privilegiada exige un motivo y queda en un registro de auditoría.

Emisión masiva, etiquetas de finalidad, plataformas

Un IBAN por pagador solo funciona si emitir uno no cuesta nada. Un casero con una docena de inquilinos podría crear los vIBAN a mano; un marketplace que da de alta a miles de vendedores, no. Por eso la emisión es una operación masiva. En la demo de vIBAN, un CSV con 2.400 pagadores se valida, muestra una vista previa del IBAN en cada fila y se emite en una sola acción: 2.400 pagadores, una operación y un paso de revisión intermedio.

Las etiquetas de finalidad mantienen los flujos separados a nivel de dirección: los alquileres aquí, las suscripciones allá, los pagos a vendedores del marketplace en su propio carril. Informar por finalidad se convierte en un filtro en lugar de un proyecto, y cada vIBAN tiene su propio extracto —CSV o PDF— mientras la cuenta maestra sigue siendo la fuente única de verdad por debajo. Cuando un pagador se va, su vIBAN se da de baja: el historial se conserva, la dirección deja de aceptar nuevos abonos.

Dónde encaja en una arquitectura de pagos

Los IBAN virtuales son infraestructura de cobro. Dan a las transferencias bancarias entrantes lo que los pagos con tarjeta siempre han tenido: la identidad adjunta al propio pago, no escrita a su lado. En el ecosistema de Protocore, los pedidos de pago por transferencia de Gateway llevan referencias de vIBAN, y Center trabaja las excepciones que deja la conciliación. La página de producto en /products/viban recorre el ciclo completo —emitir, compartir, conciliar, gestionar excepciones, informar— con los mismos datos de demo que se usan aquí.

Y un límite honesto: si recibes un puñado de transferencias al mes, basta una convención de conceptos y diez minutos de contabilidad. Los IBAN virtuales se justifican cuando el volumen ha convertido la conciliación en un proceso: rentas de alquiler, cobros de suscripciones, marketplaces; en cualquier lugar donde la pregunta de quién te ha pagado se plantea miles de veces al mes.