Rövid válasz: a számlafeldolgozásban általában mindkettő kell, csak nem ugyanarra a lépésre. Az RPA a kiszámítható, szabályalapú lépéseket viszi: a számlák begyűjtését, a rögzítést az ERP-ben, az egyeztetést ott, ahol a szabály pontosan leírható. Az AI ott dolgozik, ahol a bemenet változó: az adatkinyerésnél, mert minden szállító máshogy formázza a számláit. Az éles rendszerek a kettőt kombinálják.

Egy fuvarozó ügyfelünknél így lett a havi kb. 2000 beszállítói számla feldolgozásából 3 nap helyett 4 óra: a számlák 85%-a emberi beavatkozás nélkül fut át, a feldolgozási idő 73%-kal rövidebb. A rendszerben RPA is dolgozik és AI is — mindkettő azon a szakaszon, ahol erősebb a másiknál.

Mit csinál jól az RPA a számlafeldolgozásban?

Az RPA a determinisztikus lépéseket viszi — azokat, ahol a helyes eredmény minden futásnál ugyanaz:

  • Begyűjtés. A számla letöltése az e-mail fiókból vagy a szállítói portálról, a melléklet leválasztása, a sorba állítás.
  • Rögzítés. A jóváhagyott adatok bevitele az ERP-be, a státusz átállítása, az értesítés kiküldése.
  • Egyeztetés pontos szabály mentén. Ha a számlán szereplő megrendelésszám megegyezik a nyilvántartással, és az összeg tűréshatáron belül van, a számla mehet tovább.

Ha egy lépésre pontos folyamatábrát tudsz rajzolni, oda RPA való — vagy még inkább egy sima API-integráció, ha a célrendszer ad rá felületet. Nyelvi modell ehhez nem kell, és nem is érdemes: drágább és kevésbé kiszámítható lenne.

Hol kell AI a folyamatban?

Ott, ahol a bemenet strukturálatlan. A beérkező számláknál ez elsősorban az adatkinyerés: tételsorok, összegek, pénznemek, dátumok kiolvasása olyan dokumentumokból, amiket minden szállító máshogy épít fel. A fuvarozó ügyfelünknél a számlák több pénznemben, szállítónként eltérő elrendezésben érkeznek — ezt szabályokkal nem lehet lefedni.

A második AI-terület az egyeztetés nehezebb fele. A megrendelésen „raklapos szállítás, BUD–HAM” szerepel, a számlán „Transport HU-DE, raklapos áru”. Embernek ugyanaz a tétel; pontos szöveg-összehasonlításnak nem. Ehhez mérlegelés kell, és a mérlegelés a modell terepe.

Hogy az adatkinyeréshez mikor elég a hagyományos OCR, és mikor kell mögé modell, azt külön cikkben szedtük össze: OCR vagy AI a dokumentumfeldolgozáshoz?

Hol bukik el a csak-RPA megoldás?

A tisztán RPA-alapú számlafeldolgozás jellemzően sablonokkal nyeri ki az adatokat: szállítónként megmondod, hol az összeg, hol a dátum. Ez működik a legnagyobb szállítókra. Aztán az egyik átáll új számlázóprogramra, és a sablon csendben rossz mezőt olvas — vagy megáll a bot, és nő a sor.

A hibamód kétféle, és mindkettő kellemetlen. A hangos hiba: a bot elakad minden számlán, ami eltér a sablontól, a kivételek visszakerülnek kézi feldolgozásra, a megtakarítás elolvad. A csendes hiba a rosszabb: a rossz mezőből kiolvasott összeg bekerül az ERP-be, és a könyvelés hetekkel később veszi észre.

Ehhez jön a karbantartási teher: minden új szállító új sablon, minden formátumváltás javítás. Sok szállítós, változó számlaképű környezetben a csak-RPA megoldás nem skálázódik.

Hol hibázik a csak-AI megoldás?

Az AI hibamódja más: nem elakad, hanem magabiztosan téved. A modell felcseréli a nettót a bruttóval, rossz sort olvas, vagy a hiányzó mezőre ad egy hihetőnek tűnő értéket. Kontroll nélkül ez pontosan olyan adatot enged az ERP-be, amilyet a csendben elromlott sablon.

Ezért a determinisztikus ellenőrzéseket éles rendszerben soha nem bízzuk modellre:

  • Számtani ellenőrzés. Nettó + ÁFA = bruttó, a tételsorok összege = végösszeg. Ez szabály; mérlegelésnek nincs helye.
  • Duplikátumszűrés. Ugyanaz a számlaszám ugyanattól a szállítótól másodszor nem mehet be.
  • Rögzítés. A modell javaslatot ad; az ERP-be írás szabályozott, visszakövethető lépés.

A másik szempont a költség: minden dokumentum egy modellhívás. Ahol egy pontos szabály is elég, ott a modell futtatása felesleges kiadás.

Hogyan épül fel egy éles hibrid rendszer?

A fuvarozó ügyfelünknél futó rendszer lépései:

  • Beérkezés — a számlák begyűjtése e-mailből és portálokról. Szabályalapú.
  • Adatkinyerés — szkennelt számlánál OCR-előfeldolgozás, utána a modell nyeri ki a tételsorokat, összegeket, pénznemeket. AI.
  • Ellenőrzés — számtani és formai szabályok, duplikátumszűrés. Szabályalapú.
  • Egyeztetés a megrendeléssel — pontos szabály, ahol az azonosítók egyeznek; modell, ahol az elnevezések eltérnek. Vegyes.
  • Kivételkezelés — az eltérést a rendszer megjelöli, és a problémás mezőket kiemelve továbbítja a kollégának. A döntés nála marad.
  • Rögzítés az ERP-ben — jóváhagyás után szabályozott írás. Erről részletesen: AI számlafeldolgozás és ERP-integráció.

Az eredmény: a havi kb. 2000 számla 85%-a emberi beavatkozás nélkül fut végig, a maradék előkészítve kerül emberhez. A feldolgozás 3 napról 4 órára csökkent.

Az RPA vs. AI kérdést iparágtól függetlenül, tágabban itt jártuk körbe: RPA vs. AI: valószínűleg mindkettő kell, de nem oda, ahová gondolnád

Hogyan derül ki, nálatok mi a jó felállás?

Felméréssel, a saját számláitokon. Az AI felmérés 500 000 Ft + ÁFA-tól készül: megmutatja, a folyamatod melyik lépése szabályalapú, hol kell modell, és mit hoz az automatizálás a ti számaitokkal. Ha nincs megtérülő use case, azt is megmondjuk.

Utána pilot valós számlákon: 2-3 hét alatt kiderül, mit tud a rendszer a ti dokumentumaitokon. A bevezetés a legtöbb projektnél 6-12 hét. Egy dokumentumfeldolgozó rendszer jellemzően 12–32 millió Ft; 46+ lezárt projektünk alapján a tipikus megtérülési idő 6-12 hónap. A részletek az AI-alapú számlafeldolgozás oldalon.

Elmondod, havonta hány számla érkezik és mennyi időt visz el — mi megmondjuk, melyik lépést érdemes gépre bízni, és melyikre milyen gép való.