Què és un IBAN virtual?

Un IBAN virtual (vIBAN) és un número de compte bancari internacional real i adreçable, emès des d'un rang dedicat i encaminat cap a un únic compte mestre. Accepta pagaments com qualsevol altre IBAN —el pagador hi envia una transferència SEPA ordinària des del seu banc—, però no té saldo propi. La seva funció és la identificació: com que cada IBAN virtual s'assigna exactament a un pagador o a una finalitat, un pagament que hi arriba ja diu qui l'ha enviat i per a què serveix. Els diners es concentren automàticament al compte mestre; l'IBAN virtual és l'etiqueta del pagament, no un segon lloc on viuen els diners.

Aquesta única propietat —un IBAN per pagador— és tota la idea. Per entendre per què mereix un article, comencem pel problema que elimina.

El problema real: assignar els diners als pagadors

Imagineu una empresa que cobra per transferència bancària en un sol compte: lloguers, subscripcions, factures. Tots els ingressos arriben al mateix IBAN, i l'única pista de qui ha pagat és el que el pagador hagi escrit al camp de referència. Les referències s'escriuen malament, es trunquen pel camí o es deixen en blanc. Una transferència de €49.00 amb la referència il·legible encara no són €49.00 d'ingressos reconeguts: és una incidència. Algú ha de descobrir a quin client i a quina factura correspon abans que es tanquin els llibres.

Amb volums baixos és una molèstia. Amb volums de plataforma és un departament. Els motors de conciliació puntuen les factures candidates segons l'import, la data i el text aproximat de la referència; el que no poden col·locar va a una cua manual. I el punt feble és estructural: quan dos subscriptors paguen el mateix import el mateix dia sense referència, cap motor no els pot distingir, perquè la informació que els diferenciaria mai no va ser al pagament.

Un IBAN per pagador: identitat per disseny

Un programa d'IBAN virtuals capgira el disseny. En lloc de demanar a cada pagador que etiqueti bé el pagament, doneu a cada pagador la seva pròpia adreça. Cada llogater, subscriptor o venedor d'un marketplace paga a un IBAN que és només seu. El camp de referència pot ser incorrecte, buit o estar en un altre alfabet: l'ingrés s'identifica igualment, perquè la identitat la porta el número de compte.

El número de compte és un portador molt millor que la referència. Un IBAN inclou els seus propis dígits de control, de manera que un IBAN mal escrit no passa la validació al banc del pagador abans que la transferència s'enviï. Una referència mal escrita passa sense problemes i es converteix en un problema vostre. Traslladar la identitat del camp de text lliure a l'adreça trasllada el control d'errors del vostre back office al banc emissor.

Per al pagador no canvia res: paga a un IBAN des de l'app del seu banc, com sempre. Tota la novetat és al costat receptor: el pagament arriba preetiquetat, i el camp de referència torna a ser el que hauria d'haver estat sempre: una nota, no un sistema d'identificació.

Quan cada pagador paga al seu propi IBAN, un pagament entrant només pot significar una cosa. El problema de la conciliació no es resol: deixa d'existir.

On viuen realment els diners

Per sota, hi ha exactament un compte mestre per divisa. Els IBAN virtuals s'emeten des de rangs dedicats al programa, i tots els ingressos enviats a qualsevol d'ells s'abonen al mestre. No hi ha saldos per pagador per gestionar ni processos de buidatge diaris que moguin fons de milers de comptes petits a un de sol: la concentració es fa per encaminament, no amb transferències addicionals que després haurieu de conciliar també.

Això és també el que fa que un IBAN virtual sigui real i no un truc. És adreçable des de qualsevol banc, es liquida com qualsevol transferència SEPA i apareix a l'extracte del pagador com el compte al qual ha pagat. El que no té és exactament el que arrossega un compte complet: un saldo propi i un cicle de vida més enllà de l'assignació i la baixa.

El que un IBAN virtual no és

