TARVIX
Pénzügy · Éles rendszer

Banki utalás-előkészítés automatizálása — szándékosan mesterséges intelligencia nélkül

Csütörtök, fél nyolc. Valaki belép a vállalatirányítási rendszerbe, lekéri a nyitott szállítói számlákat, exportál, megnyit egy Excelt, kiszűri, ami még nem esedékes, összegez, ellenőriz, aztán soronként begépeli a bank vállalati terminál-formátumába: számlaszám, összeg, közlemény. Kilencre kész — ha egyetlen számjegy sem csúszott el.

Ezt a folyamatot automatizáltuk egy több márkás autókereskedés-csoportnál, szándékosan mesterséges intelligencia nélkül. A pénzmozgás láncában egyetlen AI-lépés sincs: minden lépés determinisztikus, tesztelt kód, a végén kihagyhatatlan emberi jóváhagyással. Ebben a cikkben leírjuk, hogyan működik élesben, hol van mégis helye az AI-nak a pénzügyi folyamatban — és mikor nem éri meg megépíttetni.

Hogyan néz ki egy nap az automata utalási tervvel?

Röviden: a rendszer reggel összeállítja a napi utalási tervet, e-mailben kiküldi jóváhagyásra, és kizárólag a visszaérkezett, jóváhagyott tervből készíti el a banki importfájlt. Emberi jóváhagyás nélkül egyetlen sor sem kerül fájlba.

A folyamat egy 20+ éves, zárt vállalatirányítási rendszer fölött fut, csak-olvasó rétegen keresztül. Öt lépés:

  1. Lekérdezés. A rendszer kiolvassa a nyitott szállítói számlákat a vállalatirányítási rendszerből. Csak olvas — nem ír bele semmit.
  2. Terv-összeállítás. Lejárat, partner, összeg, számlaszám, közlemény: a napi utalási terv soronként összeáll.
  3. Kiküldés. A terv Excel-mellékletként, e-mailben megy a pénzügyes kollégának.
  4. Jóváhagyás. Egyetlen oszlop van, amibe írni kell: a kolléga X-eli azt, amit nem kell utalni. Nem a fizetendőt jelöli meg, hanem a kivételt.
  5. Importfájl. A visszaküldött tervből a rendszer bájtpontos fájlt állít elő a bank vállalati terminál-formátumában, betöltésre készen.

A negyedik lépés az egész rendszer lelke. Az alapértelmezés az, hogy a lejárt szállítói számla fizetendő — a kolléga dolga nem az, hogy mindent kipipáljon, hanem hogy a kivételeket kivegye. Ez másodpercek alatt megvan, és pontosan azt a tudást használja, ami csak emberben van: hogy ezzel a beszállítóval most vitás tétel van, azt a szállítmányt pedig még nem vették át.

Voltak teljesen beavatkozás-mentes napok is: a terv jó volt, egyetlen X sem került bele. De a jóváhagyás akkor is ott volt — csak nem kellett módosítani rajta. A kapu nem attól kapu, hogy sokszor megállít, hanem attól, hogy meg tudja állítani.

A pénzügy másik oldala, a kimenő számlák lejárat-figyelése ugyanezen az elven fut: gépi figyelés, emberi döntés. Erről a fizetési felszólításról szóló cikkünkben írtunk részletesen.

Miért nincs AI a pénzmozgás láncában?

Mert az AI valószínűségi, az utalás pedig nem az. Egy nyelvi modell ugyanarra a bemenetre nem garantáltan adja ugyanazt a kimenetet — egy determinisztikus kód igen: ma is, fél év múlva is, az ezredik futásnál is.

A tévedés ára a lánc két végén nem ugyanaz. Ha egy AI a beérkező számla adatánál félreolvas egy karaktert, azt egy beépített ellenőrzés elkapja, és a számla emberi sorba kerül: elveszett fél perc. Ha az utalási fájlban csúszik el egy számjegy, akkor a pénz elment — és nem a rendszer szerzi vissza, hanem Ön.

Ezért a pénzmozgás láncában minden lépés kód: lekérdezés, szűrés, összegzés, formátum-előállítás. Kód, amit le lehet tesztelni, és amit le is teszteltünk — a rendszereink mögött összesen 5 000+ automata teszt fut. Egy nyelvi modell kimenetére ilyen teszt nem írható értelmesen: nincs mit zöldre futtatni, ha az eredmény futásonként változhat.

