Prestaňte ručne zadávať transakcie do Actual Budget a YNAB

Ak používate aplikáciu na osobné financie ako Actual Budget alebo YNAB, poznáte to: ručné zadávanie transakcií je nuda. Možno ste si priali, aby vaša banka ponúkala API. Možno ste skúšali služby tretích strán ako Plaid alebo Salt Edge a zistili ste, že vašu regionálnu európsku banku nepodporujú.

Fakt je, že dátový feed z banky už máte. Chodí vám do schránky niekoľkokrát denne. Notifikácie o transakciách obsahujú všetko, čo treba: sumy, dátumy, obchodníkov aj ID transakcií. Nejde o to, či dáta existujú. Ide o to, či ich viete vytiahnuť spoľahlivo a automaticky.

Import transakcií z e-mailov mi beží už vyše roka. Nie je dokonalý, ale 95 % mojich transakcií spracuje sám. Žiadne API banky. Žiadne služby tretích strán. Len parsovanie e-mailov, pár regulárnych výrazov a naplánovaná úloha.

Na tomto prístupe ma nezaujala technická vychytávka, ale spoľahlivosť. Keď to raz nastavíte, jednoducho to funguje. E-maily prídu, transakcie sa naimportujú, rozpočet je aktuálny. Údržba je minimálna. A na rozdiel od integrácií tretích strán, ktoré sa pokazia pri zmene API alebo zaniknú spolu so službou, parsovanie e-mailov závisí len od vašej schránky. A tá nikam nezmizne.

Ukážem vám, ako to funguje, kedy sa to oplatí a čo zvážiť, ak si chcete postaviť niečo podobné.

Hodí sa parsovanie e-mailov aj pre vás?

Najprv rýchly rozhodovací strom:

ŠTART: Ponúka vaša banka API integráciu s vašou rozpočtovou aplikáciou?
  │
  ├─ ÁNO → Použite natívnu integráciu
  │
  └─ NIE → Podporuje vašu banku služba ako Plaid?
      │
      ├─ ÁNO → Vyhovuje vám prístup tretej strany?
      │   ├─ ÁNO → Použite Plaid/Salt Edge
      │   └─ NIE → Pokračujte nižšie
      │
      └─ NIE → Posiela vaša banka e-mailové notifikácie o všetkých transakciách?
          │
          ├─ NIE → Ostaňte pri ručnom zadávaní alebo CSV exportoch
          │
          └─ ÁNO → Zvládnete základné skriptovanie a regexy?
              │
              ├─ ÁNO → Parsovanie e-mailov sa pre vás hodí ✓
              └─ NIE → Ručné zadávanie bude jednoduchšie

Prečo som sa rozhodol pre parsovanie e-mailov

Actual Budget vie pripojiť banky cez GoCardless API a vyskúšal som to. Problém nebol v dostupnosti, ale v spoľahlivosti. GoCardless synchronizoval len pár ráz denne a niektoré transakcie sa nenačítali vôbec. Ak chcete mať rozpočet presný, chýbajúce transakcie alebo 12-hodinové oneskorenie ho robia zbytočným.

E-mailové notifikácie naopak chodia do pár minút po transakcii a fungujú zhruba na 99 %. Banky majú silný dôvod ich doručovať a bežia na osvedčenej e-mailovej infraštruktúre. Tento rozdiel v spoľahlivosti rozhodol. Parsovanie e-mailov som si vybral napriek tomu, že si vyžiadalo viac práce s nastavením.

Prečo sú e-mailové notifikácie dobrý zdroj dát

Väčšina bánk posiela notifikácie o transakciách e-mailom. Nie sú to marketingové e-maily ani mesačné výpisy. Sú to upozornenia v reálnom čase, ktoré prídu do pár minút po transakcii. Majú pevnú štruktúru, jednotný vzhľad a obsahujú všetky podstatné údaje:

suma a mena transakcie
dátum a čas
názov obchodníka alebo príjemcu
ID transakcie (väčšinou)
identifikátor účtu

Štruktúra je predvídateľná, lebo e-maily generuje automat. Pri každej transakcii sa použije rovnaká šablóna. Práve preto sa dajú dobre parsovať.

Zaujímavá je aj bezpečnosť. Tretej strane nedávate prístup k bankovému účtu. Nikde neukladáte prihlasovacie údaje do banky. Čítate e-maily, ktoré vám už aj tak chodia. Ak niekto prelomí vašu schránku, tieto transakcie už vidí. Automatizácia nevytvára novú plochu útoku, len číta to, čo tam už je.