No és un subcompte: un subcompte té saldo, cal dotar-lo i buidar-lo, i multiplica els llibres majors que heu d'operar. No és un número de referència virtual: aquests continuen viatjant pel camp de referència i continuen depenent que els pagadors copiïn bé les cadenes. I no és una cartera: no s'emmagatzema res al vIBAN en si. És una adreça amb encaminament al darrere: la construcció més estreta que fa que un pagament entrant s'identifiqui sol.

Les devolucions tornen amb el motiu adjunt

Els pagaments no només arriben. Es tanquen comptes, els bancs rebutgen ingressos, els pagadors reclamen transferències. En un món amb un sol compte de cobrament, una devolució és una petita investigació: quin pagament ha tornat, de qui era i cal desfer l'assentament amb què es va conciliar?

En un programa vIBAN, una devolució és una dada. Porta el seu codi de motiu, arriba com un esdeveniment payment.returned contra el mateix IBAN virtual que va usar l'ingrés original i té el seu propi recompte a l'extracte. Sabeu de qui és el pagament que ha tornat, i per què, abans que ningú obri una incidència. Les devolucions passen a ser files per tractar, no misteris per perseguir.

Una cua d'excepcions, no un equip de conciliació

Cap disseny concilia el cent per cent de res. Arriben ingressos a vIBAN donats de baixa. Hi ha duplicats. Algú, d'alguna manera, paga directament al compte mestre. L'objectiu no és fer impossibles les excepcions, sinó fer-les poc freqüents i comptables. A la demo de vIBAN de Protocore, el 99.6% dels ingressos es concilia automàticament; la resta va a una cua de revisió amb l'historial complet del pagador adjunt, de manera que tractar una excepció parteix del context, no d'un extracte bancari i un full de càlcul.

Aquesta diferència remodela l'equip. Una operació de conciliació creix amb el volum de pagaments: més ingressos, més ingressos sense assignar, més persones. Un procés d'excepcions creix amb el volum d'excepcions, que el disseny ja ha empès cap a zero. Les persones que us queden treballen anomalies reals, no referències reescrites. A la nostra pila, aquesta cua viu a Protocore Center (/products/center), la consola d'operacions on cada acció privilegiada requereix un motiu i queda registrada en un registre d'auditoria.

Emissió massiva, etiquetes de finalitat, plataformes

Un IBAN per pagador només funciona si emetre'n un no costa res. Un propietari amb una dotzena de llogaters podria crear vIBAN a mà; un marketplace que incorpora milers de venedors, no. Per això l'emissió és una operació massiva. A la demo de vIBAN, un CSV de 2,400 pagadors es valida, mostra una previsualització de l'IBAN a cada fila i s'emet en una sola acció: 2,400 pagadors, una operació, un pas de revisió pel mig.

Les etiquetes de finalitat mantenen els fluxos separats a escala d'adreça: els lloguers aquí, les subscripcions allà, els pagaments del marketplace al seu propi carril. Informar per finalitat passa a ser un filtre i no un projecte, i cada vIBAN té el seu propi extracte —CSV o PDF— mentre el compte mestre continua sent l'única font de veritat per sota. Quan un pagador marxa, el seu vIBAN es dona de baixa: l'historial es manté, l'adreça deixa d'acceptar ingressos nous.

On encaixa en una pila de pagaments

Els IBAN virtuals són infraestructura de cobrament. Donen a les transferències bancàries entrants el que els pagaments amb targeta sempre han tingut: la identitat adjunta al pagament mateix, no escrita al costat. A l'ecosistema Protocore, les comandes de pagament per transferència de Gateway porten referències de vIBAN, i Center treballa les excepcions que la conciliació deixa enrere. La pàgina de producte a /products/viban recorre tot el cicle —emetre, compartir, conciliar, gestionar excepcions, informar— amb les mateixes dades de demo que fem servir aquí.

I un límit honest: si rebeu un grapat de transferències al mes, una convenció de referències i deu minuts de comptabilitat són suficients. Els IBAN virtuals es guanyen el lloc quan el volum ha convertit la conciliació en un procés: rendes de lloguer, cobraments de subscripcions, marketplaces; allà on la pregunta de qui us ha pagat es fa milers de vegades al mes.