A bájtpontosság sem szólam. A bank vállalati terminál-formátuma kötött mezőhosszakkal, kötött karakterkészlettel és kötött sorrenddel dolgozik. Egy rossz helyen álló szóköznél a jobbik eset az, hogy a terminál visszautasítja a fájlt. A rosszabb az, ha elfogadja.

Ez nem AI-ellenesség, hanem munkamegosztás: az AI ott jó, ahol rendetlen, ember-formátumú bemenetet kell értelmezni; a kód ott, ahol a pontosság nem alku tárgya.

A négy fék, ami nélkül el sem indul egy utalási terv

Négy dolog van beépítve, ami megállítja a folyamatot, ha valami nem stimmel. Egyik sem kapcsolható ki „csak most az egyszer”.

1. Emberi jóváhagyó kapu, ami nem kihagyható

Importfájl kizárólag jóváhagyott tervből készül. Nincs időzítő, ami válasz híján magától továbbenged, és nincs olyan szabály, hogy kis összeg alatt automatikusan megy. Ha a jóváhagyás nem érkezik meg, aznap nincs fájl. Ez nem hiba, hanem a tervezett viselkedés.

2. Duplautalás-őr

Ugyanaz a számla kétszer nem kerülhet tervbe. A rendszer nyilvántartja, melyik számla melyik napi tervben ment ki, és ha ugyanaz a tétel újra felbukkanna — mert a forrásrendszerben változott egy státusz, vagy mert kétszer futott le a lekérdezés —, akkor kiesik. Ez nem sárga figyelmeztetés a lista alján, hanem tiltás.

3. Számlaszám-ellenőrzés hibaészleléssel

A rendszer minden sornál megvizsgálja a számlaszám szerkezetét, és lefuttatja a benne lévő hibaészlelést — az elgépelt és a felcserélt számjegyek nagy része már a fájl előállítása előtt kibukik. Ami nem megy át, az kimarad a tervből, és emberi sorba kerül. Automatikus javítás nincs: a gép nem „találja ki” a hiányzó számjegyet.

4. Ünnepnap- és banki szünnap-naptár

Az utalási terv nem generálódik olyan napra, amit a naptár nem munkanapként ismer. Az áthelyezett munkanapok és a hosszú hétvégék karbantartott listából jönnek — nem abból, hogy a kód megnézi, hétvége van-e.

Ez első hallásra fölösleges óvatosság. 2026. szeptemberi állapot szerint a Magyar Nemzeti Bank tájékoztatója alapján a 20 millió forint alatti elektronikus belföldi átutalások az év minden napján, 5 másodperc alatt teljesülnek. Csakhogy a szűk keresztmetszet nem a teljesítés sebessége, hanem a jóváhagyás: az ember munkanapon ül a gép előtt. Egy ünnepnap reggelén kiküldött terv nem gyorsabb utalás, hanem egy e-mail, amire senki nem válaszol.

Minden lépésről napló készül: mikor mi ment ki, mikor és milyen tartalommal érkezett vissza a jóváhagyás, milyen fájl állt elő. Ha utólag kérdés van, nem emlékezetből kell válaszolni.

Hol van mégis helye az AI-nak a pénzügyi folyamatban?

Van helye — de a lánc elején, nem a végén. Ott, ahol rendetlen, ember-formátumú bemenetből kell adatot csinálni: a bejövő szállítói számla adatának kinyerésénél.

Egy szkennelt vagy PDF-ben érkező számla minden beszállítónál más elrendezésű. Erre a szabály-alapú kód rossz eszköz: minden új elrendezéshez új szabály kellene. Egy vision-modell viszont mezőnként kiolvassa, mi micsoda — partner, számlaszám, dátumok, nettó, ÁFA, bruttó.

Ott is van azonban egy kőkemény feltétel: a kiolvasott adat nem mehet tovább kódban lefutó, kötelező számtani ellenőrzés nélkül. Nettó + ÁFA = bruttó, a tételek összege = a végösszeg. Ami nem stimmel, az nem javul meg magától, hanem emberhez kerül. Ez a rendszer 470+ számlán fut élesben; a részletek a bejövő számlák automatikus feldolgozásáról szóló cikkünkben vannak.

A határvonal tehát egyszerű: az AI olvas, a kód ellenőriz, az ember dönt — a pénzt pedig determinisztikus kód mozgatja. Lépésenként így néz ki:

