Napojení plateb na ERP a účetnictví: párování bez ruční práce

Zákazník zaplatil převodem v pondělí ráno. Objednávka se odeslala ve středu, protože platbu někdo ručně dohledával ve výpisu. Na konci měsíce pak účetní zjistí, že od platební brány přišlo na účet dvacet souhrnných převodů, které neodpovídají žádné faktuře. Obojí má stejnou příčinu: peníze, objednávky a účetnictví žijí v různých systémech a nikdo je nepropojil.

V článku ukazujeme, jak platby dostat z banky a platební brány do e-shopu, ERP a účetnictví. Bez vymýšlení vlastních formátů, s tím, co banky a brány v Česku skutečně nabízejí (k 9/2026).

Tři toky peněz, tři různé zdroje dat

Než začnete cokoli napojovat, ujasněte si, odkud platby chodí. Každý zdroj se páruje jinak.

Nejčastější chyba je snažit se párovat všechno podle bankovního výpisu. U převodů to funguje. U brány ne, protože na účtu vidíte jednu částku za desítky objednávek, navíc sníženou o poplatky.

Bankovní převody: API místo stahování souborů

Výpisy z banky můžete do systému dostat dvěma způsoby. Ručně nebo plánovaně stáhnout soubor, nebo se na banku napojit přes API.

Soubor ve formátu ABO (GPC). Standard českých účetních programů. Umí ho Pohoda, Money S3 i Abra Flexi. Pozor na varianty: jednotlivé banky formát drobně upravují, takže ne každý GPC soubor projde každým importem napoprvé.

API banky. Systém si pohyby stahuje sám. Příklady:

• Fio banka nabízí API Bankovnictví s tokenem vygenerovaným v internetovém bankovnictví. Pohyby vrací mimo jiné v XML, JSON, CSV, GPC nebo MT940. Podle dokumentace je nejmenší interval mezi dotazy na stejný token 30 sekund.
• Pohoda podle Stormware umí přímé napojení mimo jiné na API Fio, České spořitelny, KB, ČSOB a Raiffeisenbank. Duplicitní pohyby při opakovaném stažení sama rozpozná.
• Shoptet umí párovat platby z Fio účtu přes token v nastavení detekce plateb. Pro víc bank a účtů nabízí službu Propojení s bankou v rámci Shoptet Pay.

Existuje ještě třetí cesta: poskytovatel služby informování o účtu podle směrnice PSD2 (AISP). Ten musí mít licenci ČNB nebo jiného regulátora v EU a přístup k účtu stojí na souhlasu klienta, který je časově omezený a musí se pravidelně obnovovat. Pro e-shop to dává smysl hlavně tehdy, když banka nemá vlastní API pro firemní klienty.

Platební brány: párujte vyúčtování, ne výpis

Brána vám peníze posílá v dávkách. Aby účetnictví sedělo, potřebujete rozpad každé dávky na jednotlivé transakce. Brány, se kterými se na českých e-shopech potkáváme nejčastěji, ho nabízejí:

• [Comgate](/kb/platebni-brany/comgate) posílá denní vyúčtování ve formátu CSV pro automatické zpracování a ABO pro účetní software. Stáhnout ho jde i přes API. Parametr refID (vaše číslo objednávky) se v CSV objeví ve sloupci „ID od klienta", takže platbu spárujete přímo s objednávkou. Měsíční vyúčtování chodí podle nápovědy Comgate nejpozději 6. den v měsíci.
• [GoPay](/kb/platebni-brany/gopay) umí výpis pohybů obchodního účtu ve formátu ABO (soubor .gpc), poslaný e-mailem v nastavené frekvenci nebo vygenerovaný přes API.
• Stripe má report Payout reconciliation, který každou výplatu na účet rozpadne na transakce, refundace a poplatky. Stejná data dává API přes objekty balance transaction filtrované podle ID výplaty.

Doporučený model účtování je jednoduchý. Brána je pro účetnictví samostatný „účet", podobně jako pokladna. Platba zákazníka se zaúčtuje proti faktuře v den, kdy ji brána potvrdí. Souhrnný převod na bankovní účet pak jen přesouvá peníze z brány do banky. Rozdíl mezi přijatými platbami a převodem jsou poplatky brány a vratky. Ty musí být ve vyúčtování vidět zvlášť, jinak se na konci měsíce nic nesečte.

