Kas ir virtuālais IBAN?

Virtuālais IBAN (vIBAN) ir īsts, adresējams starptautiskais bankas konta numurs, kas izsniegts no atvēlēta diapazona un novirzīts uz vienu galveno kontu. Tas pieņem maksājumus kā jebkurš cits IBAN — maksātājs no savas bankas nosūta parastu SEPA kredīta pārskaitījumu —, taču tam nav sava atlikuma. Tā uzdevums ir identifikācija: tā kā katrs virtuālais IBAN ir piešķirts tieši vienam maksātājam vai mērķim, uz tā ienākošais maksājums jau pats pasaka, kas to nosūtījis un kam tas paredzēts. Nauda galvenajā kontā uzkrājas automātiski; virtuālais IBAN ir maksājuma etiķete, nevis otra vieta, kur nauda atrodas.

Šī vienīgā īpašība — viens IBAN katram maksātājam — ir visa ideja. Lai saprastu, kāpēc par to vērts rakstīt veselu rakstu, sāksim ar problēmu, ko tā novērš.

Īstā problēma: naudas piesaiste maksātājiem

Iedomājieties uzņēmumu, kas iekasē maksājumus ar bankas pārskaitījumu uz vienu kontu: īri, abonementus, rēķinus. Katrs maksājums nonāk uz viena IBAN, un vienīgā norāde, kas maksājis, ir tas, ko maksātājs ierakstījis atsauces laukā. Atsauces tiek ierakstītas ar kļūdām, kaut kur ķēdē apgrieztas vai atstātas pavisam tukšas. €49.00 pārskaitījums ar sagrozītu atsauci vēl nav €49.00 atzītu ieņēmumu — tas ir pieteikums. Kādam jānoskaidro, kuram klientam un kuram rēķinam tas pieder, pirms tiek slēgtas grāmatas.

Nelielos apjomos tas ir tikai kaitinoši. Platformas apjomos tā ir vesela nodaļa. Saskaņošanas dzinēji vērtē kandidātrēķinus pēc summas, datuma un aptuvenas atsauces teksta atbilstības; ko tie nespēj piesaistīt, nonāk cilvēku rindā. Un problēma ir strukturāla: ja divi abonenti vienā dienā maksā vienādu summu bez atsauces, neviens dzinējs tos nespēj atšķirt — informācija, kas ļautu tos atšķirt, maksājumā nekad nebija ietverta.

Viens IBAN katram maksātājam: identitāte jau konstrukcijā

Virtuālo IBAN programma apgriež dizainu otrādi. Tā vietā, lai prasītu katram maksātājam pareizi apzīmēt maksājumu, jūs katram maksātājam piešķirat paša adresi. Katrs īrnieks, abonents vai tirgus platformas pārdevējs maksā uz IBAN, kas pieder tikai viņam. Atsauces lauks var būt nepareizs, tukšs vai citā alfabētā — maksājums tik un tā identificē sevi, jo identitāti nes konta numurs.

Konta numurs ir daudz labāks identitātes nesējs nekā atsauce. IBAN ietver savus kontrolciparus, tāpēc nepareizi ievadīts IBAN neiztur validāciju maksātāja bankā jau pirms pārskaitījuma nosūtīšanas. Nepareizi ievadīta atsauce izslīd cauri un kļūst par jūsu problēmu. Pārceļot identitāti no brīvā teksta lauka uz adresi, kļūdu pārbaude pāriet no jūsu back office uz sūtītāja banku.

Maksātājam nekas nemainās: viņš maksā uz IBAN no sava bankas lietotnes, kā vienmēr. Viss jaunais ir saņemšanas pusē — maksājums ierodas jau apzīmēts, un atsauces lauks atkal kļūst par to, kam tam vienmēr bija jābūt: piezīmi, nevis identifikācijas sistēmu.

Kad katrs maksātājs maksā uz savu IBAN, ienākošais maksājums var nozīmēt tikai vienu. Saskaņošanas problēma netiek atrisināta — tā pārstāj pastāvēt.

Kur nauda patiesībā atrodas

Zem virsmas katrai valūtai ir tieši viens galvenais konts. Virtuālie IBAN tiek izsniegti no programmai atvēlētiem diapazoniem, un katrs maksājums, kas nosūtīts uz jebkuru no tiem, tiek ieskaitīts galvenajā kontā. Nav jāpārvalda maksātāju atlikumi un nav dienas beigu pārskaitīšanas uzdevumu, kas pārliek līdzekļus no tūkstošiem mazu kontu uz vienu — koncentrācija notiek ar maršrutēšanu, nevis ar papildu pārskaitījumiem, kas pēc tam būtu jāsaskaņo atsevišķi.

Tieši tas virtuālo IBAN padara īstu, nevis triku. Tas ir adresējams no jebkuras bankas, tiek apstrādāts kā jebkurš SEPA kredīts un maksātāja izrakstā parādās kā konts, uz kuru viņš maksājis. Tam trūkst tieši tā, ko līdzi velk pilnvērtīgs konts: paša atlikuma un dzīves cikla, kas pārsniedz piešķiršanu un izņemšanu no apgrozības.

Kas virtuālais IBAN nav

Tas nav apakškonts: apakškontam ir atlikums, tas jāpapildina un jāiztukšo, un tas pavairo virsgrāmatu skaitu, kas jums jāuztur. Tas nav virtuāls atsauces numurs: tie joprojām balstās uz atsauces lauku un joprojām ir atkarīgi no tā, vai maksātāji pareizi pārkopē rakstzīmju virknes. Un tas nav maks: pašā vIBAN nekas netiek glabāts. Tā ir adrese ar maršrutēšanu aiz tās — šaurākā konstrukcija, kas padara ienākošo maksājumu pašidentificējošu.

Atgriezumi nāk atpakaļ ar iemeslu

Maksājumi ne tikai ienāk. Konti tiek slēgti, bankas noraida ieskaitījumus, maksātāji atsauc pārskaitījumus. Pasaulē ar vienu iekasēšanas kontu atgriezums ir neliela izmeklēšana: kurš maksājums atgriezās, kam tas piederēja un vai virsgrāmatas ierakstam, ar kuru tas tika saskaņots, nepieciešama atcelšana?

vIBAN programmā atgriezums ir dati. Tam ir savs iemesla kods, tas parādās kā payment.returned notikums pie tā paša virtuālā IBAN, ko izmantoja sākotnējais maksājums, un izrakstā tiek uzskaitīts atsevišķi. Jūs zināt, kura maksājums atgriezās un kāpēc, pirms kāds atver pieteikumu. Atgriezumi kļūst par apstrādājamām rindām, nevis noslēpumiem, kas jāmeklē.

Izņēmumu rinda, nevis saskaņošanas komanda

Neviens dizains nesaskaņo simt procentu no nekā. Maksājumi ierodas uz vIBAN, kas jau izņemti no apgrozības. Gadās dublikāti. Kāds kaut kā samaksā tieši uz galveno kontu. Mērķis nav padarīt izņēmumus neiespējamus — tas ir padarīt tos retus un saskaitāmus. Protocore vIBAN demo 99.6% maksājumu tiek saskaņoti automātiski; pārējie nonāk pārskatīšanas rindā ar pievienotu maksātāja pilnu vēsturi, tāpēc darbs ar izņēmumu sākas no konteksta, nevis no bankas izraksta un izklājlapas.

Šī atšķirība pārveido komandu. Saskaņošanas operācija aug līdz ar maksājumu apjomu: vairāk maksājumu, vairāk nesaskaņotu maksājumu, vairāk cilvēku. Izņēmumu process aug līdz ar izņēmumu apjomu, ko dizains jau ir novedis tuvu nullei. Cilvēki, kurus paturat, strādā ar īstām anomālijām, nevis ar pārrakstītām atsaucēm. Mūsu risinājumā šī rinda atrodas Protocore Center (/products/center) — operāciju konsolē, kurā katrai privileģētai darbībai nepieciešams iemesls un kas nonāk audita žurnālā.

Masveida izsniegšana, mērķa birkas, platformas

Viens IBAN katram maksātājam darbojas tikai tad, ja tā izsniegšana neko nemaksā. Saimnieks ar divpadsmit īrniekiem vIBAN var izveidot ar roku; tirgus platforma, kas piesaista tūkstošiem pārdevēju, nevar. Tāpēc izsniegšana ir masveida darbība. vIBAN demo 2,400 maksātāju CSV fails tiek validēts, katrā rindā parāda IBAN priekšskatījumu un tiek izsniegts vienā darbībā — 2,400 maksātāji, viena operācija, pa vidu pārskatīšanas solis.

Mērķa birkas notur plūsmas atsevišķi adreses līmenī: īre šeit, abonementi tur, tirgus platformas izmaksas savā joslā. Atskaites pēc mērķa kļūst par filtru, nevis projektu, un katrs vIBAN saņem savu izrakstu — CSV vai PDF —, kamēr galvenais konts zem tā paliek vienīgais patiesības avots. Kad maksātājs aiziet, viņa vIBAN tiek izņemts no apgrozības: vēsture paliek, adrese vairs nepieņem jaunus maksājumus.

Kur tas iederas maksājumu risinājumā

Virtuālie IBAN ir iekasēšanas infrastruktūra. Tie ienākošajiem bankas pārskaitījumiem dod to, kas karšu maksājumiem vienmēr ir bijis — identitāti, kas pievienota pašam maksājumam, nevis ierakstīta līdzās tam. Protocore ekosistēmā Gateway pasūtījumi ar apmaksu pārskaitījumu nes vIBAN atsauces, un Center apstrādā visus izņēmumus, ko saskaņošana atstāj. Produkta lapa /products/viban izstaigā visu ciklu — izsniegt, nodot, saskaņot, izņēmumi, atskaites — ar tiem pašiem demo datiem, kas izmantoti šeit.

Un godīga robeža: ja mēnesī saņemat dažus pārskaitījumus, pietiek ar atsauces konvenciju un desmit minūtēm grāmatvedības. Virtuālie IBAN attaisno sevi tur, kur apjoms saskaņošanu pārvērtis procesā — īres reģistros, abonementu iekasēšanā, tirgus platformās — visur, kur jautājums „kas jums samaksāja” tiek uzdots tūkstošiem reižu mēnesī.