Bezpečnosť v kocke: Parsovanie e-mailov nevytvára novú plochu útoku. Ak niekto prelomí vašu schránku, notifikácie o transakciách už vidí. Tento prístup len automatizuje čítanie toho, čo tam už je. Neukladáte prihlasovacie údaje do banky a nikomu tretiemu nedávate prístup.

Nie je to teoretické cvičenie. Takto som spracoval tisíce transakcií. Notifikácie sú spoľahlivejšie, než by ste čakali. Banky šablóny e-mailov menia len zriedka. A keď to urobia, parser zlyhá hlasno a očividne: hneď vidíte, že sa transakcie prestali importovať.

Architektúra automatizácie rozpočtu cez e-mail

Systém má štyri samostatné časti. Keď každú pochopíte, uvidíte, kde sa skrýva zložitosť.

E-mailový klient - Pripája sa k poskytovateľovi e-mailu cez IMAP (štandardný protokol na prístup k pošte na serveri) a sťahuje notifikácie o transakciách. Hľadá neprečítané e-maily z adresy odosielateľa vašej banky, zvyčajne v určitom dátumovom rozsahu. Kľúčové je filtrovanie: chcete notifikácie o transakciách, nie marketing ani výpisy z účtu. Väčšina bánk posiela upozornenia z jednotnej adresy, takže filtrovanie je jednoduché.

Parser - Tu sedí všetka inteligencia. Parser prejde každý e-mail a vytiahne štruktúrované dáta: sumu, menu, dátum, obchodníka a ID transakcie. Polia v texte hľadá pomocou vzorov (zvyčajne regulárnych výrazov). Každá banka má iný formát e-mailov, takže pre každú potrebujete vlastný parser. Práve tu sa to láme, keď banka zmení šablónu.

Naučil som sa to na vlastnej koži. Prvý parser som napísal príliš rigidne: hľadal presné zhody textu a rozbil sa hneď, ako banka prepísala „Amount:“ na „Transaction amount:“. Prepísať ho na flexibilné vzory mi zabralo 20 minút, ale ušetrilo ma od mesačného ladenia.

Klient rozpočtového API - Keď máte štruktúrované dáta, treba ich poslať do rozpočtovej aplikácie. Actual Budget aj YNAB majú API na import transakcií. Klient rieši autentifikáciu, naformátuje transakciu podľa špecifikácie API a odošle ju. API vráti potvrdenie alebo detail chyby.

Detekcia duplicít - Banka môže poslať tú istú notifikáciu viackrát. Skript môže spracovať ten istý e-mail dvakrát. Detekcia duplicít bráni opakovanému importu tej istej transakcie. Najspoľahlivejší spôsob: vytiahnuť z e-mailu unikátne ID transakcie a poslať ho spolu s dátami. Mnohé rozpočtové API vedia podľa tohto ID duplicitu odmietnuť.

Takto časti spolupracujú:

[E-mailová schránka]
    → Stiahnutie neprečítaných e-mailov z banky

[Parser]
    → Extrakcia: suma, dátum, obchodník, ID transakcie

[Klient rozpočtového API]
    → Odoslanie do Actual Budget/YNAB
    → S ID transakcie na detekciu duplicít

[Označenie e-mailu ako prečítaného]
    → Zabráni opätovnému spracovaniu

Tok je lineárny a bez stavu. Každý beh stiahne neprečítané e-maily, spracuje ich, naimportuje transakcie a označí e-maily ako prečítané. Ak skript v polovici spadne, najhoršie, čo sa stane, je dvojitý import niektorých transakcií. A ten zachytí detekcia duplicít. Nie je tu žiadny zložitý stav, ktorý by sa dal poškodiť alebo obnovovať.

Čo sa dá z bankových e-mailov vytiahnuť

Nie všetky e-maily o transakciách obsahujú rovnaké údaje. Záleží, čo banka uvedie. Toto zvyčajne nájdete a takto sa to mapuje na polia rozpočtovej aplikácie:

Suma a mena - Sú vždy uvedené a väčšinou sa dajú ľahko vytiahnuť. Väčšina e-mailov ich formátuje jasne: „Amount: 45.67 EUR“ alebo „$123.45“. Dajte pozor na záporné a kladné sumy.

Dátum a čas - Sú zvyčajne uvedené, ale ich formát sa mení od banky k banke. Musíte zvládnuť formát vašej banky a previesť ho na ten, ktorý čaká vaše rozpočtové API. Čas býva uvedený, no málokedy sa hodí. Rozhoduje dátum.