Folyamat-lépésAutomatizálható?AI vagy determinisztikus kód?Kell emberi kapu?
Bejövő számla adatának kinyerése (PDF, szkennelt papír)IgenAI-kinyerés + kötelező kódos számtani ellenőrzésCsak a kivételeknél
Számla iktatása, archiválása, kereshetővé tételeIgenDeterminisztikus kódNem
Lejáró szállítói számlák kiválasztása, utalási terv összeállításaIgenDeterminisztikus kódNem — a terv még nem pénz
Számlaszám- és formátum-ellenőrzésIgenDeterminisztikus kódCsak a kiesett soroknál
Döntés: mit fizetünk ki és mit nemNemEgyik sem — emberi mérlegelésIgen, ez maga a kapu
Banki importfájl előállítása a jóváhagyott tervbőlIgenDeterminisztikus kód, bájtpontos formátumNem, már túl van a kapun
A fájl betöltése és az utalás elindítása a bankbanNem automatizáljukEgyik semIgen, banki felhatalmazással

A táblázatból két sor lóg ki: a kifizetési döntés és maga a banki indítás. Egyik sem azért marad emberi kézben, mert technikailag nem menne — hanem mert nem szabad gépre bízni.

Meg lehet ezt csinálni saját kézzel?

Részben igen — és őszintén: a folyamat egy részét érdemes is saját kézbe venni. Ami reálisan összerakható házon belül, az a lekérdezés–Excel–e-mail szakasz.

Ha a vállalatirányítási rendszerből ki tud exportálni egy nyitott szállítói számla listát, akkor egy rendesen megírt Excel-sablon és egy ütemezett e-mail már megszünteti a napi másolgatás nagy részét. Ez lényegében az Excel-automatizálás középső szintje, és nem kell hozzá fejlesztő. Ha van a cégben technikai affinitású kolléga, az n8n-nel a kiküldés és a válasz visszaolvasása is összekattintható.

Négy dolog az, ami házilag rendszerint nem készül el — és éppen ez a négy dolog az, amiért egy pénzügyi automatizálásért fizetni érdemes:

  • A bájtpontos banki formátum. Nem az a nehéz, hogy a fájl elkészüljön, hanem hogy minden esetben pontosan úgy készüljön el, ahogy a terminál várja: hosszú partnernévnél, ékezetnél, kerekítésnél, jóváírásnál is.
  • Az állapotkezelés. Mi ment ki, mi jött vissza, mi került már fájlba. A duplautalás-őr enélkül nem létezik — egy Excel-sablon nem tudja, mit küldött ki tegnap.
  • A tesztelés. Nem az a kérdés, hogy jó napon működik-e, hanem hogy mi történik, ha a lekérdezés kétszer fut le, ha üres a lista, vagy ha a jóváhagyó melléklet sérülten jön vissza.
  • A felelősség. Ha a házilag összerakott megoldás hibás fájlt gyárt, azt annak a kollégának kell reggel hétkor javítania, aki összerakta — a saját munkája mellett.

Ez nem azt jelenti, hogy a saját kezű út rossz. Azt jelenti, hogy a terv-előállításig jó, az utalási fájlig már nem.

Mikor nem éri meg, és kinek nem való?

Nem minden cégnek való. Négy helyzet, amikor mi magunk beszéljük le róla:

  • Havi 10–20 utalás alatt. Ennyit gyorsabb kézzel begépelni, mint rendszert bevezetni rá. Az automatizálás az ismétlődésből él, nem a bonyolultságból.
  • Ha a szállítói számlák nincsenek egy helyen. Ha az adat egy része Excelben, más része fejben és papíron van, akkor előbb az adatot kell rendbe tenni. Rossz bemenetből a legjobb kód is rossz utalási tervet állít elő — csak gyorsabban.
  • Ha minden számlánál egyedi mérlegelés dönt. Ha nem mondható ki alapértelmezésként, hogy a lejárt számlát fizetjük, akkor a jóváhagyás nem egy X, hanem maga a munka. Ilyenkor a rendszer legfeljebb a listát adja — az sem semmi, de nem ér meg egy projektet.
  • Ha a jóváhagyó kaput ki akarja hagyni. Kapunk ilyen kérést: menjen magától, ne kelljen ránézni. Ezt nem építjük meg — nem azért, mert technikailag nem menne.

Ha viszont rendszeres utalási kör megy, a szállítói számlák egy rendszerben vannak, és a kifizetés alapértelmezése kimondható, akkor a folyamat jó eséllyel megtérülően automatizálható.