Kde se párování láme

Automatické párování podle variabilního symbolu a částky zvládne většina plateb. Problém je ve zbytku. Typické situace:

• Chybí nebo je špatně VS. Zákazník ho přepsal ručně, prohodil číslice nebo ho vynechal.
• Jiná částka. Zákazník zaplatil bez haléřů, dvě objednávky jednou platbou nebo jen část.
• Platba v cizí měně. Na účet dorazí částka po konverzi, která neodpovídá faktuře.
• Vratka přes bránu. Objednávka je zaplacená, pak částečně vrácená, a v dávce se objeví záporná položka.
• Dvojí zaplacení. Zákazník zaplatí kartou, platba se mu zdá neúspěšná a pošle ještě převod.

Pravidlo, které doporučujeme: automat páruje jen jednoznačné shody. Všechno ostatní jde do fronty výjimek s návrhem, kam platba asi patří. Člověk to schválí jedním klikem. Špatně automaticky spárovaná platba nadělá víc škody než nespárovaná, protože ji nikdo nehledá.

Nejvíc chyb přitom odstraníte ještě před platbou. QR platba v potvrzovacím e-mailu s předvyplněným účtem, částkou a VS odstraní ruční přepisování, a tím i většinu překlepů ve VS.

Kdo je zdrojem pravdy o zaplacení

Tady se napojení plateb potkává s propojením ERP, e-shopu a skladu. Stav „zaplaceno" potřebují tři systémy: e-shop (aby odeslal zboží a informoval zákazníka), ERP (aby uvolnil expedici) a účetnictví (aby uzavřelo pohledávku). Pokud páruje každý zvlášť, dříve nebo později se rozejdou.

Osvědčené uspořádání:

1. Brána informuje e-shop o zaplacení v reálném čase přes notifikaci. Tady nic neřešte, to je standard implementace brány.
2. Převody páruje jeden systém. Buď e-shop (pokud má napojení na banku), nebo ERP. Výsledek posílá ostatním.
3. Účetnictví dostává zaplacené doklady a vyúčtování bran. Bankovní výpis v něm slouží ke kontrole, ne k novému párování.
4. Rozdíly mezi systémy hlídá noční kontrola: zaplacené objednávky bez dokladu, doklady bez platby, dávky brány, jejichž součet nesedí s převodem.

Jak s doklady k platbám zachází zákon a co se dá vystavovat automaticky, rozebíráme v článku Fakturace a účetní podklady.

Jak na to prakticky

Postup, kterým napojení plateb stavíme:

1. Inventura zdrojů. Sepište všechny banky, účty, měny, brány a dopravce s dobírkou. U každého zjistěte, jaký výpis nebo API nabízí.
2. Rozhodněte, kdo páruje. Pro převody jeden systém, pro brány vyúčtování. Zapište to, ať to ví i účetní.
3. Sjednoťte identifikátory. Číslo objednávky = variabilní symbol = refID v bráně. Když se liší, párování stojí na převodní tabulce, která se jednou rozbije.
4. Nastavte účty v účetnictví. Pro každou bránu samostatný účet peněz na cestě a účet pro poplatky.
5. Napojte stahování. API banky tam, kde existuje, ABO/GPC soubory tam, kde ne. Plánované, ne ruční.
6. Frontu výjimek udělejte viditelnou pro obchod i účetní, ne jen pro jednoho člověka.
7. Měsíční kontrola. Součet vyúčtování brány = součet převodů + poplatky + vratky. Pokud nesedí, víte to hned, ne při uzávěrce.

Propojení e-shopu s účetním a ERP systémem řešíme v rámci služby napojení na ERP. Základní synchronizace objednávek a skladu trvá obvykle 2–4 týdny, párování plateb k ní přidáváme podle toho, kolik zdrojů plateb máte. Pokud současně měníte nebo přidáváte bránu, podívejte se na platební systémy. Standardní implementace jedné brány trvá obvykle 1–2 týdny a párování s účetnictvím řešíme rovnou s ní.