OTP bankkivonat PDF Excelbe konvertálás könyveléshez

Az OTP-s PDF bankszámlakivonatból úgy készíthetsz könyvelésre alkalmas Excel-táblázatot, hogy a tételeket dátum, könyvelési nap, értéknap, terhelés, jóváírás, partner, közlemény és egyenleg oszlopokba rendezed, majd az összegeket a kivonat fejlécében szereplő nyitó- és záró egyenleggel ellenőrzöd. A magyar számviteli gyakorlat a könyvelési napot tekinti a főkönyvi rögzítés alapjául; az értéknap a kamatszámításnál és a devizás tételeknél releváns. Ez a két állítás az egész munkafolyamat csontváza — minden további lépés erre épül.

Ez az útmutató a PDF-bemenetről szól. Ha az OTP Direkt vagy az OTPdirekt vállalati felületedről le tudsz tölteni STM, CSV vagy XML exportot, arra a végén külön szakaszt szentelünk; a fő ívet annak a könyvelőnek építettük, aki PDF-et tart a kezében — mert az ügyfél így küldte e-mailben, mert a saját banki felületéről PDF-ben mentette, vagy mert a régebbi típusú számlához nincs strukturált export. Ne legyen most fájlformátum-vita; te már döntöttél, neked PDF-ed van.

Másodkézből kapni a kivonatot egészen szokványos. A magyar Kft- és Bt-ügyfelek többsége a saját OTP Direkt felületéről PDF-ben menti le a havi kivonatot és úgy továbbítja a könyvelőnek, vagy a könyvelőiroda az ügyfél nevében már csak a megkapott PDF-ből dolgozik. Ennek a helyzetnek a megoldására készült az OTP bankkivonat PDF Excelbe konvertálás egész műfaja: nem versenyez a strukturált exporttal, hanem azt a részfeladatot oldja meg, amelyikre a strukturált export-utak nem alkalmasak.

A cikk végighalad a teljes munkafolyamaton: a PDF mezőitől az Excel-oszlopokig, a könyvelési nap és értéknap megkülönböztetéséig, a terhelés és jóváírás kétoszlopos szerkezetig, az OTP Direkt, OTP Smart, vállalati internetbank és szkennelt papír variánsok kezeléséig, a HUF- és devizaszámla különbségéig, valamint a havi 10–30 oldalas kivonat lapok közötti folytonosságának és záró egyenlegének ellenőrzéséig. A manuális tételezés helyett az automatizált bankkivonat-feldolgozás mesterséges intelligenciával közvetlenül a könyvelői oszlop-szerkezetbe rendezi az adatokat: a termék elsődleges bemenete pontosan a PDF és a szkennelt dokumentum, és a magyar mezőelnevezések — terhelés, jóváírás, könyvelési nap, értéknap, partner, közlemény — közvetlenül a kimenetbe kerülnek, anélkül hogy utólag át kellene címezni az oszlopokat.

---

A magyar OTP-s bankkivonat fő mezői és a könyvelői Excel-oszlopok

Egy magyar nyelvű OTP PDF kivonat tételes része a következő mezőket tartalmazza, jellemzően ebben a sorrendben: tranzakció dátuma, könyvelési nap, értéknap, partner (az ellenoldali számlatulajdonos neve és számlaszáma), közlemény (a tranzakcióhoz csatolt megjegyzés vagy hivatkozás), terhelés, jóváírás, könyvelt egyenleg a tétel után, devizaszámlán a deviza jelzése, és a tranzakció-azonosító. A kivonat fej- és lábléce ezen kívül a számlaszámot, a számlatulajdonos nevét, a kivonat időszakát és sorszámát, valamint a nyitó és záró egyenleget tartalmazza — ezek nem a tételsor részei.

A könyvelői felhasználáshoz ebből a következő Excel-séma adódik:

| Tranzakció dátuma | Könyvelési nap | Értéknap | Partner neve | Partner számlaszáma | Közlemény | Terhelés (HUF) | Jóváírás (HUF) | Egyenleg (HUF) | Deviza | Tranzakció-azonosító |

