Számlafeldolgozás automatizálása: ellenőrizhető folyamat az érkezéstől a könyvelésig
E-számla, PDF vagy e-mail: így építs adatkinyeréssel, validálással, jóváhagyással és naplózott kivételkezeléssel működő számlafolyamatot.
RÖVIDEN A LÉNYEG
A számlafeldolgozás automatizálása nem egy PDF-ből kinyert összeg könyvelését jelenti. A megbízható folyamat azonosítja a bemenetet, ellenőrzi a kötelező és üzleti mezőket, felismeri az ismételt számlát, jóváhagyási vagy kivételsorba irányít, majd csak ellenőrzött adatot ad tovább. Az alábbi folyamat szemléltető minta, nem ügyfélprojekt és nem igazolt eredmény.
- Az elektronikus számla, a PDF és az e-mail nem azonos minőségű bemenet.
- A duplikációt tartós azonosítóval és idempotens továbbítással kell kezelni.
- A bizonytalan vagy szabálytalan eset emberi döntési és naplózott kivételsorba kerül.
Három bemenet, három eltérő bizonyosság
A strukturált e-számla mezői géppel olvasható formában érkeznek, ezért az adat és a jelentése együtt kezelhető. A PDF lehet szöveges vagy képként mentett dokumentum; előbb el kell dönteni, van-e benne megbízható szövegréteg, vagy karakterfelismerés szükséges. Az e-mail törzse és csatolmányai külön bemenetek: az üzenetből érkező megjegyzés nem írhatja felül a számlaadatot vagy a rendszer szabályait.
Minden beérkezés kapjon saját fogadási azonosítót, időbélyeget, forráscsatornát és az eredeti fájlhoz tartozó ellenőrző lenyomatot. A minta folyamatban a dokumentum először elkülönített fogadási területre kerül; csak a típus, a kártevő-ellenőrzés és az engedélyezett formátum vizsgálata után indul adatkinyerés. Így egy hibás csatolmány nem jelenik meg sikeresen feldolgozott számlaként.
Adatkinyerés után üzleti validálás következik
A kinyert adat még nem jóváhagyott adat. Ellenőrizni kell többek között a számla azonosítóját, kiállítóját, vevőjét, kiállítási és teljesítési dátumát, pénznemét, nettó és adóösszegeit, végösszegét, valamint a fizetési hivatkozást, ha a folyamat használja. A Peppol BIS Billing specifikáció jó példa arra, hogyan kapcsolódnak üzleti szabályok a strukturált számlamezőkhöz; a saját kötelező mezőket azonban a tényleges jogi, számviteli és működési környezethez kell igazítani.
A formai ellenőrzés mellett üzleti szabály is kell: ismert-e a szállító, egyezik-e a pénznem a megrendeléssel, számolhatók-e újra a részösszegek, van-e szükséges költséghely vagy projektazonosító, és megengedett-e az eltérés. A rendszer minden mezőhöz őrizze meg a forrást és a validálási eredményt. Ha OCR vagy AI javasolt értéket, annak bizonytalansága és az eredeti dokumentumrészlet is legyen látható az ellenőrzőnek.
A duplikáció és az újrapróbálás külön probléma
Ugyanaz a számla megérkezhet e-mailben, feltöltésből és újraküldésként is. Az e-mail üzenetazonosítója vagy a fájlnév önmagában nem elég. A duplikációs kulcs több ellenőrzött adatból állhat, például a kibocsátó azonosítójából, a számlaszámból, a kiállítás dátumából, a pénznemből és a végösszegből. A dokumentum lenyomata további jel, de egy technikailag újragenerált PDF ugyanazt az üzleti számlát eltérő bájtokkal tartalmazhatja.
A könyvelő- vagy számlázórendszer felé küldött művelet kapjon idempotenciakulcsot és tartós állapotot. Időtúllépés után a rendszer előbb kérdezze le, létrejött-e már a tétel, és csak bizonyítottan biztonságos műveletet próbáljon újra. Az „ismeretlen” állapot ne váljon automatikusan „sikertelen”-né: kerüljön ellenőrzésre, különben ugyanaz a számla többször is továbbmehet.
A jóváhagyás és a kivételsor a folyamat része
A jóváhagyási szabály rögzítse, ki dönthet, milyen összeg-, beszállító-, költséghely- vagy eltérési feltételnél kell további ellenőrzés, és mi történik helyettesítéskor. A jóváhagyó az eredeti dokumentumot, a kinyert mezőket, az ellenőrzések eredményét és a korábbi döntéseket ugyanazon ügyben lássa. Az AI vagy OCR javaslata ne rejtse el a bizonytalanságot, és ne kapjon önálló jogosultságot pénzügyi következményű művelethez.
A kivételsorban ne csak hibakód legyen. Tartalmazza a megállás okát, a felelőst, a következő lehetséges lépést, a határidőt és a javítás után újrafuttatandó ellenőrzéseket. Tipikus minta lehet a hiányzó rendelési hivatkozás, az eltérő összeg, az ismeretlen szállító, az olvashatatlan mező vagy a feltételezett duplikáció. A javított adatnál látszódjon, ki, mikor és milyen forrás alapján változtatott.
Az integráció csak ellenőrzött állapotot adjon tovább
Előre rögzítsd, melyik rendszer a hiteles forrás a beszállítóhoz, a rendeléshez, a jóváhagyáshoz és a könyvelési státuszhoz. A mezőtérkép írja le a típusokat, pénznemeket, adókódokat, költséghelyeket, tartós azonosítókat és az üres értékek kezelését. A célrendszer válasza ne pusztán technikai 200-as státusz legyen: tartalmazzon olyan azonosítót és állapotot, amellyel az ügy később visszakereshető.
A kapcsolatkimaradást, a részleges választ és a késve érkező státuszt is teszteld. A könyvelő vagy számlázó felületén létrejött tétel azonosítója kerüljön vissza a folyamatnaplóba. Ha a célrendszerben ember módosítja vagy elutasítja a tételt, annak visszajelzése is rendezett útvonalon érkezzen, ne külön e-mailben maradjon. Az integrációs szerződés, a verziózás és a hibakezelés részletesebb tervezéséhez külön rendszerintegrációs útmutató kapcsolódik ehhez a mintához.
Adatvédelem, megőrzés és audit trail együtt tervezendő
A számla személyes és üzleti adatot is tartalmazhat. Rögzítsd a feldolgozás célját és jogalapját, a hozzáférési szerepköröket, a tárolási helyeket, a megőrzési és törlési szabályt, valamint a szolgáltatókat, amelyeken az adat áthalad. A GDPR célhoz kötöttségi, adatminimalizálási és korlátozott tárolási elvei miatt ne kerüljön teljes dokumentumtartalom olyan naplóba vagy analitikai rendszerbe, ahol nincs rá meghatározott szükség. A konkrét megőrzési időt a vonatkozó jogi és számviteli kötelezettségek alapján kell meghatározni.
Az audit trail külön kezelje a fogadást, a kinyerést, a validálást, a kézi módosítást, a jóváhagyást, az integrációs kérést, a választ és a lezárást. Minden eseményhez tartozzon idő, ügyazonosító, szereplő vagy rendszer, művelet, előző és új állapot, de a napló csak a vizsgálathoz szükséges adatot tartalmazza. A NIST naplókezelési útmutatója is a naplózás teljes életciklusát és felelősségeit hangsúlyozza; a napló önmagában nem érték, ha nem védett, nem visszakereshető vagy senki nem vizsgálja.
A mérési terv a teljes ügyutat vizsgálja
Fejlesztés előtt rögzíts összehasonlítható kiinduló állapotot: beérkező számlák típusát és mennyiségét, kézi ráfordítást, várakozást, javítást, duplikációt és a lezárás módját. A próba mérheti a végig automatikusan validált ügyek arányát, az emberi ellenőrzés idejét, a kivétel okait, az integrációs újrapróbálást és az átfutást. A gyorsabb feldolgozás önmagában nem siker, ha több utólagos korrekció vagy ellenőrizetlen tétel keletkezik.
A tesztkészletben legyen strukturált e-számla, szöveges és szkennelt PDF, hiányos mező, eltérő összeg, ismételt beküldés, ismeretlen szállító, kapcsolatkimaradás és jóváhagyói visszautasítás. Minden elvárt eredményhez legyen elfogadási feltétel és felelős. Ez szemléltető mérési terv: nem Kriside-ügyféladat, és nem ígér előre pontosságot, időnyereséget vagy pénzügyi eredményt.
Kapcsolódó megvalósítási területek
A számlafolyamat szabályalapú automatizációt, dokumentumértelmezést és ellenőrzött rendszerkapcsolatot is igényelhet. A technológiát mindig a tényleges bemenet és kockázat alapján válaszd.
Üzleti automatizáció
Ami ismétlődik, fusson kiszámíthatóan. Adatmásolás, státuszváltás, utánkövetés és értesítés átlátható szabályok mentén.
02AI-integráció meglévő üzleti rendszerekbe
Az AI-integráció egy körülhatárolt értelmezési feladatot kapcsol a meglévő rendszerhez, ellenőrzött adatúttal és emberi döntési ponttal.
03API- és rendszerintegrációk
A rendszereid beszéljenek egymással. Összekötjük az űrlapokat, CRM-et, számlázást és belső eszközöket, követhető adatmozgással.
Kapcsolódó döntési útmutatók
AI-automatizáció vagy szabályalapú automatizálás?
Mikor kell AI, mikor elég egy szabály, és mikor indokolt saját munkafelület? Öt kérdés a megfelelő megoldás kiválasztásához.
Borbély KristófRendszerintegráció tervezése: mit tisztázz az API-fejlesztés előtt?
Az API csak a kapcsolat technikai része. A működő integrációhoz adatgazda, egyértelmű azonosítók, hibakezelés, jogosultság és felügyelet is kell.
Borbély KristófForrások és további olvasnivaló
- Peppol BIS Billing 3.0OpenPeppol · Ellenőrizve: 2026-10-31
- Directive 2014/55/EU on electronic invoicing in public procurementEuropean Union · Ellenőrizve: 2026-10-31
- General Data Protection Regulation, Article 5European Union · Ellenőrizve: 2026-10-31
- Guide to Computer Security Log ManagementNIST · Ellenőrizve: 2026-10-31
Kapcsolódó kérdések
Milyen számlabemenetek automatizálhatók?
Strukturált e-számla, szöveges vagy szkennelt PDF és e-mailes csatolmány is feldolgozható, de nem azonos bizonyossággal. Minden csatornához külön fájl-, adatkinyerési és validálási szabály kell; az OCR vagy AI által javasolt mező addig nem jóváhagyott adat, amíg a szükséges ellenőrzés meg nem történt.
Mikor kell emberi ellenőrzés az automatikus számlafeldolgozásban?
Emberi döntés kell legalább akkor, ha kötelező mező hiányzik, az összeg vagy pénznem eltér a megrendeléstől, a szállító ismeretlen, a dokumentum bizonytalanul olvasható, duplikáció gyanúja áll fenn, vagy a művelet pénzügyi jóváhagyást igényel. A kivételsornak az okot, a felelőst, a következő lépést és a döntés naplóját is mutatnia kell.
Borbély Kristóf
A Kriside mögött álló fejlesztő. Gyakorlati útmutatókat ír webes rendszerekről, automatizációról és AI-megoldásokról.