Obchodník alebo príjemca - Banky uvedú to, čo odoslal platobný terminál. Môže to byť skrátené alebo s kódmi lokality. Z „STARBUCKS #8234 SEATTLE WA“ sa stane názov príjemcu. Extrakcia len prenesie to, čo je v e-maile.

ID transakcie - Váš mechanizmus na detekciu duplicít. Väčšina bánk uvádza unikátny identifikátor s označením „Transaction ID“, „Reference“ alebo „Authorization Code“. Vytiahnite ho a pošlite s transakciou. Rozpočtové API môže podľa neho odmietnuť duplicity.

Identifikátor účtu - Ak máte v jednej banke viac účtov, e-mail môže uvádzať, ktorý účet sa použil. Potrebujete ho, aby transakcia pristála na správnom účte v rozpočtovej aplikácii.

Takto vyzerá extrakcia v praxi:

Pole	Príklad z e-mailu	Vytiahnutá hodnota	Pole API
Suma	„Amount: 45.67 EUR“	`45.67`, `EUR`	`amount`, `currency`
Dátum	„2025-11-02 14:35“	`2025-11-02`	`date`
Obchodník	„STARBUCKS #8234 SEATTLE WA“	`STARBUCKS #8234 SEATTLE WA`	`payee_name`
ID transakcie	„ID: 221025/131110-2“	`221025/131110-2`	`imported_id`
Účet	„Card ending **5633“	`5633`	smerovanie na účet

Extrakcia je párovanie vzorov: hľadáte text ako „Amount: 45.67 EUR“ a zachytíte hodnoty. Regulárne výrazy fungujú dobre, lebo bankové e-maily sú štruktúrované a jednotné.

Bezpečnosť a prístup

Automatizácia cez e-mail potrebuje IMAP prístup do vašej schránky. Na tom, ako ho vyriešite, záleží.

App-specific heslá a OAuth - Na automatizáciu nepoužívajte hlavné heslo k e-mailu. Od mája 2025 vyžaduje Gmail na IMAP prístup OAuth 2.0 a app-specific heslá sa postupne rušia. Pri Gmaile preto budete musieť implementovať OAuth 2.0: raz na obrazovke OAuth udelíte súhlas a získate refresh token pre prístup bez dohľadu. Iní poskytovatelia e-mailu môžu app-specific heslá stále podporovať. Sú to prihlasovacie údaje s obmedzeným rozsahom, ktoré viete zrušiť samostatne. Ak uniknú alebo systém prestanete používať, môžete ich zrušiť bez dopadu na hlavný prístup k e-mailu.

Šifrovanie TLS - IMAP spojenia majú používať TLS. Je to štandard v každej IMAP knižnici. Zaručí, že prihlasovacie údaje ani obsah e-mailov nepoputujú sieťou ako čistý text.

Prístup len na čítanie - Automatizácia potrebuje e-maily iba čítať a označovať ako prečítané. Overte, že váš kód nerobí nič navyše.

E-mailové aliasy na mapovanie účtov - Aliasy vám dovolia smerovať oznámenia z rôznych účtov do rôznych e-mailových schránok. Ak je váš e-mail you@example.com, mnohí poskytovatelia dovoľujú používať aj you+checking@example.com a you+savings@example.com, hoci nie všetci poskytovatelia a banky to podporujú. Parser potom podľa adresy príjemcu zistí, na ktorý rozpočtový účet transakciu priradiť.

Prostredie, kde to beží - Bežné voľby: vlastný server, Raspberry Pi, cloudové VM alebo lokálny stroj s plánovačom. Ak to pustíte pod vlastným používateľom na stroji, ktorý kontrolujete, dáta ostanú lokálne a súkromné.

Ako to rozšíriť: vzor rozhrania parsera

Časom budete pravdepodobne chcieť podporiť viac bánk. Možno máte účty v dvoch bankách. Možno chcete systém zdieľať s kamarátom, ktorý používa inú banku. Rozšíriteľnosť znamená, že pridanie novej banky nevyžaduje prepisovať celý systém.

Pomáha vzor rozhrania parsera. Každá banka má vlastnú triedu parsera, ktorá implementuje rovnaké rozhranie. To určuje, či parser zvládne daný e-mail (zvyčajne podľa adresy odosielateľa) a ako vytiahnuť dáta do štandardnej štruktúry. Hlavná slučka prechádza dostupné parsery, kým nenájde ten, ktorý e-mail zvládne, a použije ho na extrakciu. Logika špecifická pre banku tak ostane na jednom mieste. Keď banka zmení formát e-mailu, upravíte jeden parser a zvyšok systému necháte na pokoji.