Ez a séma minden lényeges PDF-mezőt megtart, és minden oszlopnak van konkrét könyvelési szerepe: a két dátum-mező a főkönyvi rögzítéshez és a kamat- vagy árfolyam-szempontú ellenőrzéshez, a partner-mezők a kontírozás-felgyorsításhoz, a közlemény a tétel céljának azonosításához, a terhelés és jóváírás a forgalom irányának szétbontásához, az egyenleg a futó számla-állapot ellenőrzéséhez, a deviza-mező a HUF-számlán előforduló külföldi devizás kártyás vásárlások jelzéséhez, és a tranzakció-azonosító a banki rendszerben való visszakereséshez.

A fej- és lábléc tartalma — számlaszám, számlatulajdonos, kivonat időszaka, kivonat sorszáma, nyitó és záró egyenleg — soha ne kerüljön a tételsorok közé. Tedd egy külön kis blokkba az Excel tetején, vagy egy második munkalapra; ezekre a bizonylat-azonosításhoz szükséged lesz, de a tételsorba keverve elrontják a szűrőket és a kimutatásokat.

Egy tétel egy Excel-sornak felel meg. Ha egy közlemény-mező hosszú és a PDF-en több sort foglal el, tedd egyetlen cellába a soron belüli sortöréssel — az Excelben ezt az Alt + Enter adja —, ne új sorba; az új sor megtöri a tétel-egységet, és attól kezdve a SUM-képletek, a partner-szűrés és a pivot-tábla mind hibás eredményt ad. Ugyanez vonatkozik a többsoros partner-címre is.

Aki a magyar specifikum-réteg alatt az általános képet keresi a bankkivonat-konverzióhoz, annak az általános bankkivonat PDF-ből Excelbe konvertálás háttérismeretei ad kiinduló kontextust; az itt következő szakaszok ennek a magyar OTP-re szabott rétegét adják.

Könyvelési nap vagy értéknap: melyik kerüljön a főkönyvbe

A magyar OTP kivonat minden tételéhez két dátum tartozik. A könyvelési nap (más néven könyvelt nap) az a dátum, amikor a tranzakció a bank rendszerében a számlán megjelent és a számla-egyenleget módosította. Az értéknap az a dátum, amelyen a tranzakció pénzügyileg érvényes a kamatszámítás és a deviza-elszámolás szempontjából — a bank ehhez a dátumhoz köti azt, hogy melyik napi árfolyamon és melyik nap kamatállományával számol.

A magyar számviteli gyakorlat alapszabálya: a főkönyvi rögzítéshez a könyvelési nap a meghatározó. Ez tükrözi azt az időpontot, amikor a tranzakció a vállalat banki egyenlegét tényleges módon megváltoztatta — vagyis amikor a pénzmozgás könyvelési értelemben megtörtént.

Vannak azonban szabályos kivételek, ahol az értéknap számít:

• Kamatszámítás. A bank a követelt vagy fizetett kamatot az értéknap-állomány alapján számolja, így ha a könyvelő a kamat-elszámolást ellenőrzi vagy maga is utánaszámol, az értéknap az alap.
• Deviza-átváltás. Devizás tranzakciónál a HUF-érték a magyar számviteli gyakorlat szerint az értéknap-árfolyamon számítódik, nem a könyvelési nap árfolyamán. Ez a szabály főként a devizaszámla-tételeknél fontos, de érinti a HUF-számlán előforduló külföldi devizás kártyás vásárlást is.
• Év végi zárás. A fordulónap körül érdemes figyelni a függő tételekre — például egy december 31-i értéknappal, januári könyvelési nappal érkező utalásra. Hogy a tranzakció a tárgyévi vagy a következő évi rögzítésbe kerül, a vállalat számviteli politikájától függ; a két dátum különbsége önmagában jelzés, hogy az adott tételt külön át kell nézni.

Ezért az Excel-sémában mindig külön oszlopot kapjon a könyvelési nap és az értéknap — soha ne vond össze őket egyetlen Dátum oszlopba. A két érték együtt ad teljes képet, és az eltérő sorok azonnal kiszűrhetők.

Egy gyakorlati tipp az ismétlődő havi munkához: a legtöbb belföldi forintos tranzakciónál a két dátum azonos, és csak a hétvégén indított, devizás vagy a hét végén feldolgozott tételeknél tér el. Ha az adott ügyfélnél tudod, hogy az eltérés ritka, az Excelben egyetlen szűrővel — Könyvelési nap ≠ Értéknap — pillanatok alatt átnézheted azt a néhány sort, amelynél a különbség könyvelési döntést igényel. A többit gond nélkül a könyvelési nappal viheted a főkönyvbe. Ez az egyszerű szűrés csak akkor működik, ha az OTP bankkivonaton a könyvelési nap és az értéknap külön oszlopként marad meg — ez az egyik konkrét haszna a kétoszlopos sémának.

