PDF bankszámlakivonat Excelbe könyveléshez

PDF bankszámlakivonatból akkor készül könyvelésre kész Excel, ha minden tétel mellett túléli a konverziót a könyvelési nap, az értéknap, a partner név és bankszámlaszám, a közlemény, a terhelés és jóváírás (vagy előjeles összeg), valamint a kivonat nyitó és záró egyenlege. Ez a hét mező adja a könyvelőprogramba betölthető sor minimumát; ha bármelyik elveszik vagy összeolvad egy másik mezővel, a havi zárás során utólag kell visszamenni a forrás PDF-re, és a hiányzó adatot kézzel kiegészíteni.

A munkafolyamat ezzel együtt két útvonalból áll. Ha a bank kínál strukturált XLS, CSV, XML vagy STM exportot — például OTP STM/CSV vagy K&H Electra STA —, érdemes először abból dolgozni: a könyvelési nap és az értéknap már szétválasztva érkezik, a partneradat tisztán marad, és a díjak sem ragadnak rá a tranzakció értékére. Ha csak PDF vagy szkennelt kivonat áll rendelkezésre — mert az ügyfél így küldi, mert a bankhasználata vegyes, vagy mert historikus kivonatról van szó —, AI-alapú adatkinyerés állít elő egységes oszlopstruktúrájú Excelt több bank kivonataiból egyetlen kötegben. Ez a cikk a PDF bankszámlakivonat Excelbe könyveléshez kérdést abból a könyvelői szögből veszi fel, ahol a vegyes ügyfélkör miatt a bank natív exportja önmagában nem mindig elég, és a fallback útvonalat a bevett "kérje le strukturáltan" tanács nem fedi le.

A bankszámlakivonat mezői, amelyeket a könyvelésnek meg kell őriznie

A bankszámlakivonatból könyvelésbe kerülő minden tétel egy bizonylat a főkönyvben, és ennek a bizonylatnak konkrét mezőkészlete van. Ha a konverzió valamelyik mezőt elveszti, kicsonkolja vagy egy másikba olvasztja, az import után a sor vagy egyáltalán nem köthető a megfelelő számlához és szerződéshez, vagy kézi rendezésre kerül — ami a havi zárásban a legdrágább munka.

Az alábbi mezők azok, amelyeket a végleges Excelnek mindenképp tartalmaznia kell, függetlenül attól, hogy a forrás strukturált bank-export vagy PDF-ből kinyert adat:

• Könyvelési nap és értéknap külön oszlopként. A könyvelési nap (a banki feldolgozás napja) vezeti a főkönyvi tételt és az időszaki riportokat; az értéknap (a kamatszámítás napja) a kamat- és árfolyam-elszámolásokhoz kell. Ha a konverzió csak egyetlen "Dátum" oszlopot ad, a könyvelőprogramban sem a kamatszámítás, sem az időszak-szűrő nem fog megfelelően működni — ezért a "bankkivonat Excel könyvelési nap értéknap" probléma az egyik leggyakoribb csapda PDF-konverzió után.
• Partner név és bankszámlaszám. A partner mezőben a forint IBAN (HU típusú, 28 karakter) és a régi belföldi 3x8 számformátum egyaránt megjelenhet, akár ugyanazon a kivonaton; a kivonat-konverziónak mindkettőt épségben át kell vinnie, és nem szabad összemosnia őket egyetlen szöveges mezőbe.
• Közlemény. A "bankkivonat partner közlemény Excel" igény azért visszatérő keresés, mert ez az a mező, amelyik a tételt egy konkrét számlához vagy szerződéshez köti — gyakran tartalmaz INV-2024-… vagy SZ-… típusú rendszer-azonosítót. Ha a PDF-konverter 30-40 karakter után csonkolja, az auto-egyeztetés a könyvelőprogram és a számlaadatbázis között elveszik, és a sor a "kézi rendezés" oszlopba kerül.
• Terhelés és jóváírás. Vagy két külön oszlopban (terhelés / jóváírás), vagy egy előjeles összegben kell látszania — egyik forma sem rosszabb a másiknál, de a könyvelőprogram egyik konvenciót várja, és a kettőt nem szabad keverni egy fájlon belül.
• Deviza és összeg. A devizanem és az eredeti deviza-összeg minden tételhez tartozzon, akkor is, ha forint főszámla devizás díjsoráról van szó.
• Kivonat nyitó és záró egyenlege. Per kivonat (nem per tétel) — ez az a két szám, amivel a következő kivonat nyitó egyenlege egyezni fog, és amivel a havi záró egyenleg a főkönyvi banki egyenleggel összevethető.
• Kivonat sorszáma és időszaka. Az adott kivonat azonosító száma (pl. 2026/3) és időszaka (kezdő- és zárónap) ahhoz kell, hogy egy későbbi audit-keresésben — például NAV ellenőrzés alatt — egy adott tétel egyértelműen visszakereshető legyen a forrás kivonatra.
• Díjak külön sorként. A bankköltséget, kezelési díjat, SWIFT díjat soha ne olvassza össze a tranzakció értékével: külön soron kerül a megfelelő ráfordítás-számlára, és csak így illeszkedik a számviteli politikához.