Az árakról röviden. A belépő a folyamat-audit 120 000 Ft-ért, egy hét alatt: ha nem találunk legalább öt megtérülő automatizálási lehetőséget, a díj visszajár, 60 napon belüli megrendelésnél pedig beszámít a projekt árába. A megépítés 300 000 Ft-tól indul; ha a lánc elejére a bejövő számlák feldolgozása is bekerül, az már dokumentum-feldolgozás: 500 000 Ft-tól. Az üzemeltetés — felügyelet, hibariasztás, havi 2 óra fejlesztési keret, havi összefoglaló — 30 000 Ft/hó-tól kérhető. Óradíjjal nem dolgozunk, és az első működő automatizálás 2 héten belül elindul. Az audit menetéről tételesen az AI-audit árairól szóló cikkünkben írtunk.

Gyakori kérdések

Mennyibe kerül egy banki utalás-előkészítő automatizálás?

A belépő a folyamat-audit 120 000 Ft fix áron, egy hét alatt. A megépítés 300 000 Ft-tól indul; ha a bejövő számlák feldolgozása is a rendszer része, az dokumentum-feldolgozás, 500 000 Ft-tól. Az üzemeltetés 30 000 Ft/hó-tól kérhető. Óradíjjal nem dolgozunk, az ár a specifikáció után fix.

Utal-e a rendszer magától, ember nélkül?

Nem. A rendszer utalási tervet készít és banki importfájlt állít elő, de a fájl betöltése és az utalás elindítása mindig emberi kézben marad, banki felhatalmazással. Importfájl is csak jóváhagyott tervből készül: ha a pénzügyes kolléga nem küldi vissza a mellékletet, aznap nincs fájl.

Biztonságos-e a banki utalást automatizálni?

A pénzmozgás láncában nálunk nincs AI: minden lépés determinisztikus, tesztelt kód, ugyanarra a bemenetre mindig ugyanazzal a kimenettel. Ehhez jön a kihagyhatatlan emberi jóváhagyás, a duplautalás-őr, a számlaszám-ellenőrzés és a teljes naplózás. A forrásrendszerbe a rendszer nem ír, csak olvas.

Mi történik, ha ugyanaz a számla kétszer kerülne be a tervbe?

Nem kerülhet be. A rendszer nyilvántartja, melyik számla melyik napi tervben ment ki, és a már felhasznált tételt kiszűri, akkor is, ha a lekérdezés kétszer fut le vagy a forrásrendszerben megváltozik egy státusz. Ez tiltás, nem figyelmeztetés: a kizárt sor nem kerül be a fájlba.

Kötelező-e az emberi jóváhagyás, vagy kikapcsolható?

Nálunk kötelező, és nem kapcsolható ki. Nincs időzítő, ami válasz híján továbbenged, és nincs értékhatár, ami alatt automatikusan menne. Kapunk olyan kérést, hogy a jóváhagyás maradjon el, de ezt nem építjük meg: az emberi kapu az, ami a rendszert egy hibás nap után is megállíthatóvá teszi.

Milyen bankkal és milyen rendszerrel működik?

A kimenet a bank vállalati terminál-formátuma, amit az adott banknál használnak, bájtpontosan előállítva. A bemeneti oldalon a meglévő vállalatirányítási rendszerre építünk, csak-olvasó rétegen keresztül. Egy 20+ éves, zárt rendszernél is működik: eddig 2 034 ERP-táblát térképeztünk fel ehhez a megközelítéshez.

A következő lépés

Ha az utalás-előkészítés Önöknél is napi félóra másolgatás, kezdje azzal, hogy megnézi, mit ér ez egy évben: a megtakarítás-kalkulátorban a saját darabszámaival számolhat. Ha a szám meggyőző, a következő lépés a folyamat-audit — abból derül ki, hogy az utalás-előkészítés egyáltalán a legjobb belépőpont-e, vagy van a cégben nála is drágább kézi kör. Egy 30 perces beszélgetésen ez általában eldől.

Kezdje itt

Nézzük meg, hol áll most az utalás-előkészítése

Egy 30 perces beszélgetésen kiderül, hogy a folyamat automatizálható-e megtérülően, és hogy melyik lépés hoz a legtöbbet. Ha nem éri meg, azt is megmondjuk.

Olvasson tovább

Kapcsolódó cikkek

Ingyenes 30 perces konzultáció