Terhelés és jóváírás: miért két külön Excel-oszlop

A magyar OTP PDF kivonaton minden tranzakció két külön összeg-oszlopban szerepel: terhelés (kimenő tétel — átutalás, kártyás vásárlás, banki díjak, beszedés) és jóváírás (bejövő tétel — ügyfél utalása, bér, kamat, visszafizetés). Egyetlen előjeles összeg-oszlop nincs, és nem véletlenül: ez a magyar számviteli hagyomány egyik azonosítójele, és a könyvelői munka logikája is erre épül.

Az Excel-sémában is hagyd meg ezt a kétoszlopos szerkezetet. A legfontosabb gyakorlati ok: szűrhetőség. Ha havi 200 tranzakciós kivonatból a 30 kimenő utalást szeretnéd átnézni, egyetlen kattintással szűröd a Terhelés oszlopra > 0 feltétellel — és kész. Ugyanez egyetlen előjeles összeg-oszlopnál < 0 szűrés lenne, ami logikailag kevésbé intuitív, és a könyvelői gyakorlatban könnyebben elnézhető. A terhelés és jóváírás külön oszlopa egyenesen tükrözi azt a mentális szétbontást, amellyel a könyvelő a kontírozást végzi.

A SUM-ellenőrzés is tisztább a kétoszlopos szerkezeten. Σ(Jóváírás) − Σ(Terhelés) egyetlen képlet, és a következő szakaszban a záró egyenleg verifikációhoz pontosan ezt használjuk fel — egy összeg-oszloppal három különálló SUM-ot kellene kezelni (összes pozitív, összes negatív, nettó), és a logikai hibák gyakoribbak.

Ha valamilyen későbbi felhasználáshoz mégis előjeles formátumra van szükség — például egy külföldi szoftverbe való importhoz, ahol az amount mező egyetlen, pozitív vagy negatív értéket vár —, egy új oszlopban a =Jóváírás-Terhelés képlet pillanatok alatt megadja az előjeles értéket. A kétoszlopos forrás ilyenkor egyoszloposra konvertálható; fordítva már nem, mert ha az eredeti adatok egyetlen előjeles oszlopban érkeznek, a forgalom irány-szerinti szétbontása csak feltételes képlettel állítható vissza, és minden devizás vagy korrekciós tételnél hibalehetőség.

Egy gyakorlati részlet a deviza-tranzakciókhoz. Ha HUF-számlán külföldi devizában történt egy kártyás vásárlás, a Terhelés oszlopban a HUF-ban átszámolt érték szerepel — nem az eredeti EUR vagy USD összeg —, és a Deviza oszlopban jelenik meg az eredeti devizanem és összeg, jellemzően EUR 25,00 formátumban. A kétoszlopos terhelés-jóváírás logika alapja végig a HUF-érték; az eredeti deviza tájékoztató jellegű mező, amelyet a könyvelő külön kezel. Ezt a megkülönböztetést tartsd meg a sémában, mert a HUF-alapú forint-szűrésekhez és kimutatásokhoz erre építesz.

---

OTP Direkt, OTP Smart, internetbank és papír kivonat ugyanazon a munkafolyamaton

Az OTP-s ügyfeleid négy fő forrásból fognak PDF kivonatot küldeni, és érdemes előre tudni, mi várható mindegyiktől:

• OTP Direkt — a lakossági netbank PDF kivonata. Tisztán olvasható szöveg, strukturált fejléccel, fix oszlop-elrendezéssel; ez a könyvelő szempontjából a legkönnyebb forrás.
• OTPdirekt vállalati felület — a Kft, Bt és más jogi személy ügyfelek számláihoz tartozó kivonat. Szerkezete az OTP Direkthez nagyon hasonló, de a fejléc a vállalati számlaszám-formátumot, a cégnevet és a céges azonosítókat hozza, és a kivonat egyértelműen vállalati bizonylatként jelöli magát.
• OTP Smart — a mobilalkalmazásból letöltött PDF kivonat. Szerkezete némileg eltér: a fejléc tömörebb, a tételsor sűrűbb, és a margók szűkebbek. A tartalmi mezők ugyanazok, csak a vizuális elrendezés más.
• Régi papíralapú vagy szkennelt / fotózott kivonat — az ügyfél által e-mailben továbbított, jellemzően egy szkennerrel vagy mobiltelefonnal digitalizált verzió. Itt számít a szkennelési minőség: ferde lapok, halvány nyomtatás, nem teljesen vízszintes orientáció mind előfordul.