Detekcia duplicít: ID transakcií sú vaši priatelia

Tá istá transakcia sa môže objaviť viackrát. Skript sa môže spustiť dvakrát alebo banka pošle notifikáciu opakovane. Detekcia duplicít bráni tomu, aby sa v rozpočte objavil jeden výdavok dvakrát.

Spoľahlivý spôsob sú ID transakcií. Parser k transakcii pridá jej jedinečný identifikátor pridelený bankou. Keď transakciu pošlete do rozpočtového API spolu s týmto ID, API si ho môže uložiť a rozpoznať duplicity. Opakovaný import tak dá rovnaký výsledok ako jednorazový.

Ak skript spadne po importe, ale pred označením e-mailov ako prečítaných, ďalší beh stiahne tie isté e-maily. API ich podľa ID transakcií odmietne ako duplicity. Nemusíte nič ručne čistiť.

Bez ID transakcií by ste museli párovať podľa sumy, dátumu a obchodníka, a to je krehké. Dve kávy v ten istý deň by sa pobili. ID transakcií túto nejednoznačnosť odstránia.

Prečo sú ID transakcií dôležité: Bez unikátnych ID by ste párovali podľa sumy, dátumu a obchodníka. Dve kávy po 5 $ v ten istý deň by sa pobili. ID transakcií túto krehkosť odstránia: každú transakciu viete jednoznačne identifikovať bez ohľadu na čas či sumu.

Automatizácia procesu: beh podľa plánu

Parsovanie nemusí bežať neustále. Banky posielajú notifikácie do pár minút po transakcii, ale okamžitý import nepotrebujete. Zvyčajne stačí raz za hodinu alebo raz denne.

Automatizácia beží v dávkach: pripojí sa k e-mailu, stiahne neprečítané e-maily od odosielateľov z banky, každý spracuje, naimportuje do rozpočtového API, označí ako prečítaný a odpojí sa. Hlavná zásada: skript nemá mať stav. Každý beh je nezávislý a spolieha sa len na obsah schránky a stav rozpočtového API. Môžete ho teda spustiť ručne, zmeniť plán alebo nejaký beh vynechať, a nič sa nerozbije.

Pri prvom behu majú význam limity dávky. Ak máte 500 neprečítaných e-mailov o transakciách, spracovať všetky naraz môže naraziť na limity API alebo trvať príliš dlho. Limit (napríklad max. 100 e-mailov na beh) tomu zabráni. Ďalší beh spracuje ďalšiu dávku.

Kedy sa to oplatí

Import transakcií cez e-mail nie je pre každého. Tu funguje dobre:

Vaša banka nemá API - Regionálne európske banky, menšie družstevné záložne a banky na rozvíjajúcich sa trhoch často API nemajú. Agregátory ako Plaid ich nepodporujú. Parsovanie e-mailov môže byť vaša jediná možnosť automatizácie.

Zvládate ľahké skriptovanie - Parser napíšete alebo upravíte, nastavíte plánované úlohy a budete ladiť, keď sa niečo pokazí. Ak sa nebojíte regulárnych výrazov a spúšťania skriptov, zvládnete to. Inak bude jednoduchšie ručné zadávanie alebo CSV exporty z banky.

Banka posiela notifikáciu o každej transakcii - Niektoré banky posielajú e-mail len nad určitú sumu. Ak vám banka pošle e-mail ku každej transakcii, pokryjete všetko. Ak chodia nárazovo, niečo vám unikne.

Nechcete pustiť tretiu stranu do banky - Služby ako Plaid fungujú dvoma hlavnými spôsobmi: priamym API pripojením k banke (dnes asi 75 % pripojení) alebo, pri bankách bez API, screen scrapingom cez prihlasovacie údaje: zadáte login do banky a Plaid sa za vás prihlási do účtu. Parsovanie e-mailov číta dáta, ktoré už máte. Je to alternatíva, ktorá chráni súkromie.

Máte viac účtov - Parsovanie e-mailov dokáže zjednotiť viac bánk. Každá banka má svoj parser a všetky transakcie tečú do jednej rozpočtovej aplikácie. Je to lepšie než prihlasovať sa na weby viacerých bánk a sťahovať CSV.

Kedy sa to neoplatí

Vaša banka má natívnu integráciu - Ak vašu banku podporuje rozpočtová aplikácia alebo Plaid/Salt Edge, použite to. Natívne integrácie sú spoľahlivejšie, lepšie udržiavané a nerozbijú sa pri zmene šablóny e-mailu.

