PDF-ből Excelbe automatikusan: AI adatkinyerés üzleti dokumentumokból

Fontos az elején tisztázni egy hatalmas iparági félreértést: ez a cikk nem egy asztali "PDF to Excel Converter" szoftverről szól, amit ezer forintért le lehet tölteni, és megpróbálja a PDF vonalait Excel cellákká formázni. Üzleti környezetben (számlák, szerződések, megrendelések ezreinek feldolgozásakor) a dokumentumfeldolgozás célja sosem a "vizuális kinézet" vagy a formázás megtartása.

A cél a strukturált, megbízható adatkinyerés és a kíméletlen üzleti validáció. Nem az érdekel minket, hogy milyen betűtípussal írták a számlát, hanem az, hogy a nettó összeg pontosan a mi rendszerünk "Nettó" oszlopába (az adatbázisba) kerüljön, adóügyileg validáltan.

Ez a folyamat a bemeneti forrás technikai minőségétől függően lépcsőzetesen épül fel (az egyszerűtől a bonyolult AI felé):

• 1. Digitális (Text-native) PDF → Szövegkinyerő (Parser) / Reguláris kifejezések (Nincs AI)
• 2. Szkennelt papír / Kép → Ipari OCR (Optikai Karakterfelismerés - Csak digitalizál, nem értelmez)
• 3. Változó struktúra / Szabad szöveg → Document AI (LLM / Vizuális modell) Szemantikai Értelmezés
• 4. BÁRMELYIK fenti után KÖTELEZŐ: → Üzleti Validációs Motor → Döntés (Automatikus betöltés VAGY Emberi jóváhagyás)

A laikusok gyakran egy kalap alá veszik a PDF-eket, mintha az egy egységes fájltípus lenne, pedig programozói (informatikai) szempontból hatalmas a különbség köztük. A rendszertervezés nulladik lépése annak meghatározása, hogy a vállalatnál forgó dokumentumok melyik kategóriába esnek. Ez dönt a fejlesztési költségről.

• Text-native (Digitális) PDF: Olyan PDF, amit egy szoftverből (pl. Word-ből, vagy egyenesen az ERP rendszerből) "Nyomtatás PDF-be" vagy "Export" paranccsal generáltak. Ennek óriási előnye, hogy a betűk, mint digitális karakterek benne vannak a fájl kódjában. Az egerével ki tudja jelölni és le tudja másolni a szöveget. Itt NINCS szükség OCR-re, mert a szöveg már létezik. (Ez a legolcsóbb és legstabilabb eset).
• Scan / Kép alapú PDF: Egy fizikailag kinyomtatott, lepecsételt, majd egy irodai szkennerrel vagy mobiltelefonnal lefotózott lap, amit PDF kiterjesztéssel mentettek el. A gép számára ez nem szöveg, hanem egy halom színes pixel (egy kép). Ebből a gép csak bonyolult OCR technológiával képes a betűket kitalálni.
• Kötött Űrlap (Form): Például egy adóbevallás vagy hatósági bejelentő. A vonalak és a rubrikák milliméterre pontosan mindig ugyanott vannak, a válaszok pedig jól látható mezőkben (dobozokban) találhatók.
• Beszállítói Számla (Invoice): Erősen kötött adattartalom (mert törvény írja elő, mi kell rá: adószám, nettó, ÁFA), de ahány beszállító, annyiféle dizájn, logó és elrendezés (layout). Ezt klasszikus programozással szinte lehetetlen lefedni.
• Jogi Szerződés (Contract): Hosszú, többoldalas folyószöveg, bekezdésekkel, amiből konkrét, rejtett tényeket (felek neve, dátumok, kötbér mértéke) kell az értelmezőnek kinyernie.

A piacon sok szoftvercég próbálja eladni a méregdrága mesterséges intelligencia csomagjait olyan feladatokra, amelyekhez egyáltalán nincs rá szükség. Ha az Ön cégének feldolgozandó PDF-jei fix layoutúak (például mindig ugyanaz a gigavállalat küldi a riportot, milliméterre pontosan ugyanazzal a dizájnnal), és a dokumentum text-native formátumú, akkor az AI (LLM) bevonása technológiai hiba.

Ilyenkor egy rendkívül olcsó, végtelenül gyors, és (ami a legfontosabb) 100%-ig determinisztikus (tévedhetetlen) szoftveres parser-re van szükségünk. A fejlesztő ír egy kódot (Reguláris kifejezést, vagy egy x-y koordináta leolvasót), ami megmondja a gépnek: "Keresd meg a 'Bruttó fizetendő' szót, és az utána következő 10 karaktert másold be az adatbázisba". Ez másodpercenként ezres nagyságrendben, hiba nélkül fut. AI-t ide tenni felesleges kockázat lenne.

Az OCR (Optical Character Recognition – Optikai Karakterfelismerés) akkor lép be, ha a dokumentum egy szkennelt kép (pixelsor). Az ipari OCR motorok (pl. Google Vision, AWS Textract, Tesseract) óriási fejlődésen mentek keresztül, de fontos megérteni a fizikai korlátaikat:

Az OCR csak a betűket "látja", de az értelmüket nem fogja fel.

Az OCR önmagában nem tudja, hogy a kép jobb alsó sarkában felismert "1 2 3 4 5" az egy budapesti irányítószám, egy raktári cikkszám, vagy a fizetendő nettó végösszeg euróban. Csak azt tudja, hogy ott van öt darab számjegy (és esetleg azt, hogy milyen betűtípussal és milyen x-y koordinátán). Az üzleti jelentést (a szemantikát) a következő, jóval intelligensebb rétegnek kell hozzáadnia.

A modern nyelvi és vizuális AI modellek (pl. GPT-4, Claude, specifikus LayoutLM modellek) pontosan ott veszik át az irányítást, ahol a hagyományos, szabályalapú informatikai rendszerek (a reguláris kifejezések) "eltörnek". Hol van szükségünk rájuk?

• Eltérő beszállítói sablonok káosza: Ha a cégének van 2000 különböző beszállítója, az 2000 különböző dizájnú számlát jelent. Lehetetlen 2000 különböző kódszabályt (Template-et) fenntartani és frissítgetni. A modern AI (a szavak környezete alapján) pusztán a logikából megérti, hogy a "Fizetendő", a "Mindösszesen", vagy a "Total Due" ugyanazt jelenti, függetlenül attól, hogy a papír melyik sarkában van.
• Változó mezőpozíciók és több oldalas számlák: A dokumentum hossza és a keresett mezők helye folyamatosan változik (pl. egy szállítólevél hol 1 oldalas, hol 3, a végösszeg hol a 2. oldal közepén, hol a legvégén szerepel).
• Komplex Táblázatok (Line items): Ha egy táblázat átfolyik a következő oldalra, ráadásul a fejléc nem ismétlődik meg az új oldalon. Hagyományos kóddal az ilyen táblázat-folytatásokat szinte lehetetlen hiba nélkül összefűzni.
• Strukturálatlan, Szabad szöveg (Unstructured data): Kinyerni egy 40 oldalas jogi dokumentumból a választ egy konkrét kérdésre: "Milyen események (Force Majeure) esetén bontható fel a szerződés kötbér nélkül?". Ezt kizárólag a LLM-ek (Large Language Models) képesek elolvasni és szintetizálni.

Ha valaki havonta pár darab PDF-ből akar adatot kimásolni, használja bátran a ChatGPT webes felületét. De egy vállalati folyamat (pl. a bejövő számlafeldolgozó részleg leváltása) egy robusztus, többlépcsős Data Pipeline-t követel meg, ami képes hiba nélkül elnyelni a napi 5000 dokumentumot is:

[Forrás: Bejövő Email Fiók / sFTP Scanner]
  ↓
[Lépés 1: Fájl osztályozása (Classification)] -- (Ez egy számla vagy egy spam?)
  ↓
[Lépés 2: Képminőség javítás (Pre-processing)] -- (Dőlésjavítás, zajszűrés)
  ↓
[Lépés 3: Ipari OCR Engine] -- (Pixelek átalakítása nyers szöveggé)
  ↓
[Lépés 4: AI Extraction (Kinyerés)] → {Szállító: X Kft, Dátum: 2026.05.04, Nettó: 15.000}
  ↓
[Lépés 5: ÜZLETI VALIDÁCIÓ ÉS MASTER DATA CHECK (Kötelező!)]
    ⊢→ [Matek Check]: Nettó + ÁFA == Bruttó?
    ⊢→ [CRM Check]: Létezik ez az adószám a rendszerünkben?
    ⊢→ [Duplikáció]: Ezt a sorszámot kifizettük már tegnap?
  ↓
[Lépés 6: Döntési Routing (Confidence Score alapján)]
    ⊢→ HA a gép bizonytalan (Pl. score < 95%), vagy elbukott a Validáció → [Emberi Ellenőrzés (Review Queue)]
    └→ HA minden valid (STP - Straight Through Processing) → [Automatikus írás az ERP-be / Excelbe]

A PDF fejlécéből (ki küldte, mi a dátum) kinyerni az adatot a modern rendszereknek már gyerekjáték. A technológiai vízválasztó a táblázatok, konkrétan a Számla Tételsorainak hibátlan felismerése. Egy professzionális AI rendszernek tudnia kell kezelni (normalizálni) az alábbi káoszt:

• Összevont (Merged) és Több sorba lógó cellák: Amikor a hosszú terméknév (pl. "Nagy teljesítményű ipari fúrógép, 220V") vizuálisan két-három sorba törik, de az ára csak egyetlen sorban van mellette. Az AI-nak össze kell fűznie ezt az egyetlen logikai tétellé.
• Lokalizáció és Tizedesjelek (Decimal Separators): Az egyik beszállító angol szoftvert használ ponttal (1,234.56), a magyar magyarul vesszővel (1 234,56). A kinyerő rendszernek (Data Normalization) ezt a betöltés előtt feltétlenül egységes (Float) típusú adattá kell alakítania, különben az ERP tízmilliós tételt könyvel be az ezer forintos helyett.
• Pénznemek (Currencies): Van aki azt írja "USD", van aki azt hogy "$", van aki azt hogy "Dollár". Ezeket a rendszernek azonnal a standard 3 betűs ISO kódokra (pl. EUR, HUF) kell fordítania.
• Mértékegységek (Units): Ugyanez igaz a db, darab, pc, pcs, kg, kilogramm egységesítésére.
• Üres és implicit (Missing) cellák: Ha az ÁFA százalék oszlop teljesen üres, mert az adott tétel adómentes (vagy fordított áfás).