A négy variáns közötti különbségek a kivonatolás lépésénél jelennek meg — ott számít, hogy a fejléc hova esik, milyen vastag a táblázat-vonal, hol kezdődik az első tétel —, de az Excel-séma mind a négyre stabilan ugyanaz marad. A Tranzakció dátuma | Könyvelési nap | Értéknap | Partner neve | Partner számlaszáma | Közlemény | Terhelés (HUF) | Jóváírás (HUF) | Egyenleg (HUF) | Deviza | Tranzakció-azonosító szerkezet az OTP Direkt és az OTP Smart kivonatára ugyanúgy alkalmazható, mint a vállalati internetbank vagy a papír-szkennelt verzióra. Egyetlen sablonnal mind a négy ügyfél-típust egységesen tudod kezelni.

A szkennelt és fotózott eset megérdemel egy külön mondatot. A szöveg-felismerés (OCR) pontossága itt számít, és a tipikus problémák ismerősek: a ferde lapok megdöntik a táblázat-illesztést, a halvány nyomtatás miatt egyes számjegyek (3 és 8, 0 és O, 1 és 7) összemoshatók, és a több oldalú szkennen néha a lap-sorrend felcserélődik. A legtisztább megoldás, ha az ügyfeledtől tudsz kérni digitálisan letöltött PDF-et a szkennelt másolat helyett — a digitális PDF-ben a szöveg már strukturált formában van, és a felismerési hibák lényegében elmaradnak. Ahol ez nem opció (régi kivonat, ügyvédi vagy felszámolási anyag), a szkennelt PDF is feldolgozható, csak a záró egyenleg ellenőrzésére fokozottan érdemes támaszkodni.

A hitelesített elektronikus kivonat státuszáról is érdemes szót ejteni a könyvelő szempontjából. Az OTP Bank hitelesített elektronikus kivonat tájékoztatója szerint az OTP Bank minősített elektronikus aláírással és időbélyegzővel ellátott elektronikus bankszámlakivonatokat bocsát ki ügyfelei részére, amelyek a könyvelésben a papíralapú kivonatokkal egyenértékű bizonylatként használhatók. Ez azt jelenti, hogy az OTP Direkt vagy az OTPdirekt vállalati felületen lekért, hitelesített elektronikus kivonat — ha az ügyfél le tudja tölteni — közvetlenül megfelelő bizonylat a könyvelési archívumba: nem kell papírra nyomtatni, és nem kell mellé kiegészítő hitelesítést keresni.

Praktikus következmény: ha a Kft- vagy Bt-ügyfeleidnek tudsz egy egyszerű mondatot átadni — kérjük a hitelesített elektronikus kivonatot az OTP Direktből vagy az OTPdirekt vállalati felületről, ne a mobilról fotózva —, akkor a havi munkafolyamat archiválhatóság és bizonylat-státusz szempontjából a lehető legtisztább. A PDF-ből Excelbe konvertálás a tételezést megadja, az eredeti hitelesített PDF pedig a bizonylat-státuszt; a kettő együtt teljes.

A termék mind a digitális, mind a szkennelt vagy fotózott PDF-bemenetet feldolgozza ugyanazon a felületen, ugyanazzal a prompttal — nincs külön sablon a szkennelt forrásra, és nincs külön beállítás az OTP Smart formátumra. Ez különösen a vegyes ügyfél-portfóliónál hasznos, ahol nem tudod előre, melyik csatornán érkezik az adott havi kivonat: a kép, a digitális PDF és a szkennelt verzió mind ugyanahhoz a kimenethez vezet.

HUF-számla, devizaszámla, partner és közlemény mezők használata

A HUF-számla és a devizaszámla különbsége az Excel-séma rugalmas pontján mutatkozik meg. HUF-számla kivonatán a Deviza oszlop a legtöbb sorban üres marad — minden tétel forintban szerepel, és csak az alkalmankénti külföldi devizás kártyás vásárlásnál tölti ki az AI vagy a kézi kivonatoló az eredeti devizanemet és összeget (EUR 25,00, USD 38,40, GBP 12,75). A tranzakció HUF-értéke a Terhelés vagy Jóváírás oszlopban szerepel, a Deviza mező csak tájékoztató.

Devizaszámla kivonatán minden sornak van deviza-mezője, és gyakran árfolyam-mezője is. Itt a tranzakciók a számla devizájában (EUR, USD, GBP, CHF) szerepelnek, és a HUF-konverzió a magyar számviteli zárás szempontjából külön kalkuláció — a könyvelő az értéknapi árfolyamot használja a forint-érték kiszámításához. Devizaszámlánál érdemes a sémát kibővíteni: egy Deviza oszlop a devizanemnek, egy Árfolyam oszlop a használt értéknap-árfolyamnak, és egy HUF-érték oszlop a számolt forint-értéknek. Ez a három mező együtt adja a teljes nyilvántartást, és a havi vagy év végi átértékelési feladathoz is ezekre az oszlopokra építesz.

Térjünk át a partner és közlemény mezőkre — itt van a könyvelői munka egyik legnagyobb hatékonyság-növelő pontja. A partner-mező az ellenoldali számlatulajdonos neve és számlaszáma; ezekre az adatokra szűrve azonnal kiemelhető minden visszatérő ügyfél, szállító, vagy díjmegoldó (havi bérleti díj, internet-előfizetés, könyvelési díj, biztosítás). Egyszer kontírozod a havi villanyszámla átutalását, aztán a következő hónapban Excel-szűrővel egyetlen kattintással felidézed a kontírt — nem kell minden hónapban újragondolni a tétel besorolását.

A közlemény mező az adott tranzakcióhoz csatolt megjegyzést, hivatkozást vagy számla-azonosítót tartalmazza, és a kontírozási döntéshez gyakran ez adja a kulcs-információt. Egy Számla 2026/0457 típusú közlemény azonnal megmondja, melyik beérkező számlához tartozik a fizetés; egy Bér 2026 április egyértelművé teszi, hogy bér-kifizetésről van szó és melyik időszakhoz. A partner és a közlemény oszlopok együtt teszik a kontírozást újrahasználhatóvá hónapról hónapra — a havi munka ismétlődő részét egy szűrő és egy másolás-beillesztés lerövidíti.

A közlemény mezőt egészben tartsd meg az Excelben, még akkor is, ha hosszú. Részleges kivonás veszteséget jelent — pont az a hosszú közlemény fog egyszer eldönteni egy kontírozási vitát, amelyiket „túl hosszúnak” ítéltél és levágtál. A korábban már említett soron belüli sortörés (Alt + Enter) egyetlen cellán belül kezeli a többsoros közleményeket; nem kell sem kihagyni, sem új sorba törni.

Egy gyakorlati záró tipp az ismétlődő havi munkához: a kivonat feldolgozása után érdemes egy egyszerű pivot-táblát készíteni Partner neve szerint csoportosítva, az értékben pedig a Terhelés és Jóváírás SUM-jával. Egy oldalon látszik, hogy az adott hónapban melyik szállítónak mennyit fizettél, és melyik ügyféltől mennyit kaptál; a havi-zárás ellenőrző kör 5–10 perccé rövidül, és a szokatlan tételek (kétszeresen utalt összeg, hiányzó havi befizetés) azonnal feltűnnek.

---

Lapok közötti tétel-folytonosság és a záró egyenleg ellenőrzése

Egy magyar OTP havi kivonat sokszor 10–30 oldalas, és a tételek a PDF lapjai között folyamatos sorozatot alkotnak. A PDF-ből Excelbe konvertálás leggyakoribb hibái pontosan ezekből a lap-határokból fakadnak: kimarad egy tétel a lap-váltás peremén, a fej- vagy lábléc tartalma (lapszám, kivonat-azonosító, OTP-logó alatti felirat) tévesen tételsorként kerül a táblázatba, vagy egy hosszabb közlemény-mező kettéreped a két oldal között és csak a fele kerül át. Ezeket a hibákat egy kétperces ellenőrzéssel azonnal észreveheted — és nélküle könnyen átcsúsznak a havi-zárásig.