Preferujete ručnú kontrolu - Ručné zadávanie vás núti všímať si, kam idú peniaze. Ak je to pre vaše rozpočtovanie dôležité, automatizácia môže oslabiť pozornosť, vďaka ktorej rozpočet funguje.

Notifikácie sú nespoľahlivé - Ak banka posiela upozornenia len pri vybraných typoch transakcií alebo ich doručuje nespoľahlivo, parsovanie e-mailov niektoré transakcie prehliadne.

Porovnanie možností

Takto si stoja tri hlavné prístupy:

Hľadisko	Parsovanie e-mailov	API tretej strany (Plaid)	Ručné zadávanie
Náročnosť nastavenia	Stredná (vývoj parsera)	Nízka (ak banku podporuje)	Žiadna
Pokrytie bánk	Každá banka s e-mailovými notifikáciami	Len podporované banky	Univerzálne
Súkromie	Vysoké (bez prístupu tretej strany)	Stredné (login cez tretiu stranu)	Vysoké
Údržba	Nízka (15 - 30 min pri zmene šablóny)	Žiadna	Stála (denná úloha)
Spoľahlivosť	Vysoká (pri zlyhaní hlasno zlyhá)	Vysoká	Vysoká (ručná kontrola)
Cena	Zadarmo (vlastná práca)	Často predplatné	Čas
Najlepšie pre	Nepodporované banky, ľudí dbajúcich na súkromie	Bežné banky, pohodlie	Uvedomelé rozpočtovanie

Ako to vyzerá s údržbou

Banky menia šablóny e-mailov zriedka, možno raz za rok. Keď sa to stane, parser sa rozbije a transakcie sa prestanú importovať. Všimnete si to hneď.

Oprava trvá 15 - 30 minút: pozriete sa na nový formát, upravíte logiku parsovania a otestujete. Zlyhanie je viditeľné, nejde o tiché poškodenie dát. Parser buď funguje, alebo nie.

Za túto údržbu platíte. Natívne API integrácie sa nerozbijú zmenou šablóny e-mailu, ale vyžadujú, aby banka udržiavala API. Pri bankách bez API sú občasné úpravy parsera cenou za automatizáciu.

Stavba s pomocou AI

Celú integráciu som postavil s Claude Code, AI asistentom na programovanie. Napísal implementáciu v TypeScripte, nastavil IMAP klienta, vymyslel regexy na parsovanie a napojil Actual Budget API. Celý systém bežal za pár hodín. Väčšinu času som strávil testovaním rôznych formátov e-mailov a ladením okrajových prípadov.

Nie je to však riešenie bez kódu. Potrebujete základy programovania, aby ste rozumeli, čo kód robí, vedeli upraviť parsery, keď banka zmení formát e-mailov, a vedeli ladiť, keď sa niečo pokazí. Ak viete čítať TypeScript alebo JavaScript a zvládate príkazový riadok, AI asistenti urobia väčšinu ťažkej práce. Ak programovanie nepoznáte, bude vás to iba frustrovať.

Praktické poznámky k implementácii

Ak uvažujete o vlastnej stavbe, budete potrebovať: IMAP prístup k e-mailu (s app-specific heslom alebo cez OAuth), vzorové e-maily o transakciách z vašej banky na vývoj pravidiel parsovania, prístupové údaje k API rozpočtovej aplikácie a plán na ošetrenie chýb. Pred automatizáciou všetko ručne otestujte na malej dávke.

Na záver

Systém používam od začiatku roka 2024 a prešli ním tisíce transakcií z viacerých bánk a v rôznych menách. Údržba dokopy: asi dve hodiny za rok, väčšinou úpravy parsera, keď banky zmenili formát e-mailov.

Je to náhradné riešenie za chýbajúce bankové API, ale prekvapivo robustné. Natívne integrácie nenahradí tam, kde existujú. No pre banky bez API, pre ľudí, ktorí chcú automatizáciu šetrnú k súkromiu, a pre každého, koho omrzelo ručné zadávanie transakcií, je to schodná cesta. Dáta tam už sú. Notifikácie sú už štruktúrované. Len vyťahujete to, čo vám banka aj tak posiela.

Ak ste postavili niečo podobné, alebo ak ručne zadávate transakcie, lebo vaša banka nemá API, rád sa to dozviem. Aký je váš prístup? Čo sa pokazilo? Čo vás prekvapilo? Napíšte mi na hi@andrejkostal.sk.