Az, hogy ezek a mezők miért ennyire súlyosak, jobban értelmezhető a magyar pénzforgalom volumenével: az MNB pénzforgalmi sajtóközleménye az elektronikus fizetések 2024-es növekedéséről szerint 2024-ben Magyarországon több mint 2,5 milliárd elektronikus fizetés teljesült, és az elektronikus tranzakciók száma több mint 200 millióval nőtt az előző évhez képest. Egy magyar Kft. havi bankkivonatában ez tételszinten azt jelenti, hogy a partner, a közlemény és a könyvelési nap minősége nem stilisztikai kérdés — ez különbözteti meg az auto-egyeztethető tételeket azoktól, amelyeket a könyvelő egyenként kénytelen összerakni a számlaadatbázissal.

Strukturált export mint elsődleges választás: magyar bankok formátumai

Ha a bank elérhetővé tesz strukturált XLS, CSV, XML vagy STM exportot, érdemes a havi zárás első lépésévé tenni a letöltését: a könyvelési nap és az értéknap már szétválasztva érkezik, a partner és közlemény mezők eredeti formában maradnak, a díjak külön sorként jönnek, és a kivonat sorszáma is a fájlban van. Ez nem stílusbeli ajánlás — minden mező, amit a 2. szakasz mezőhierarchiája megkövetel, alapértelmezésben rendben van benne, és nincs szükség kinyerésre vagy utólagos rendezésre. A lentebbi gyors-referencia abban segít, hogy új ügyfél új bankjával találkozva tudja, hová kattintson és milyen formátumú fájlt fog kapni — bank-specifikus mély dokumentációért minden esetben a bank saját oldalára érdemes menni.

OTP Bank. Az OTP Direkt netbank több exportformátumot kínál: CSV, DAT, CTR, CAM és STM, amelyekből a CSV és STM a leggyakoribb a könyvelői gyakorlatban; a CSV közvetlenül megnyitható Excelben, az STM a klasszikus magyar számlavezető-formátum, amelyet a könyvelőprogramok importmoduljai többsége natívan ismer. Az OTP-vel dolgozó könyvelők számára a részletes lépésről lépésre folyamatot — beleértve a PDF-konverziós eseteket is — az OTP bankkivonat PDF Excelbe alakítás lépésről lépésre cikk dolgozza fel; itt csak gyors-referencia szinten foglalkozunk vele, hogy a multi-bank áttekintés ne dőljön át OTP-deep-dive irányba.

K&H Bank. A K&H web Electra rendszerében a kivonat STA és STM formátumokban tölthető le; a STA a hagyományos K&H számlatörténet-formátum, amely tételenként hozza a könyvelési és értéknapot, a partner és közlemény mezőket, a terhelést és jóváírást. A magyar könyvelőprogramok importmoduljai a STA-t és STM-et alapból kezelik, így K&H számláról a "bankszámlakivonat CSV könyvelőprogramba" kérdésre rendszerint nem is CSV, hanem STA/STM a praktikus válasz.

Erste Bank. Az Erste NetBankjának kivonat-letöltési felületén PDF mellett strukturált export is választható: Excel és CSV a két legtöbb könyvelőprogrammal kompatibilis változat, és az exportban a könyvelési nap, értéknap, partner-számlaszám, partnernév és közlemény külön oszlopokban érkezik.

Raiffeisen Bank. A Raiffeisen DirektNet és üzleti netbank-felületein a havi és köztes kivonatok többféle formátumban tölthetők le; a CSV és Excel változat tartalmazza a 2. szakaszban felsorolt mezők többségét, és általában megjelenik benne a tranzakció rendszer-azonosítója is, ami a későbbi audit-keresést gyorsítja.

MBH Bank (volt Budapest Bank/MKB). Az összevont MBH netbank-felületén az exportformátum nagyrészt megőrizte mindkét jogelőd bank korábbi struktúráját — érdemes az adott számla típusától függően ellenőrizni, hogy a CSV/Excel oszlopkészlete tartalmazza-e a könyvelési és értéknapot külön mezőként, mert egyes régebbi számlatípusoknál egyetlen "Dátum" mezőként jelenik meg. Ilyenkor érdemes az XML-export vagy az STM lehetőséget keresni a netbank kivonat-letöltési oldalán.

CIB Bank. A CIB Internet Bank kivonat-export funkciója Excel és CSV formátumot kínál; az oszlopkészlet a könyvelői mezőhierarchiához közel áll, és a multi-currency számlák esetén a deviza külön oszlopként szerepel.

UniCredit. Az UniCredit Business Net felületén a kivonat XML, CSV és Excel formátumban exportálható; a CSV/XML a strukturált import szempontjából a legkonzisztensebb, a könyvelési nap, értéknap, partner-számlaszám, közlemény és összeg külön oszlopokba kerül.

A bank-specifikus formátumok közötti választás — különösen, ha az olvasó egyszerre több módszer (strukturált export, PDF-konverter, AI-alapú adatkinyerés, kézi rögzítés, banki kapcsolat) közül szeretne tájékozódni — nem ennek a cikknek a tárgya; a tágabb módszertani áttekintést a bank statement PDF to Excel: öt módszer összehasonlítása cikk dolgozza fel.

---

Amikor csak PDF van: adatkinyerés mint legitim fallback útvonal

A magyar könyvelőszoftver-vendor-dokumentációk konszenzusa egyhangú: ne a PDF-et importáld, kérj a banktól strukturált XLS, CSV vagy XML exportot. Ez első válasznak helyes — egyszerűbb, gyorsabb, és a 2. szakasz mezőhierarchiája alapból jobban megmarad benne. A könyvelői praxisban azonban három tipikus eset rendszeresen marad meg ezen a tanácson kívül, és ezek mindegyike a havi zárás során rendszeresen visszatér:

• Az ügyfél csak PDF-et küld. Ez a könyvelőiroda gyakorlatában a leggyakoribb eset, és nem szakmai vita kérdése: az ügyfél a netbankjából azt tölti le és küldi át, ami először keze ügyébe esik, és ez tipikusan a PDF kivonat. A "kérje le strukturáltan" tanácsot tizenkét ügyfélnek havonta elismételni nem reális — a bejövő PDF-eknek munkafolyamat kell, nem elkerülés.
• Historikus kivonatok. Több éves visszamenőleges könyvelés, audit, vagy átvett ügyfélkönyvelés esetén az archív kivonatok gyakran csak PDF-ben vannak meg; a bank netbankja sok esetben csak korlátozott időtávra ad strukturált exportot, a régebbi időszakra már csak a PDF-archív áll rendelkezésre.
• Vegyes bankú ügyfél. Egy közepes Kft.-nek könnyen lehet párhuzamosan OTP-, K&H- és Raiffeisen-számlája, és három bank exportformátumát egyetlen import előtti egységes Excellé összeszerkeszteni — eltérő oszlopnevekkel, eltérő dátumformátumokkal, eltérő partner-mező-konvenciókkal — nagyobb munka, mint az összes kivonatot uniform PDF-folyamaton átfuttatni.

A PDF-fallback útvonal kulcsa az, hogy a "PDF bankkivonat OCR könyveléshez" intent valójában nem az, ami elsőre tűnik. A klasszikus OCR pixelképből szöveget nyer ki — szót, számot, sorokat —, de nem garantál mezőstruktúrát. A PDF-en a könyvelési nap, az értéknap, a partner-számlaszám, a közlemény és a terhelés/jóváírás egymás mellett áll oszlopokban, de az OCR kimenete leggyakrabban egy hosszú szöveg-blokk, amit utólag kell mezőkre szétválasztani — és ez a szétválasztás bankonként eltérő. A praktikus megoldás ezért nem nyers OCR, hanem a könyvelői mezőkre célzott AI-alapú adatkinyerés, ahol az olvasó természetes nyelvű prompttal megadja, milyen oszlopokat akar a kimenetben, és a kinyerő minden bank kivonatára azonos szerkezetet termel.

Egy olyan munkahéten, amikor tizenkét ügyfél kivonatát kell péntek estig könyvelésre kész Excelben látni, az AI-alapú bankszámlakivonat adatkinyerés Excelbe útvonal így néz ki a gyakorlatban: a könyvelő egyetlen kötegként feltölti az ügyfelek PDF kivonatait — közöttük van OTP, K&H, Raiffeisen és néhány MBH —, és egyszer írja meg a promptot, ami felsorolja a kívánt mezőket, például "Könyvelési nap, Értéknap, Partner név, Partner számlaszám, Közlemény, Terhelés, Jóváírás, Deviza, Egyenleg". A kimenet egy egységes oszlopstruktúrájú Excel, amelyben minden tétel mellett ott a forrás-fájl neve és az oldalszám is, ahonnan az adat származik — így ha egy közlemény gyanúsnak tűnik, vagy egy partner-számlaszámot ellenőrizni kell, egy kattintással visszanyitható az eredeti PDF megfelelő oldala. Ahol az ügyfél bankja állandó, a prompt mentett változatként újrahasznosítható: a következő havi zárásnál ugyanaz a folyamat fut, ugyanazokkal az oszlopokkal.

Ugyanez a PDF→Excel logika nem korlátozódik bankszámlakivonatra: a magyar könyvelési gyakorlatban a bérjegyzék PDF Excelbe konvertálás éves összesítőhöz cikk ugyanazt a mintázatot mutatja be munkavállalói bérjegyzékre, és aki a bankkivonat-folyamatot már egyszer beállította, az minimális módosítással ezt a folyamatot is tudja futtatni. Az adatkinyerő nem magyar könyvelőprogram, nem közvetlen banki kapcsolat, és nem ASP-rendszer — kizárólag dokumentum-szintű adatkinyerő, amely Excel/CSV/JSON kimenetet ad. Feladata annyi, hogy egy adott munkahéten a vegyes ügyfélkör vegyes formátumú PDF kivonataiból egyetlen, a könyvelőprogramba importálható Excelt készít — onnantól a tételek a megszokott havi zárás útján haladnak tovább.

Devizás bankszámlakivonatok és MNB középárfolyam kezelése

A devizás kivonat akkor lesz tisztán könyvelhető, ha minden tétel mellett két érték áll: az eredeti deviza-összeg a devizanemmel, és a forintosított érték — utóbbinál a hivatkozási alap az MNB középárfolyam a könyvelési napra (vagy az adott jogszabály, illetve a számviteli politika által előírt napra), nem a bank saját konverziós árfolyama. Ha a kivonatból csak egyetlen összeg-oszlop kerül az Excelbe, akár a deviza, akár a forint érték, a forintosítás utólag csak árfolyamtörténet alapján rekonstruálható — és ez egy nagyobb ügyfél éves zárásánál tételenként sok perc.

A strukturált bank-exportokban a deviza és az eredeti összeg többnyire külön oszlop, és gyakran szerepel egy árfolyam-mező is — a bank által alkalmazott konverziós ráta —, amit azonban a könyvelő nem közvetlenül használ a főkönyvi forintosításhoz. Az MNB-középárfolyam alkalmazása ezután a könyvelő dolga, akár excel-képletként a kimenet mellé téve, akár a könyvelőprogram saját árfolyamtáblájából. PDF vagy szkennelt kivonatból ugyanezt az oszlopkészletet az adatkinyerő prompt írhatja elő közvetlenül: "Deviza, Eredeti összeg, MNB árfolyam (könyvelési nap), HUF érték" — így minden tétel mellett ott marad mind az eredeti, mind a forintosított érték, és az ellenőrzéshez a bizonylat egyértelmű.