A záró egyenleg verifikáció alapképlete egyszerű:

nyitó egyenleg + Σ(Jóváírás) − Σ(Terhelés) = záró egyenleg

A nyitó és záró egyenleg az OTP havi kivonat tételesen Excelbe konvertált verziójában nem a tételsorok között van — a kivonat fejlécében vagy lábjegyzetében szerepel, és a séma elején tárolt fej-blokkból olvasható ki. Az Excelben a SUM képlet egyetlen cella; az eredmény eltérése a kivonatban szereplő záró egyenlegtől azonnal megmondja, hogy van-e hibásan kezelt tétel.

Egy konkrét számszerű minta: tegyük fel, hogy a kivonat fejlécében a nyitó egyenleg 1 245 600 HUF, a záró egyenleg 1 387 240 HUF. Az Excelben Σ(Jóváírás) = 950 000 HUF, Σ(Terhelés) = 808 360 HUF. A különbség 141 640 HUF; nyitó + különbség = 1 245 600 + 141 640 = 1 387 240 HUF — egyezik a kivonatban szereplő záró egyenleggel, a tételek hiánytalanok. Ha viszont a számolt záró egyenleg 1 385 240 HUF lenne, az eltérés 2 000 HUF — ez vagy egy hiányzó 2 000 HUF-os jóváírás, vagy egy tévesen duplikált 2 000 HUF-os terhelés. Az eltérés pontos forintösszege gyakran rögtön megmondja, melyik tételt érdemes keresni.

Második, független ellenőrzés a tranzakció-szám egyezés. Az OTP kivonat fejlécében vagy lábjegyzetében szerepel az adott időszakra vonatkozó tranzakció-szám (Tranzakciók száma: 247). Az Excelben a =COUNTA(A:A)-1 képlet — ahol az A oszlop a Tranzakció dátuma fejléc oszlopa, és a -1 a fejléc-sor levonása — megmondja, hány tételsor van. Ha a két szám megegyezik, a tételek hiánytalanok. Az összeg-ellenőrzés és a darabszám-ellenőrzés együtt zárja ki a leggyakoribb hibatípusokat: az összeg-ellenőrzés a forintban kifejezhető hiányt fogja, a darabszám-ellenőrzés pedig azt is, ha véletlenül egy nullás tétel maradt ki vagy duplikálódott (amit az összeg-ellenőrzés nem mutat).

A lapok közötti folytonossághoz adok egy kiegészítő szemrevételezési lépést. A feldolgozás után rendezd a tételeket Tranzakció dátuma szerint, és nézd át, van-e olyan dátum-ugrás, amelyik nem indokolt. Ha az ügyfél számlája aktív és minden hétköznap van forgalom, egy hirtelen 3 napos szakadás a hét közepén gyanús — visszanéz a forrás-PDF megfelelő oldalára, és egy pillanat alatt kiderül, hogy egy egész lap kimaradt-e a kivonatolásból. Ez a szemrevételezés nem helyettesíti az egyenleg-ellenőrzést, de a hiányzó-blokk típusú hibákat (több egymást követő tétel együtt elveszik) gyorsan felismeri.

A fej- és lábléc-zaj hibája is egyszerűen kiszűrhető. Az Excelben szűrj olyan sorokra, ahol a Terhelés és a Jóváírás oszlop is üres — ezek tipikusan fej- vagy lábléc-tartalomból átkerült sorok (lapszám, OTP-logó alatti szöveg, kivonat-azonosító részlet), és törölhetők. Egy valódi tétel sosem üres mindkét összeg-oszlopban; ha igen, akkor zaj.

A termék a több oldalas PDF-eket egyetlen folyamatos tétel-listaként kezeli, és a fej- vagy lábléc-tartalmat automatikusan kiszűri — egy 30 oldalas havi kivonat ugyanazzal a prompttal és ugyanúgy egy lépésben dolgozható fel, mint egy 2 oldalas. A fenti záró egyenleg ellenőrzést a generált Excelben végezheted el; a SUM-képlet és a fejléc-számok összehasonlítása így marad a végső validáció, akkor is, ha a kivonatolás automatizált.

---

Mikor érdemes a STM-, CSV- vagy XML-utat választani, és hogyan tedd ismétlődővé a havi munkát

Egyszer ki kell mondani őszintén: ha az ügyfeled hozzáfér az OTP Direkt vagy az OTPdirekt vállalati felülethez, és tud STM (Electra szöveges), CSV vagy XML formátumban exportot lekérni, akkor az a strukturált export közvetlenebb és hibatűrőbb forrás, mint a PDF. A magyar piacon erre az útra több bevett szoftver épült (ExcelGuru Bankkonvertáló, Novitax, Kulcs-Soft), és ha a könyvelőirodában rendszeres ügyfeled van OTP Direkt-hozzáféréssel, érdemes ezeket az utakat is megnézni — különösen, ha nagy a havi tétel-volumen, vagy ha az ügyfél napi-heti gyakorisággal küld kivonatot.

A határ azonban világos: ha egyszer már megkaptad a PDF-et és nincs hozzáférésed a strukturált exporthoz, ne fordulj vissza az ügyfélhez exportért. A PDF-bemenet feldolgozása — a cikkben végigvitt munkafolyamattal — az adekvát megoldás, és sok esetben gyorsabb is, mint az ügyfelet újabb fájl letöltésére kérni.

A döntési logikát hosszabb távon érdemes így nézni. A PDF-irány különösen indokolt, ha:

• az ügyfél technikailag nem tudja az exportot lekérni (nem ért az OTP Direkthez, nincs jogosultsága a vállalati felületre),
• a kivonat régi, papíralapú vagy szkennelt formában érkezik (felszámolási anyag, archív időszak, ügyvédi adatkérés),
• több bankkivonatos ügyfeled van vegyes forrásokkal, és egyetlen workflow-t akarsz mindegyikre.

A strukturált export-irány különösen indokolt, ha:

• az ügyfél napi vagy heti gyakorisággal küld kivonatot, és nagy a havi tétel-volumen,
• az ügyfél maga is használja az OTP Direktet, és az export-letöltés nem extra teher számára,
• a könyvelőirodában már fut az ExcelGuru, Novitax vagy Kulcs-Soft alapú import-folyamat más ügyfeleknél.

A két út kiegészíti egymást, és a konkrét ügyfelenkénti választás a helyzettől függ — nem értelmes egyik utat sem fő útként minden ügyfélre kényszeríteni.

A havi ismétlődő munkához egyetlen Excel-sablon a leghatékonyabb befektetés. Hozz létre egy üres munkafüzetet a fenti oszlop-fejlécekkel — Tranzakció dátuma | Könyvelési nap | Értéknap | Partner neve | Partner számlaszáma | Közlemény | Terhelés (HUF) | Jóváírás (HUF) | Egyenleg (HUF) | Deviza | Tranzakció-azonosító —, és minden hónap végén másold át a generált tételeket a sablon ugyanezen oszlopaiba. A munka a séma kialakításáról az adatok átviteléről és ellenőrzéséről kerül át — két különböző feladat, és csak az utóbbit kell havonta megismételni.

A sablonban érdemes előre beállítani néhány eszközt: szűrőket a Partner neve oszlopra (a visszatérő szállítók azonnal kiválaszthatók), keresési segédet a Közlemény oszlopra (a kategorizáláshoz), és egy egylapos pivot-táblát a havi forgalom partner-szerinti csoportosítására. Ezek a beállítások egyszer készülnek el, és minden hónapban 10–15 percet adnak vissza.

Ha az adott ügyfél bér-utalásait is te kezeled, érdemes tudnod: ugyanaz a PDF→Excel munkafolyamat-architektúra, amelyet itt a bankkivonatra használtál, közvetlenül alkalmazható a bérjegyzékek PDF-ből Excelbe konvertálása ugyanezzel a munkafolyamattal feladatra is — a séma más, az elv ugyanaz: PDF-bemenet, magyar oszlopok, záró összeg-ellenőrzés. És ha a havi pénzügyi zárás során a számla-oldali tételezés is része a feladatodnak, a NAV Online Számla XML-ek Excelbe rendezése a számlaoldali párhuzamhoz megadja a teljes havi képet — bankkivonat a kifizetés-oldalon, NAV XML a számla-oldalon, és a kettő együtt a havi-zárás teljes alapanyaga.