Mi az a virtuális IBAN?

A virtuális IBAN (vIBAN) valódi, címezhető nemzetközi bankszámlaszám, amelyet külön számtartományból bocsátanak ki, és egyetlen főszámlára irányítanak. Úgy fogad fizetést, mint bármely más IBAN: a fizető fél a saját bankjából egy szokásos SEPA-átutalást indít rá, de saját egyenlege nincs. A feladata az azonosítás: mivel minden virtuális IBAN pontosan egy fizető félhez vagy célhoz tartozik, a rá érkező fizetésből már látszik, ki küldte, és mire szól. A pénz automatikusan a főszámlán gyűlik össze; a virtuális IBAN a fizetés címkéje, nem egy második hely, ahol a pénz tárolódik.

Ez az egyetlen tulajdonság, a fizetőnként egy IBAN, az egész ötlet lényege. Hogy miért érdemes írni róla, azt a legjobb azzal a problémával kezdeni, amelyet megszüntet.

A valódi probléma: a pénz és a fizető fél összepárosítása

Képzeljünk el egy vállalkozást, amely banki átutalással gyűjt be pénzt egyetlen számlára: bérleti díjat, előfizetéseket, számlákat. Minden jóváírás ugyanarra az IBAN-ra érkezik, és a fizetőre egyedül az utal, amit a fizető a közlemény mezőbe beírt. A közleményeket elírják, valahol a lánc mentén megcsonkítják, vagy üresen hagyják. Egy garbled közleményű, €49.00-s átutalás még nem €49.00 elismert bevétel, hanem egy jegy. Valakinek ki kell derítenie, melyik ügyfélhez és melyik számlához tartozik, mielőtt lezárulnak a könyvek.

Alacsony forgalomnál ez bosszúság. Platformméretnél már egy egész osztály. Az egyeztető motorok összeg, dátum és hozzávetőleges közleményszöveg alapján pontozzák a lehetséges számlákat, amit pedig nem tudnak elhelyezni, az emberi sorba kerül. A hiba ráadásul szerkezeti: ha két előfizető ugyanazon a napon ugyanazt az összeget fizeti közlemény nélkül, egyetlen motor sem tudja szétválasztani őket, mert a megkülönböztetéshez szükséges információ eleve nem szerepelt a fizetésben.

Fizetőnként egy IBAN: azonosítás a felépítésből adódóan

A virtuális IBAN-program megfordítja a felépítést. Ahelyett, hogy minden fizetőtől azt kérnéd, hogy helyesen címkézze meg a fizetését, minden fizetőnek saját címet adsz. Minden bérlő, előfizető vagy marketplace-eladó olyan IBAN-ra fizet, amely kizárólag az övé. A közlemény lehet hibás, üres, vagy egy másik ábécével írt, a jóváírás akkor is azonosítja magát, mert az azonosságot a számlaszám hordozza.

A számlaszám sokkal jobb hordozó, mint a közlemény. Az IBAN saját ellenőrző számjegyeket tartalmaz, így egy elírt IBAN már a fizető bankjánál megbukik az érvényesítésen, még az átutalás elküldése előtt. Egy elírt közlemény viszont észrevétlenül átmegy, és a te problémáddá válik. Ha az azonosítást a szabad szöveges mezőből a címbe helyezed át, a hibaellenőrzés a te back office-odtól a küldő bankhoz kerül.

A fizető fél számára semmi sem változik: ugyanúgy a banki appjából utal egy IBAN-ra, mint eddig. Minden újdonság a fogadó oldalon van: a fizetés előre megcímkézve érkezik, a közlemény mező pedig újra az lehet, aminek mindig is lennie kellett: üzenet, nem azonosítási rendszer.

Ha minden fizető a saját IBAN-jára utal, a beérkező fizetés csak egyetlen dolgot jelenthet. Az egyeztetési probléma nem megoldódik, hanem megszűnik létezni.

Hol van valójában a pénz

Alul pontosan egy főszámla van devizánként. A virtuális IBAN-okat a programnak fenntartott tartományokból bocsátják ki, és bármelyikre küldött jóváírás a főszámlán könyvelődik. Nincsenek fizetőnkénti egyenlegek, amelyeket kezelni kellene, és nincsenek napvégi gyűjtőfeladatok sem, amelyek ezernyi kis számláról terelnék át a pénzt egybe. Az összegyűjtés útválasztással történik, nem további átutalásokkal, amelyeket aztán külön-külön egyeztetni kellene.

Ettől valódi a virtuális IBAN, és nem csupán trükk. Bármelyik bankból címezhető, úgy teljesül, mint bármely SEPA-átutalás, és a fizető saját kivonatán is úgy jelenik meg, mint a számla, amelyre fizetett. Ami hiányzik belőle, az pontosan az, amit egy teljes számla magával cipel: saját egyenleg, és a kiosztáson és megszüntetésen túli életciklus.

Mi nem a virtuális IBAN

Nem alszámla: az alszámlának egyenlege van, fel- és lefinanszírozást igényel, és megsokszorozza az üzemeltetett főkönyveket. Nem virtuális hivatkozási szám: az továbbra is a közlemény mezőn utazik, és továbbra is attól függ, hogy a fizetők helyesen másolják át a karakterláncot. És nem is wallet: magán a vIBAN-on semmi sincs tárolva. Ez egy cím, mögötte útválasztással, a legszűkebb olyan megoldás, amely a beérkező fizetést önazonosítóvá teszi.

A visszaküldés az okával együtt érkezik

A fizetések nemcsak befelé mozognak. Számlák záródnak, bankok visszautasítják a jóváírást, fizetők visszahívják az átutalást. Egyetlen gyűjtőszámla esetén a visszaküldés kisebb nyomozás: melyik fizetés jött vissza, kié volt, és vissza kell-e vonni a főkönyvi tételt, amelyhez párosították?

vIBAN-programban a visszaküldés adat. Magával hozza az okkódját, payment.returned eseményként ugyanarra a virtuális IBAN-ra érkezik, mint az eredeti jóváírás, és a kivonaton saját tételt kap. Tudod, kinek a fizetése jött vissza és miért, még mielőtt bárki jegyet nyitna. A visszaküldések kezelendő sorokká válnak, nem kinyomozandó rejtélyekké.

Kivételsor, nem egyeztetőcsapat

Egyetlen felépítés sem egyeztet száz százalékot semmiből. Jóváírások érkeznek megszüntetett vIBAN-okra. Előfordulnak duplikátumok. Valaki valahogy közvetlenül a főszámlára fizet. A cél nem a kivételek lehetetlenné tétele, hanem az, hogy ritkák és megszámolhatók legyenek. A Protocore vIBAN demóban a jóváírások 99.6%-a automatikusan egyeztetődik; a maradék átnézésre vár a fizető teljes előzményével együtt, így a kivétel kezelése a kontextusból indul, nem egy bankszámlakivonatból és egy táblázatból.

Ez a különbség átalakítja a csapatot. Az egyeztetési munka a fizetési forgalommal együtt nő: több jóváírás, több párosítatlan jóváírás, több ember. A kivételkezelés a kivételek mennyiségével nő, amelyet a felépítés már nulla felé szorított. Akiket megtartasz, azok valódi anomáliákkal foglalkoznak, nem újragépelt közleményekkel. A mi stackünkben ez a sor a Protocore Centerben (/products/center) él, abban az operációs konzolban, ahol minden privilegizált művelethez indoklás kell, és bekerül az audit naplóba.

Tömeges kiadás, célcímkék, platformok

A fizetőnkénti egy IBAN csak akkor működik, ha egy kiadása semmibe sem kerül. Egy tucat bérlős bérbeadó kézzel is létrehozhat vIBAN-okat, egy több ezer eladót felvevő marketplace nem. Ezért a kiadás tömeges művelet. A vIBAN demóban egy 2,400 fizetőt tartalmazó CSV érvényesítődik, minden sorhoz előnézetben megjelenik egy IBAN, és egyetlen lépésben kiadásra kerül: 2,400 fizető, egy művelet, közben egy ellenőrzési lépés.

A célcímkék címszinten tartják szét a folyamatokat: itt a bérleti díj, ott az előfizetések, a marketplace-kifizetések pedig külön sávban. A cél szerinti riportolás szűrővé válik projekt helyett, és minden vIBAN saját kivonatot kap, CSV-ben vagy PDF-ben, miközben alatta a főszámla marad az egyetlen igazságforrás. Ha egy fizető távozik, a vIBAN-ját megszüntetik: az előzmény megmarad, a cím pedig nem fogad új jóváírást.

Hol a helye egy fizetési stackben

A virtuális IBAN-ok beszedési infrastruktúra. Azt adják a beérkező banki átutalásoknak, ami a kártyás fizetéseknek mindig is megvolt: az azonosítás magához a fizetéshez tartozik, nem mellé gépelik. A Protocore ökoszisztémában a Gateway átutalásos rendelései vIBAN-hivatkozást hordoznak, a Center pedig kezeli azokat a kivételeket, amelyeket az egyeztetés hátrahagy. A /products/viban termékoldal végigvezet a teljes körön (kiadás, megosztás, párosítás, kivétel, riport) ugyanazokon a demóadatokon, amelyeket itt is használtunk.

És egy őszinte határ: ha havonta csak maroknyi átutalást fogadsz, elég egy közleménykonvenció és tíz perc könyvelés. A virtuális IBAN-ok ott térülnek meg, ahol a forgalom az egyeztetést folyamattá tette: bérleti állományoknál, előfizetéses beszedésnél, marketplace-eknél, mindenhol, ahol a „ki fizetett?” kérdés havonta ezerszer felmerül.