A startupok és szoftverértékesítők előszeretettel dobálóznak a hangzatos "99,5%-os pontosság" (Character-level accuracy) mérőszámával. Ez a mérőszám az üzleti életben teljesen értéktelen. Miért? Tegyük fel, hogy a magyar adószám ("12345678-2-42") 10 karakter hosszú. Ha a rendszer a 10 karakterből csak egyetlen egyet téveszt el, az matematikai szinten 90%-os karakterpontosság. De üzleti szinten az a dokumentum (és az a tranzakció) 100%-ban kuka, hibás rekord. A valódi, menedzsment által követendő KPI-ok a következők:

• Field-level Accuracy (Mezőszintű pontosság): Hány konkrét, teljes adatmezőt (nem betűt) talált el a gép 100%-osan pontosan? (Pl. a teljes bruttó összeget, vagy a teljes bankszámlaszámot).
• Critical Field Error Rate (Kritikus mező hibaarány): Hányszor tévesztett el olyan üzletkritikus mezőt, mint az adószám vagy az IBAN? (Ideális esetben az üzleti validációnak ezeket fel kell fognia, mielőtt beíródnának).
• STP Rate (Straight Through Processing - Zökkenőmentes Átfutás): A legfontosabb "zsebben maradó" szám. 100 darab beérkezett pdf számlából végül ténylegesen hány darab futott át a rendszeren az ERP-ig úgy, hogy egyetlen embernek sem kellett rápillantania? Egy jól tanított rendszernél ez 80-92% között mozog. A maradék 8-20%-ot a (koszos, olvashatatlan) kivételkezelés teszi ki.
• Manual Review Rate & Time (Kézi ellenőrzés ideje): A hibásan felismert (Exception) dokumentumoknál mennyi idő alatt tudja a kolléga manuálisan kijavítani a felületen a hibát? Ezt is másodpercre mérni kell az operációs hatékonyság (OpEx) számításához.

Bár a cikk és a feladatok (illetve a Google keresések) zöme arra irányul, hogy "hogyan tegyük Excelbe a PDF-et", a valódi nagyvállalati automatizáció célja szinte mindig az, hogy az adat végső soron a könyvelőprogramba (ERP) vagy a CRM-be (Salesforce) kerüljön.

Ilyenkor az Excel gyakran csak egy felesleges, sérülékeny köztes állomás (Staging Layer). Bár a rendszer tud CSV-t vagy XLSX-et generálni, ha van rá lehetőség (és az ERP biztosít nyílt felületeket), mindenképpen érdemes az adatokat (a validáció után) közvetlenül, API-n (REST, SOAP) vagy dedikált adatbázis-kapcsolaton (SQL) keresztül, "egyenesen a csövön" betolni az üzleti szoftverbe, teljesen kihagyva az Excelt a láncból.

A vállalati dokumentumok (főleg HR papírok, orvosi leletek, vagy bizalmas beszerzési szerződések) szigorúan védett személyes adatokat (PII) és üzleti titkokat tartalmaznak. Bár csábító egy egyszerű szkripttel beküldeni őket a ChatGPT publikus API-jára, ezt az információbiztonság azonnal (és jogosan) megvétózza. Ennek kezelése 3 pilléren nyugszik:

• Titkosított Tranzit és Tárolás (Storage): A beérkező PDF-eket és a feldolgozás közti átmeneti képfájlokat végpontok közötti (E2E) titkosítással kell továbbítani.
• Privát, Elzárt Modellek: Érzékeny adatok (Különleges kategóriájú GDPR adatok) esetén a publikus cloud modellek helyett garantált "Zero Data Retention" Enterprise végpontokat (Pl. Microsoft Azure OpenAI), vagy ami még jobb: dedikált virtuális hálózaton (VPC), esetleg lokális (On-Premise) szerveren futó nyílt forráskódú LLM-eket (pl. LLaMA 3, Mistral) kell beüzemelni. Itt senki nem tréningezi a modellt az Ön adataival.
• Szigorú Adatmegőrzés (Retention Policy): Az automatizált architektúrának biztosítania kell, hogy miután az adat beért az ERP-be, a közvetítő szerveren lévő ideiglenes PDF cache (a fájlok) X napon belül (pl. 48 óra) visszavonhatatlanul törlődjenek a diskről.

Összefoglalásként, mielőtt IT projektbe kezd, határozza meg, milyen technológia illik a dokumentumaihoz: