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 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.
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 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.
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 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.
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. Társasházkezelő ügyfélnél ez a logika a társasházi közmű számlák Excelbe rendezett havi nyilvántartására is átvihető: a banki tranzakció-oldalon a partner-szűrő, a számla-oldalon pedig az MVM, vízmű és távfűtés tételek lakásra bontása adja a közös költség elszámolás alapjá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. A nagyobb vagy szokatlan szállítói kifizetések előtt ugyanebbe az ellenőrző körbe érdemes beépíteni a szállítói adószám fizetés előtti ellenőrzését is, hogy a banki tételhez tartozó számla és partner státusza is dokumentált legyen.
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 választás a hozzáférésen és a tétel-volumenen múlik: ha az ügyfél maga is kezeli az OTP Direktet vagy az OTPdirektet és napi-heti volumenben dolgoztok, érdemes a strukturált export-utat (ExcelGuru, Novitax, Kulcs-Soft) bevezetni. Egyébként — különösen szkennelt, archív vagy vegyes forrású ügyfeleknél — a PDF-feldolgozás gyorsabb, és nem teszi az ügyfelet újabb fájl letöltésére rá.
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 a sablonod kimenetét közvetlenül a magyar könyvelőprogramba (Novitax, Kulcs-Soft, RLB) szeretnéd betölteni, a bankszámlakivonat-tételek könyvelőprogramba importálható Excel-szerkezetbe rendezése megadja a könyvelési nap, értéknap, partner, közlemény és devizás tételek elrendezését pontosan az import-formátumhoz illesztve.
Ha a havi pénzügyi zárás során a számla-oldali tételezés is rád esik, a NAV Online Számla XML-ek Excelbe rendezése a számlaoldali párhuzamhoz megadja a teljes havi képet — a banki tételek a kifizetés-oldalt, a NAV XML a számla-oldalt fedi le.