A devizás bankszámlakivonat Excel-formában jellemzően három alesetben jelenik meg, és mindegyik más kezelést igényel:

• Tisztán devizás számla (csak EUR vagy csak USD). Itt minden tétel deviza-érték, a HUF oszlop teljes egészében az alkalmazott árfolyam alapján számolódik. A kivonat nyitó és záró egyenlege is devizában érkezik, és a forintosított záró egyenleg a fordulónapra alkalmazott középárfolyammal képződik.
• HUF főszámla devizás tétellel. Tipikusan SWIFT díj, devizás kártyatranzakció, vagy nemzetközi átutalás-jutalék. Ezeknél a sor összege HUF-ban szerepel a kivonaton — a bank már átszámolta —, de a könyvelői szempontból érdemes a kinyerés során az eredeti deviza-értéket és a bank által alkalmazott árfolyamot is megőrizni, mert az audit során az átszámítás levezetése jól jön.
• Multi-currency összevont kivonat. Egyes bankok egy fájlban hozzák több devizanem tételeit — a kinyerő Excelnek ezt devizanem-oszlopra építve kell rendeznie, és a könyvelőprogram importja előtt érdemes devizanemenként szétválasztani, mert a magyar könyvelőprogramok importmoduljai nagy részben egy devizanemű importot várnak egyszerre.

Hogy melyik árfolyamot milyen napra alkalmazza a könyvelő — havi átlag, könyvelési napi középárfolyam, fordulónapi árfolyam, választott számviteli politika szerinti változat — szakmai döntés és a számviteli politika kérdése, nem a kivonat-konverzióé. A kivonat-konverzió felelőssége csak annyi, hogy a forintosításhoz szükséges összes input (eredeti összeg, devizanem, könyvelési nap) sértetlenül megmaradjon az Excelben — onnan a számviteli politika dolga, hogy a HUF érték milyen árfolyammal képződjön.

Import a magyar könyvelőprogramokba: Novitax, RLB, Kulcs-Soft és társaik

A magyar könyvelőszoftver-piac három legismertebb bankkivonat-import modulja — a Novitax, az RLB és a Kulcs-Soft — gyakorlatilag ugyanazt a mezőkészletet várja, amit a 2. szakasz mezőhierarchiája meghatározott: könyvelési nap, értéknap, terhelés és jóváírás (vagy előjeles összeg), partnernév és partner-számlaszám, közlemény, devizanem és összeg, valamint a kivonat nyitó és záró egyenlege. A "bankszámlakivonat import Novitax RLB Kulcs-Soft" probléma ezen a szinten ezért nem mező-újragondolás, hanem leképezés: ha az előző szakaszokban előállított Excel oszlopai megegyeznek ezzel a listával, az import-modul tipikusan minimális mezőleképezéssel — vagy egyszerűen oszlopnév-átnevezéssel — befogadja.

A részletek azonban program-specifikusak, és érdemes az adott vendor saját dokumentációját megnézni a végleges leképezéshez. Ezek a program-szintű részletek tipikusan a következőket szabályozzák: az oszlopok pontos sorrendje (egyes importmodulok kötik az oszlopokat, mások csak a fejléceket nézik), kötelező-e az IBAN formátum a régi 3x8 belföldi számlaszám helyett, hogyan kezeli az import a díj sorokat (külön sorként vagy a tranzakció kiegészítő mezőjeként), és milyen formában várja a dátumot (YYYY-MM-DD vagy a magyar napiformátum). Ezeket nem érdemes itt replikálni — a Novitax tudástár, az RLB dokumentáció és a Kulcs-Soft tudásbázis pontosabb, naprakészebb forrás, és a kivonat-konverzió szempontjából a lényegi kérdés csak az, hogy az Excelben az oszlopokat lehessen a vendor által várt nevekre átnevezni anélkül, hogy maguk az adatok változnának.

A többi magyar könyvelőszoftver — Hessyn Kettős, Szamvitelirendszer, IMA ERP, Makrodigit és társaik — bankkivonat-import moduljai is a fenti mező-mintázatot követik. Eltérések tipikusan a kötelező vs. opcionális mezők szintjén jelennek meg (egyik program kéri a kivonat sorszámát, másik nem), és ezek általában az adott vendor importmodul-dokumentációjából egy vagy két oldalon kiolvashatók. A munka tehát, ami a könyvelői Excelt elválasztja a könyvelőprogram-import bemenetétől, a magyar piacon szinte minden esetben oszlopnév-szintű, nem szerkezeti — feltéve, hogy a 2. szakasz mezőhierarchiája a kinyerés során sértetlenül megmaradt.

Ellenőrzési lista import előtt: amit minden könyvelőnek érdemes átfutnia

Mielőtt a kivonat-Excel a könyvelőprogram import-modulján átfut, érdemes egy gyors ellenőrzést megfuttatni rajta — akár a bank strukturált exportjából, akár PDF-alapú adatkinyerésből származik. A gyakorlati hibák jellegzetesek és pár perc alatt kiszúrhatók, miközben az import után ugyanezek a hibák a főkönyvbe már bekerülve órás javítómunkát jelentenek.

• A záró egyenleg illeszkedik-e a következő kivonat nyitó egyenlegéhez. Ez a legegyszerűbb ellenőrzési pont: ha a 2026/3 kivonat záró egyenlege nem azonos a 2026/4 kivonat nyitóegyenlegével, valahol elveszett egy tétel a konverzió során, és érdemes azonnal visszanézni, mielőtt az import megtörténik.
• A díj sorok külön soron vannak-e. Bankköltség, kezelési díj, SWIFT díj, kártya-éves díj — egyik sem szabad, hogy beolvadjon egy tranzakció értékébe; ha a kinyerésben így jelenik meg, a könyvelőprogram a megfelelő ráfordítás-számlára nem fogja külön kontírozni.
• A közlemény nincs-e csonkolva. Sok PDF-konverter 30-40 karakter után elvágja a közleményt, és pont az INV-2024-… típusú azonosító esik le a végéről — ami épp az auto-egyeztetést tenné lehetővé a számlaadatbázissal. A leghosszabb közleményt érdemes mintaként kiválasztani és a forrás PDF-fel összevetni.
• A partner név és számlaszám ott van-e, ahol a PDF-en is rajta volt. Ha a kivonaton a kedvezményezett vagy megbízó IBAN-ja és cégneve egyaránt szerepelt, mindkettőnek meg kell lennie a kinyerés után is — ha csak az egyik jelenik meg, az import a hiányzó mezőt üresen hagyja, és kézi javítás lesz belőle.
• A könyvelési nap és értéknap szét van-e választva. Külön oszlopként, a 2. szakasz hierarchiája szerint — ha egyetlen "Dátum" oszlop maradt, az időszaki riportok és a kamatszámítás már nem fog rendben futni a könyvelőprogramban.
• Devizás tételeknél megvan-e az eredeti összeg és a devizanem. A forintosítás később bármikor rekonstruálható, ha az eredeti deviza-összeg, a devizanem és a könyvelési nap megvan; ha csak a HUF-érték maradt, az audit során az átszámítás levezetését nem lehet visszaadni.
• A kivonat sorszáma és időszaka hozzá van-e rendelve a tételekhez. Egy későbbi NAV ellenőrzés vagy belső audit során egy tétel forrásának megtalálása sokkal gyorsabb, ha minden tétel mellett ott áll, melyik sorszámú és időszakú kivonatból származik.

Ehhez a listához egy magyar audit-szempont kapcsolódik: a könyvelési bizonylat-megőrzési és audit-keresési gyakorlat — különösen NAV ellenőrzés, vagy bejövő számlák és bankkivonat tételeinek számlaegyezés-vizsgálata során — sokkal gyorsabb, ha a forrás-fájl és oldalszám hivatkozás már magában az Excelben szerepel, nem csak az archív könyvtárban a PDF mellett. A bankkivonat közlemény mezője gyakran köti vissza a könyvelést egy konkrét, számlaszám szerinti bejövő vagy kimenő számlához, és a magyar Online Számla kötelezettségek áttekintése cikk azt a szomszédos szabályozási keretet foglalja össze, amely meghatározza, milyen formában áll rendelkezésre a NAV-felé jelentett számlaadatkör — ez az a referenciaadatkör, amivel a bankkivonat tételeinek közlemény mezője összevethető.