Mit tud ma egy dokumentumfeldolgozó AI, és mit nem?
Kiolvassa a beérkező dokumentumot és strukturált mezőkké alakítja: számlaszám, adószám, végösszeg, dátum, tételsorok. Amit nem tud: garantálni, hogy a kiolvasott érték helyes. A látó modellek jellemző hibája, hogy formailag hibátlan, tartalmilag hamis számot adnak vissza. Ezért kell mellé validációs réteg és emberi kivételkezelés.
Ez a különbség fontosabb, mint amilyennek elsőre hangzik. A klasszikus OCR akkor hibázik, ha egy karaktert nem ismer fel, és ilyenkor krix-krax kerül a mezőbe. Látszik. A látó modell viszont egy nyugtán a 45,20 helyett odaírja, hogy 42,50: érvényes szám, érvényes formátum, semmi sem jelzi, hogy baj van. Ezt a hibamódot írja le a 2026-os OCR-áttekintő, és ez az egyetlen legerősebb érv amellett, hogy a modell önmagában nem termék.
Érdemes elhatárolni két dolgot, amit a piac gyakran összemos. A RAG rendszer keresésre és válaszadásra való: felteszel egy kérdést, és megkapod rá a választ a céges dokumentumokból. A dokumentumfeldolgozás (angolul intelligent document processing) ezzel szemben strukturált kinyerés: minden beérkező aktából ugyanazt a húsz mezőt kell kiszedni, ugyanabba a sémába, hogy az ERP be tudja fogadni. Más a metrika, más az architektúra, más a hibatűrés.
OCR vagy látó modell? Melyik kell a te dokumentumaidhoz?
Tiszta, sablonos, nyomtatott dokumentumra a klasszikus OCR gyorsabb és olcsóbb. Zajos szkennelésre, kézírásra és változó feladóformátumra a látó nyelvi modell pontosabb. A gyakorlatban nem kell választani: az olcsó motor fut először, és csak a bizonytalan oldalak mennek tovább a drága modellhez. Ez a routing adja a költség nagy részét.
| Klasszikus OCR | Látó nyelvi modell | |
|---|---|---|
| Felépítés | szövegdetektálás, karakterfelismerés, utófeldolgozás három lépésben | vision encoder és nyelvi dekóder, egyetlen modellhívás |
| Sebesség / oldal | Tesseract 50-200 ms lokálisan | frontier modell 5-30 másodperc API-n |
| Tiszta nyomtatott | Textract 95%+, Tesseract 5 több mint 95% | GPT-4o 98%, Claude 3.5 Sonnet 97% |
| Romlott szkennelés | Textract 82% tételsorra, Tesseract 80-85% | Gemini 2.5 Pro 94%, Claude 3.5 Sonnet 90% |
| Kézírás | Tesseract kurzívra használhatatlan | GPT-5 95%, olmOCR-2-7B 94% (angol mérés) |
| Nehéz táblázat | Google Document AI 40% | PaddleOCR-VL 92,86 TEDS az OmniDocBench mérésén |
| Hibamód | hiányzó vagy torz karakter, szemmel látható | hihető, de hamis érték, nem látható |
A számokat érdemes fenntartással kezelni. Az AIMultiple DeltOCR benchmarkja 300 dokumentumon mér, de kizárólag angolul. Az olmOCR-Bench 8 413 unit tesztje 1 403 PDF-oldalon szintén angol. A dokumentumtípusonkénti pontossági tábla eredetije a Parslitól jön, ami maga is versenytárs a felsorolt eszközöknek, tehát elfogult.
Nálunk ilyenkor az a menetrend, hogy az ügyfél saját dokumentumaiból összerakunk egy 100-200 darabos mérőkészletet, és azon futtatjuk le a jelölteket. Egy hét munka, és utána tényszámról lehet beszélni ígéretek helyett. Az ő/ű és ó/ú pár, valamint az í a tipikus buktató, ezt kizárni kell, nem feltételezni.
Hogyan épül fel egy működő dokumentumfeldolgozó pipeline?
Négy szinten, és minden szint drágább az előzőnél. A dokumentum először a legolcsóbb úton próbál átmenni, és csak akkor lép feljebb, ha a konfidencia nem éri el a küszöböt. Ez a felépítés adja a költségkontrollt: a bejövő anyag nagy része soha nem jut el a legdrágább szintig.
| Szint | Mit csinál | Mikor lép be | Költség |
|---|---|---|---|
| 0. szint | a PDF beágyazott szövegrétegét olvassa ki (PyMuPDF, pdfplumber) | digitálisan generált PDF | közel nulla |
| 1. szint | gyors klasszikus motor (Tesseract, PaddleOCR) | olyan dokumentumosztály, ahol eléri a minőségi célt | nulla saját vason |
| 2. szint | specializált vagy frontier látó modell | zajos szkennelés, kézírás, egyedi elrendezés | 2-25 USD / 1 000 oldal |
| 3. szint | emberi felülvizsgálat | kritikus mező alacsony konfidenciával | 1-5 perc / dokumentum |
A routing kalibrálása fontosabb, mint a modellválasztás. Egyetlen oldalszintű átlagkonfidencia nem elég: a kritikus mezőkre (adószám, végösszeg, IBAN) külön, szigorúbb küszöb kell, dokumentumosztályonként eltérő szabállyal. Ha ezt kihagyod, vagy mindent felküldesz a drága modellhez, vagy átengedsz hibás értékeket.
A validációs réteg, ami nélkül nem szabad élesíteni
Mivel a látó modell hihető, de hamis értéket ad, a hibát nem a modellen belül kell megfogni, hanem utána. Négy ellenőrzés fut nálunk minden számlára, és mindegyik olcsó a hibás könyveléshez képest.
- Aritmetikai egyeztetés: a nettó és az áfa összege kiadja-e a bruttót, a tételsorok összege kiadja-e a végösszeget.
- Formátum-ellenőrzés reguláris kifejezéssel a dátumra, az adószámra, az IBAN-ra és a telefonszámra.
- Keresztellenőrzés második modellel, de csak a kritikus mezőkre, különben a költség megduplázódik.
- Egyeztetés a NAV Online Számla adattal, ha belföldi B2B számláról van szó. Ez a magyar plusz, amit a nemzetközi eszközök nem tudnak.
A mérés is feladattípusonként más. Sima szövegnél karakter- és szóhiba-arány (CER, WER) a metrika, űrlapnál és nyugtánál a pontos egyezési arány és a mezőnkénti F1, táblázatnál a TEDS, kérdés-válasz jellegű kinyerésnél az ANLS. Ha az ajánlatban csak egy globális pontossági százalék szerepel, kérdezz rá, melyik metrikáról van szó.
A 12 use case: manuális idő, automatizálható arány, hibaarány, emberi ellenőrzés
Tizenkét dokumentumfeldolgozási feladat következik, mindegyiknél ugyanaz a négy adat. A lista fele publikusan mért, a másik fele nem. Ezt nem szépítjük: a hat mért esetnél megnevezzük a forrást, a hat mérés nélkülinél odaírjuk, hogy becslés.
A hat mért use case
| Use case | Manuális időigény | Automatizálható | Hibaarány | Emberi ellenőrzés |
|---|---|---|---|---|
| 1. Bejövő számla | 8-15 perc / számla | 55-75% érintésmentes az első évben | 3-5% kézzel, 0,5% alatt automatizálva | kivételarány 14% (best-in-class 9%) |
| 2. Szerződéskivonatolás | 1-3 óra közepes szerződésnél (becslés) | a kivonatolás közel teljesen, a minősítés nem | AI 94% vs jogász 85% NDA-kockázatra | 100% a jogi értékelésre |
| 3. E-mail triage | az ügyintézői idő 20-31%-a megy triage-re | Tier-1 deflekció 55-70% | gyártói 98% osztályozás, független mérés nincs | 30-45% |
| 4. Önéletrajz-szűrés | 6-7 mp szkennelés, 2-3 perc érdemi átnézés | 500 önéletrajz 83 óra helyett 15 perc | AI konzisztencia 85-95% vs emberi 60-70% | jogilag kötelező, lásd AI Act Annex III 4(a) |
| 5. Biztosítási kárbejelentés | 30-60 perc / akta kivonatolás | 20-40% ciklusidő-csökkenés | nincs megbízható publikus adat | 100%, ha a döntés elutasítás |
| 6. Banki KYC | 18+ perc / verifikáció | verifikáció 30 mp alatt, 48-70% költségcsökkenés | nincs megbízható publikus adat | 100% AML-találatnál és PEP-egyezésnél |
A hat use case, amire nincs publikus mérés
| Use case | Manuális időigény | Automatizálható | Hibaarány | Emberi ellenőrzés |
|---|---|---|---|---|
| 7. Orvosi lelet | 5-20 perc / lelet (becslés) | a kivonatolás igen, az értelmezés nem (becslés) | nincs adat | 100%, GDPR 9. és 22. cikk |
| 8. Közbeszerzési dokumentáció | 2-8 óra / ajánlati felhívás (becslés) | az alkalmassági feltételek kigyűjtése igen (becslés) | nincs adat | 100% az ajánlati döntésre |
| 9. Garancialevél | 5-15 perc / levél (becslés) | magas, sablonos dokumentum (becslés) | nincs adat | csak kivételkezelés (becslés) |
| 10. Szállítólevél | 3-8 perc / bizonylat (becslés) | magas, ha a beszállítói kör stabil (becslés) | nincs önálló mérés, a 3-way match része | eltérésnél 100% |
| 11. Üzleti jegyzőkönyv | 20-60 perc / jegyzőkönyv (becslés) | a feladatkiosztás kinyerése igen (becslés) | nincs adat | 100%, ha jogi hatálya van |
| 12. Áfabevallás előkészítés | változó, a tételszámtól függ | nem kiolvasási, hanem besorolási feladat | nincs adat | 100% a bevallás jóváhagyásánál |
1. Bejövő számla
A legjobban dokumentált eset, és egyben a legtöbbet túlígért. Az Ardent Partners 2025-ös AP-benchmarkja szerint egy számla átlagosan 9,40 dollárba kerül, a legjobb negyed 2,78 dollárból megoldja, a feldolgozási idő átlagosan 9,2 nap. Az APQC mediánja 21,40 dollár, a felső kvartilis 10,18. A Hypatos 85-92 százalék érintésmentes feldolgozást állít SAP- és Oracle-környezetben, a független all-buyer átlag viszont 25 százalék körül van.
30-35%
az adatrögzítés részaránya a teljes számlafeldolgozási költségből
IOFM, Lido összesítés
14%
átlagos kivételarány, best-in-class 9%, leggyengébb negyed 22%
Ardent Partners 2025
55-75%
reális érintésmentes arány magyar KKV-nál az első évben
AppForge vállalás
A legfontosabb ROI-üzenet nem a százalék, hanem a költségszerkezet. Az IOFM szerint az adatrögzítés a teljes számlafeldolgozási költség 30-35 százaléka, a kivételkezelés 20-25 százaléka. Az AI tehát a költség nagyjából felét célozza, nem az egészet. Aki 80 százalékos megtakarítást ígér számlafeldolgozásra, az a saját számait sem nézte meg.
2. Szerződéskivonatolás
A JPMorgan COIN rendszere évi 360 ezer jogász- és hitelezői munkaórát spórolt kereskedelmi hitelszerződések átnézésén, 12 ezernél is több éves szerződésen. Fontos részlet, amit a legtöbb ügynökségi anyag elhallgat: ez 2017-es adat, kilencéves. A LawGeex NDA-tanulmánya, amely 94 százalékos AI-pontosságot mért a jogászok 85 százalékával szemben, 2018-as.
A kivonatolás gyakorlatilag teljesen automatizálható: felmondási idő, kötbér, szavatosság, joghatóság kiszedhető. A jogi minősítés nem. Nem azért, mert a modell nem képes rá, hanem mert a szakmai felelősség nem delegálható egy API-nak. Ezt a határvonalat az ajánlatban is le kell írni.
3. E-mail triage
Gartner-hivatkozású mérés szerint a teljes ügyintézői kezelési idő 31 százaléka megy el a beérkező üzenetek olvasására, címkézésére és újraosztására, más mérés szerint a munkanap 20-30 százaléka. A Zendesk 2025-ös CX Trends adata szerint napi 500 e-mail felett a levelek nagyjából 22 százaléka elveszik félreirányítás, duplikáció vagy határidőcsúszás miatt.
Az első szintű ügyek 55-70 százaléka elterelhető: rendelésstátusz, nyitvatartás, visszaküldés, készlet. Eszkalációnál az automatikus összefoglaló 35-45 százalékkal csökkenti a kezelési időt. A 98 százalékos osztályozási pontosság gyártói szám, független mérés nincs mögötte.
4. Önéletrajz-szűrés
Egy toborzó 6-7 másodperc alatt szkennel át egy önéletrajzot, érdemi átnézésre 2-3 perc kell. Ötszáz önéletrajz így 83 óra, az automatizált szűrés 15 perc. Az AI konzisztenciája 85-95 százalék, az emberi bírálók egyetértése 60-70. A toborzók a kvalifikált jelöltek 20-30 százalékát elszalasztják.
Ez viszont a legkockázatosabb tétel a listán. Az EU AI Act Annex III 4(a) pontja kifejezetten nevesíti az álláspályázatok elemzését és szűrését magas kockázatú felhasználásként, a GDPR 22. cikke pedig tiltja a kizárólag automatizált elutasítást. Akadémiai kutatások tartós torzítást mutatnak nők, idősebb és fogyatékossággal élő jelöltek ellen. Emberi felülvizsgálat nélkül ez nem bevezethető.
5. Biztosítási kárbejelentés
A CAIC 2026-os kárrendezési playbookja 20-40 százalékos ciklusidő-csökkenést mér dokumentumnehéz ágakon, és kárszakértőnként 30-60 perc megtakarítást aktánként. A kárszakértői kapacitás 15-30 százalékkal nő, ha a változáskezelés is rendben van. Az első éles use case 60-120 nap alatt áll fel.
A playbook szándékosan nem közöl nevesített biztosítói esettanulmányt. A több blogban keringő Aviva-számot nem sikerült elsődleges forrásból megerősíteni, ezért nem is használjuk.
6. Banki KYC
Egy komplex intézményi ügyfél manuális átvilágítása 1 500 és 3 000 dollár közé esik, egy verifikáció 18 percnél is több. Automatizálva a verifikáció 30 másodperc alá megy, az esetenkénti költség 48-70 százalékkal csökken, a teljes onboarding-idő közel 90 százalékkal. Egy nevesítetlen regionális bank esettanulmánya 5 munkanapról 4 órára rövidült átfutást közöl.
Az AML-találat, a PEP-egyezés és a magas kockázatú joghatóság kivétel nélkül emberi döntés marad, ez nem opció, hanem jogszabályi kötelezettség.
7. Orvosi lelet
Erre nincs publikus benchmark, se magyarul, se angolul, ezért a táblázatban minden szám becslés. Egy tény viszont dokumentált: az Anthropic saját vision-leírása kimondja, hogy a modell nem alkalmas összetett diagnosztikai felvételek, például CT vagy MRI értelmezésére, és a kimenet nem helyettesíti a szakorvosi véleményt.
Ami reálisan működik: a lelet szövegének strukturálása, leletkivonatolás beutalóhoz, kódolás előkészítése. A döntés maradjon emberé, mert itt a GDPR 9. cikk szerinti különleges adat és a 22. cikk együtt lép be.
8. Közbeszerzési dokumentáció
Az ajánlati felhívások és műszaki leírások átolvasása időigényes, és a hiba drága, mert egy kihagyott alkalmassági feltétel érvénytelen ajánlatot jelent. Mért megtérülésre nem találtunk forrást. Amit a modell jól csinál: kigyűjti a határidőket, a formai követelményeket, a referenciaelvárásokat és az értékelési szempontokat egy összehasonlító táblába.
Az ajánlati döntés emberé marad, és a magyar EKR-rendszer sajátosságait a kinyerő sémába külön bele kell tervezni.
9. Garancialevél
Sablonos, rövid, ismétlődő dokumentum, tehát papíron ideális jelölt. Publikus mérés nincs rá. A gyakorlati kérdés itt nem a pontosság, hanem a volumen: ha havonta harminc garancialevél érkezik, a fejlesztés soha nem térül meg. Ezer felett viszont az egyik legolcsóbban automatizálható tétel a listán.
10. Szállítólevél
Önálló mért adatot nem találtunk, mert a beszerzési benchmarkok a szállítólevelet a hármas egyeztetés (megrendelés, szállítólevél, számla) részeként kezelik. Ez viszont a legjobb hír: a szállítólevél nem önálló projekt, hanem a bejövő számla pipeline része, és ott már van mért megtérülés.
Eltérés esetén emberi ellenőrzés kell, mert a mennyiségi eltérés pénzügyi és készletkövetkezménnyel jár. A visszaírás az ERP vagy WMS irányába technikailag rendszerintegrációs feladat, nem AI-feladat.
11. Üzleti jegyzőkönyv
Mért ROI-t erre sem találtunk. Létezik viszont magyar Transkribus-modell testületi jegyzőkönyvekre, igaz, történeti anyagra tanítva. A modern use case egyszerűbb: a jegyzőkönyvből kinyerni a döntéseket, a felelősöket és a határidőket, majd feladatként betölteni a projektrendszerbe.
Ha a jegyzőkönyvnek jogi hatálya van, például taggyűlési határozat, akkor a kimenetet minden esetben jóvá kell hagyatni.
12. Áfabevallás előkészítés
Ez Magyarországon nem kiolvasási probléma. A NAV eÁFA M2M-interfészspecifikáció 2.0-ja 2026 májusában jelent meg, a tesztkörnyezet júliustól elérhető, és a PwC összefoglalója szerint 2026. augusztus 3-tól a 2.0-s adatstruktúrát kell használni. A NAV a beküldött adatcsomagot validálja, és ebből áll össze a bevallási tervezet, amit gépi úton jóvá lehet hagyni.
Az AI itt a tételszintű besorolásban ér valamit: kontírozási javaslat, áfakulcs-hozzárendelés, adómentességi jogcím, fordított adózás felismerése. A szövegkiolvasásban nem. Erre publikus megtérülésmérést nem találtunk.
Mi más Magyarországon: NAV, ékezet, kézírás
A legfontosabb magyar technikai tény: belföldi B2B számlánál nem kell OCR-ezni. A strukturált adat már a NAV-nál van, és lekérdezhető. Az Online Számla interfészspecifikáció 3.0 két végpontja elég hozzá: a queryInvoiceDigest összesített adatot ad keresési paraméterek alapján, a queryInvoiceData a teljes számlaadatot számlaszám alapján.
A gyakorlati architektúra ezért háromrétegű. Első réteg a NAV-adat mint kiindulási igazság. Második réteg a képfelismerés, de csak arra, ami a NAV-nál nincs benne: külföldi beszállító, nyugta, költségtérítés. Harmadik réteg a kettő automatikus egyeztetése. Ez pontosabb, mint a tisztán képfelismerésre épülő nemzetközi eszközök, és a hazai szállítók közül alig valaki kommunikálja.
Az ékezet valós, mérhető kockázat a klasszikus motoroknál. A Tesseract szegmentálása és tanítóanyaga történetileg az angolra és a strukturált latin szövegre optimalizált, és a Klippa leírása szerint az erős diakritika ívelt betűtípussal és színes háttérrel érdemben rontja a pontosságot. A magyar hun modell rossz minőségű szkennen nem megbízható.
Kézírásra a nagy látó modellek angolul 93-95 százalékot mutatnak, magyarra viszont nincs bizonyíték. A legjobb elérhető magyar adat a Transkribus 19-20. századi kézírás-modellje 10,7 százalékos karakterhiba-aránnyal, 1 265 oldalas tanítóanyagon. Ez történeti anyag, nem átvételi elismervény. A többnyelvű ATR-benchmarkok között a 2026-os METATR 29 nyelvet fed le, és a magyar nincs köztük.
Mit ír elő a GDPR és az AI Act dokumentumfeldolgozásnál?
A GDPR 22. cikke szerint az érintettnek joga van ahhoz, hogy ne terjedjen ki rá kizárólag automatizált adatkezelésen alapuló döntés, amely rá nézve joghatással jár. Az AI Act 50. cikkének átláthatósági kötelezettségei 2026. augusztus 2-tól élnek. A magas kockázatú rendszerek kötelezettségei a 2026/1744 rendelettel 2027. december 2-re csúsztak.
| Feladat | GDPR 22. cikk | AI Act kötelezettség |
|---|---|---|
| Bejövő számla kontírozás | nem érinti, nem személyről szóló döntés | nincs 50. cikk kötelezettség |
| Önéletrajz-szűrés | érinti, ha az elutasítás automatikus | 50(1) tájékoztatás, 2027-12-02-től Annex III 4(a) magas kockázat |
| Hitelbírálat dokumentumból | érinti | Annex III 5(b), 2027-12-02-től |
| Biztosítási kárelbírálás | érinti, ha automatikusan elutasít | Annex III 5(c) élet- és egészségbiztosításnál |
| Orvosi lelet | érinti, plusz 9. cikk különleges adat | kizárólag emberi döntés |
| AI-generált válaszlevél ügyfélnek | önmagában nem | 50(1): jelezni kell, hogy AI-val kommunikál |
Az adatátadás külön kockázat, és ezt a legtöbb ajánlat kihagyja. A Gemini API ingyenes szintjén a Google saját közlése szerint a tartalmat termékfejlesztésre használják, tehát ügyféladatra nem alkalmas. Az Anthropic vision-dokumentációja szerint a feltöltött képeket nem használják modelltanításra, a képfeltöltés efemer, és a PDF-feldolgozás jogosult a nulla adatmegőrzési opcióra. Ha a dokumentum orvosi vagy ügyvédi titok, marad a lokális futtatás: Docling, PaddleOCR vagy Tesseract saját vason.
Melyik dokumentum nem éri meg az automatizálást?
Az alacsony volumenű, ritkán érkező és mindig más formátumú dokumentum. Havi 50 darabnál egy 2,5 millió forintos fejlesztés évtizedek alatt térül meg. Nem éri meg a belföldi B2B számla képi kiolvasása sem, mert a NAV-adat pontosabb. És nem éri meg ott, ahol a kimenetet jogi vagy orvosi felelősség miatt úgyis végig kell nézni.
| Mikor ne csináld | Miért | Mit csinálj helyette |
|---|---|---|
| Havi 100 dokumentum alatt | a fejlesztés és a karbantartás fixköltsége nem oszlik el | sablon plusz gyorsbillentyűs rögzítés, vagy szolgáltatói portál |
| Belföldi B2B bejövő számla képi kiolvasása | a NAV Online Számla adat pontosabb és ingyen van | NAV-lekérdezés, és képfelismerés csak a maradékra |
| Minden dokumentum más felépítésű | nincs mit tanulni, minden eset kivétel | előbb a beérkezési formátumot szabványosítsd |
| A kimenetet 100%-ban ellenőrizni kell | a megtakarítás a kettős munkával elolvad | az AI csak előkészítsen, ne döntsön, és mérd, marad-e haszon |
| Áfabevallás szövegkiolvasással | nem kiolvasási, hanem besorolási feladat | eÁFA M2M integráció, plusz tételszintű besorolási javaslat |
| Kézírás magyar mérőkészlet nélkül | nincs publikus magyar pontossági adat, vakon vállalnál | előbb mérj 100-200 dokumentumon, utána árazz |
Van egy hetedik eset, amit ritkán mondanak ki. Ha a folyamat azért lassú, mert a jóváhagyó három napig nem nyitja meg a levelet, akkor a kiolvasás felgyorsítása semmit nem ér. Előbb a szűk keresztmetszetet kell megtalálni. A folyamatautomatizálási alapok erről bővebben szólnak.
Mennyibe kerül egy dokumentum feldolgozása?
A modelldíj ezer oldalra vetítve 1,5 dollártól 50 dollárig terjed a szolgáltatótól és a művelettől függően. Ez viszont a teljes költség töredéke: a manuális feldolgozás számlánként 10-22 dollár, az automatizált 0,5-1 dollár. A különbség nagy részét nem az API adja, hanem a fejlesztés, a validáció és a kivételkezelés.
| Eszköz | Művelet | Ár / 1 000 oldal | Ingyenes keret |
|---|---|---|---|
| Azure AI Document Intelligence | Read (OCR) | 1,50 USD | 500 oldal/hó (F0) |
| Azure AI Document Intelligence | Prebuilt számla, nyugta, ID | 10 USD | ua. |
| Azure AI Document Intelligence | Custom Extraction | 30 USD | ua. |
| AWS Textract | DetectDocumentText | 1,50 USD | 1 000 oldal/hó 3 hónapig |
| AWS Textract | AnalyzeExpense (számla, nyugta) | 10 USD | 100 oldal/hó |
| AWS Textract | AnalyzeDocument Forms | 50 USD | 100 oldal/hó |
| Google Document AI | Form Parser | 30 USD | nincs |
| Mistral OCR 4.0 | OCR | 3,50 EUR (batch kb. fele) | nincs |
| Unstructured.io | platform | 30 USD | 15 000 oldal/hó |
| Docling (MIT licenc) | self-host | 0 USD licencdíj, csak compute | korlátlan |
A frontier modellek külön számítást igényelnek, mert oldalanként fizetsz tokenért, nem oldalért. Az Anthropic dokumentációja szerint egy PDF-oldal 1 500-3 000 szövegtokent visz, és minden oldal képként is bemegy, a képtoken plafonja standard szinten 1 568. Ebből egy A4-es oldal nagyjából 3 568 bemeneti token, plusz körülbelül 300 kimeneti token a JSON-válaszra.
| Modell | 1 000 oldal (input + output) | Batch API (-50%) |
|---|---|---|
| Claude Haiku 4.5 | kb. 5,07 USD | kb. 2,54 USD |
| Claude Sonnet 5 | kb. 10,14 USD | kb. 5,07 USD |
| Claude Opus 5 | kb. 25,34 USD | kb. 12,67 USD |
Két olcsó kar van, amit sokan kihagynak. A batch feldolgozás felezi a bemeneti és kimeneti árat is, dokumentum-pipeline-nál pedig ritkán kell valós idejű válasz. A prompt gyorsítótár olvasása a normál ár egytizede, és mivel a hosszú rendszerprompt meg a kinyerési séma minden hívásnál ugyanaz, ez a leggyorsabban megtérülő optimalizálás.
Mennyi a fejlesztés maga?
A folyamatautomatizálási árlistánk szerint egy egyszerű, 1-3 lépéses munkafolyamat 100 000 és 500 000 forint között van, a többrendszeres integráció hibakezeléssel 500 000 és 2 500 000 forint között, az AI-vezérelt komplex automatizálás (számla-OCR, AI-osztályozás és jóváhagyási folyamat együtt) 2 500 000 és 10 000 000 forint között. A karbantartás havi 30 000 és 150 000 forint. A pilot 1-2 hét, a megtérülés jellemzően 3-9 hónap.
Egy modellszámítás, ami pont a magyar középvállalati profilra illeszkedik: egy nevesítetlen európai KKV esettanulmánya évi 12 000 beszállítói számlánál 65 százalékos adatrögzítés-csökkenést, 600 megspórolt munkaórát és 40 000 euró bérköltség-megtakarítást közöl. A forrás gyártói és az ügyfél nincs megnevezve, tehát ezt modellnek használd, ne bizonyítéknak.
Összegzés és gyakori kérdések
Mit tud ma egy dokumentumfeldolgozó AI, és mit nem?
Kiolvassa a beérkező dokumentumot és strukturált mezőkké alakítja: számlaszám, adószám, végösszeg, dátum, tételsorok. Amit nem tud: garantálni, hogy a kiolvasott érték helyes. A látó modellek jellemző hibája, hogy formailag hibátlan, tartalmilag hamis számot adnak vissza, például 45,20 helyett 42,50-et. Ezért kell mellé validációs réteg és emberi kivételkezelés.
Melyik a jobb: klasszikus OCR vagy látó nyelvi modell?
Tiszta, sablonos, nyomtatott dokumentumra a klasszikus OCR gyorsabb és olcsóbb: a Tesseract 50-200 ezredmásodperc alatt olvas egy oldalt, egy frontier modell 5-30 másodperc alatt. Zajos szkennelésre, kézírásra, változó feladóformátumra a látó modell pontosabb. A gyakorlatban a kettő együtt fut: olcsó motor először, drága modell csak a bizonytalan oldalakra.
Mekkora arányban automatizálható a bejövő számla feldolgozása?
A gyártók 85-92 százalék érintésmentes feldolgozást állítanak, a független Ardent Partners benchmark 25-35 százalékot mér. A különbség a mintaválasztásból jön. Magyar KKV-nál, vegyes beszállítói körrel az első évre 55-75 százalék a reális vállalás. Az IOFM szerint az adatrögzítés a teljes számlafeldolgozási költség 30-35 százaléka, tehát nem az egész költséget célozzuk.
Kell-e OCR a magyar bejövő számlákhoz?
Belföldi B2B számlánál nem. A NAV Online Számla rendszerben a strukturált adat már ott van, és a queryInvoiceDigest, illetve queryInvoiceData végponttal lekérdezhető. OCR-re csak a maradék kell: külföldi beszállító, nyugta, költségtérítés. Ez a háromrétegű felépítés pontosabb, mint a tisztán képfelismerésre épülő nemzetközi eszközök.
Mennyire pontos a dokumentumfeldolgozó AI magyar nyelven?
Nyilvános, reprodukálható magyar benchmark üzleti dokumentumokra nem létezik. Ami van: a Transkribus magyar kézírás-modellje 10,7 százalékos karakterhiba-arányt közöl, egy 2026-os F1000Research-cikk finomhangolt TrOCR-rel 3,681-es értéket mér. Aki 95 százalékos magyar számlapontosságot ígér, az nem mérésre hivatkozik. Kérj tőle mérőkészletet.
Mennyibe kerül dokumentumonként a feldolgozás?
A modelldíj ezer oldalra vetítve 1,5 dollártól 50 dollárig terjed a szolgáltatótól és a művelettől függően: Azure Read 1,5 dollár, AWS Textract AnalyzeExpense 10 dollár, Google Form Parser 30 dollár, Mistral OCR 4.0 3,5 euró, Docling nulla licencdíj. Ez viszont a teljes költség töredéke. A manuális feldolgozás számlánként 10-22 dollár, az automatizált 0,5-1 dollár.
Melyik dokumentumfeldolgozási feladat nem éri meg?
Az alacsony volumenű, ritkán érkező és mindig más formátumú dokumentum. Havi 50 dokumentumnál egy 2,5 millió forintos fejlesztés évtizedek alatt térül meg. Nem éri meg a belföldi B2B számla képi kiolvasása sem, mert a NAV-adat pontosabb, és nem éri meg ott, ahol a kimenetet jogi vagy orvosi felelősség miatt úgyis száz százalékban ellenőrizni kell.
Milyen jogi kötelezettség vonatkozik a dokumentumfeldolgozó AI-ra?
A GDPR 22. cikke tiltja a kizárólag automatizált, joghatással járó döntést, tehát önéletrajz-elutasításnál, hitelbírálatnál, kárelutasításnál emberi felülvizsgálat kell. Az AI Act 50. cikkének átláthatósági szabályai 2026. augusztus 2-tól élnek. Az Annex III magas kockázatú kötelezettségek a 2026/1744 rendelettel 2027. december 2-re csúsztak, ez érinti az önéletrajz-szűrést és a hitelképesség-értékelést.
Hol tartunk mi ebben
Egy dolgot érdemes kimondani, mert a magyar piacon senki nem mondja ki: 2026 augusztusában nem létezik egyetlen publikált, nevesített, auditált magyar esettanulmány sem, amely dokumentumfeldolgozó AI megtérülését mérte volna. Se a miénk, se a versenytársainké. Aki magyar számokat idéz, az nemzetközi benchmarkot fordít le. Ez pont azért baj, mert a magyar felállás technikailag más: a NAV-adat miatt jobb kiindulási helyzetből indulunk, mint a nyugati eszközök.
Ha dokumentumfeldolgozást terveztek, a folyamatautomatizálás oldalunk írja le, hogyan épül fel egy ilyen projekt, az AI integrációs esettanulmányok pedig azt, mit szoktunk hét különböző helyzetben csinálni. Az éles projektjeink az AI portfólió oldalon vannak.
Források
- Számlafeldolgozási benchmarkok: WEX (Ardent Partners 2025 idézése), Lido (APQC, Ardent, IOFM), Hypatos
- Szerződés és jog: ABA Journal a JPMorgan COIN-ról (2017)
- E-mail, toborzás, kárrendezés, KYC: Fini Labs, Equip, CAIC playbook, Lorikeet
- OCR-pontosság: AIMultiple DeltOCR, olmOCR-Bench, OmniDocBench, Parsli, Klippa a Tesseractról
- Magyar nyelv: Transkribus magyar modellek, F1000Research 15:181, METATR v1.0 (arXiv:2605.26712)
- NAV: Online Számla interfészspecifikáció 3.0, nyugtaadat-szolgáltatás, eÁFA M2M 2.0
- Jog: GDPR 22. cikk, AI Act 50. cikk, AI Act Annex III
- Árak: AWS Textract, Azure AI Document Intelligence, Mistral OCR 4.0, Unstructured.io, Docling, Anthropic árlista, Gemini API árak
