Jak propojit účetnictví s aplikací správně

Ruční přepisování faktur do účetního systému obvykle nezačne jako zásadní problém. Nejprve jde o několik dokladů týdně. Pak přibudou objednávky, předplatná, dobropisy, více měn a další lidé, kteří s daty pracují. Otázka jak propojit účetnictví s aplikací rozhoduje o tom, zda finance pracují s aktuálními daty, nebo zda firma každý měsíc dohání chyby z provozu.

Správné propojení nevzniká tím, že se mezi dva systémy pošle soubor s fakturami. Nejdřív je potřeba určit, odkud který údaj vychází, kdy se může změnit a kdo za něj odpovídá. Teprve nad tím má smysl stavět integraci.

Nejdřív určete, co má propojení řešit

Účetní systém a provozní aplikace mají rozdílnou roli. Aplikace obvykle řeší zákazníky, objednávky, smlouvy, poskytované služby nebo platby. Účetnictví potřebuje správně zaevidované účetní doklady, sazby DPH, párování úhrad a podklady pro účetní závěrku. Když z jednoho systému uděláte kopii druhého, skončíte se dvěma místy, která si mírně odporují.

Začínáme proto konkrétním pracovním tokem. Firma například vytvoří objednávku v zákaznickém portálu, po jejím potvrzení vznikne faktura, účetní systém ji zaeviduje a po zaplacení se stav úhrady vrátí do aplikace. U předplatného může být tok jiný: aplikace každý měsíc vytváří podklady pro fakturaci, účetní systém vystavuje doklady a aplikace pouze zobrazuje jejich stav.

Rozdíl je podstatný. V prvním případě je zdrojem faktury aplikace. Ve druhém může být zdrojem účetní systém. Pokud tuto odpovědnost neurčíte hned, dříve nebo později vzniknou dvě verze stejného dokladu s odlišnou částkou, variabilním symbolem nebo stavem platby.

Oddělte potřeby účetní od očekávání obchodního týmu. Obchod obvykle potřebuje vidět, zda zákazník zaplatil. Účetní potřebuje vědět, jak byla úhrada spárována, do jakého období patří a zda doklad nebyl stornován. Stav z platební brány a spárovaná úhrada v účetnictví nejsou totéž. Brána to často řekne dřív.

Jak propojit účetnictví s aplikací bez dvojích dat

První návrhové pravidlo je jednoduché: každý typ údaje má jeden hlavní zdroj. Aplikace může být hlavním zdrojem zákazníků a objednávek. Účetní systém může být hlavním zdrojem účetních dokladů, zaúčtování a skutečně spárovaných plateb. Integrace pak data nepřelévá bez rozmyslu, ale předává je tam, kde je druhý systém potřebuje.

V praxi se vyplatí napsat si mapu dat ještě před vývojem. U každého údaje musí být jasné, zda jde z aplikace do účetnictví, opačným směrem, nebo zda se vůbec nepřenáší. Typicky sem patří obchodní název a identifikační údaje zákazníka, fakturační adresa, položky dokladu, měna, sazba DPH, datum zdanitelného plnění, splatnost, variabilní symbol, stav storna a informace o úhradě.

Zvláštní pozornost si zaslouží identifikátory. Interní ID objednávky není číslo faktury a číslo faktury nemusí být vhodné jako technický klíč. Každý systém má vlastní identifikaci záznamů. Propojení proto obvykle ukládá vazbu mezi ID objednávky v aplikaci a ID dokladu v účetnictví. Bez této vazby se opravy, storna a opakované odeslání dat rychle mění v ruční dohledávání.

U zákazníků je potřeba rozhodnout, jak se zabrání duplicitám. Jako klíč může fungovat IČO, ale ne vždy — například u zahraničních subjektů, fyzických osob nebo zákazníků, kteří údaje doplní až později. Proto nelze automatické slučování stavět jen na podobnosti názvu firmy. IČO se v Česku ověřuje v ARES, evropské DIČ ve VIES. Když registr neodpoví nebo nesedí s objednávkou, záznam patří člověku. Automaticky přepisovat název firmy podle registru bez pravidla je rychlá cesta k rozbitým dokladům.

Ne každé propojení musí být obousměrné

Obousměrná integrace zní prakticky, ale přináší více stavů a konfliktů. Pokud se faktura upraví v aplikaci i v účetním systému, co má přednost? A co se stane, když je doklad v účetnictví uzavřený, ale obchodník v aplikaci změní objednávku?

Ve většině případů je lepší zvolit řízený tok. Aplikace vytvoří návrh nebo požadavek na vystavení dokladu. Účetní systém vrátí číslo faktury, případně její PDF a stav zpracování. Stav úhrady se pak propisuje zpět. Úpravy už vystavených dokladů se neřeší přepsáním původní faktury, ale standardním účetním postupem, například dobropisem nebo stornem.

Tohle omezení chrání účetní historii a lidem v provozu řekne, kde která změna patří. Stejný spor o zdroj pravdy řeší i propojení dalších firemních systémů, nejen účetnictví.

Technický návrh rozhoduje o tom, zda integrace vydrží provoz

Účetní systém může nabízet API, výměnu přes XML, importní soubory nebo kombinaci těchto cest. API je vhodné pro průběžnou komunikaci, ale samo o sobě neřeší správnost dat ani výpadky. Import souborů může stačit, pokud doklady jdou jednou denně. Zpětná vazba je pomalejší a chyby se hůř hledají.

V Česku se rozhraní liší víc než „máme API“. Desktopové účetnictví často bere XML nebo lokální službu a v okamžiku objednávky nemusí vůbec běžet. Cloudové fakturační nástroje mívají API.

Rozhraní	Časté u	Co z toho plyne
XML nebo importní soubor	Pohoda, Money S3	fronta nebo noční dávka; checkout nečeká na účetní program
REST API	iDoklad, Fakturoid, FlexiBee	průběžný přenos; výpadek, duplicity a logy řešíte stejně

U aplikací, kde vznikají faktury nebo platby průběžně, stavíme přenos jako samostatný proces na pozadí. Uživatel dokončí objednávku a aplikace uloží požadavek na vytvoření dokladu. Integrační proces ho následně odešle do účetnictví, zaznamená výsledek a při dočasném výpadku jej zkusí znovu. Zákazník tak nečeká na odpověď cizího systému a firma nepřijde o doklad jen proto, že byl účetní systém chvíli nedostupný.

Každý přenos musí být opakovatelný bez vzniku duplicit. Tomu se říká idempotence, ale pro byznys je podstatné hlavně toto: pokud se odpověď ztratí nebo služba selže, opakování nesmí vytvořit druhou stejnou fakturu. Řeší se to unikátním referenčním klíčem, uložením stavu odeslání a kontrolou, zda účetní systém doklad už nepřijal.

Stejně důležité je logování. Nestačí vědět, že integrace skončila chybou. Potřebujete dohledat, jaký doklad se posílal, kdy, s jakou verzí dat, jakou odpověď vrátil druhý systém a zda byl pokus opakován. Citlivé údaje přitom do technických záznamů nepatří v plném rozsahu. Log má pomoci problém vyřešit, ne vytvořit další bezpečnostní riziko.

Webhooky, dávky a ruční kontrola

Když účetní systém umí posílat notifikace o změně, například o spárování platby, webhook bývá nejrychlejší cesta. Aplikace dostane událost bez pravidelného dotazování a může ihned změnit stav objednávky nebo zpřístupnit službu.

Webhook ale potřebuje ověřený podpis požadavku, bezpečné zpracování i při opakovaném doručení a zálohu pro případ, že některá oznámení nedorazí. Proto dává smysl doplnit jej pravidelnou kontrolou vybraných stavů. U menšího objemu dokladů může naopak stačit noční dávka, pokud zpoždění nepředstavuje provozní problém.

Nejasné případy by měly skončit ve frontě pro člověka, ne v tichém selhání. Například neplatné DIČ, chybějící sazba DPH nebo zákazník, kterého nelze jednoznačně přiřadit, vyžadují rozhodnutí. Aplikace může účetnímu ukázat konkrétní problém a nabídnout opravu, ale neměla by si účetní pravidla domýšlet.

Účetní pravidla nejsou okrajový detail

Nejvíce chyb nebývá v samotném volání API, ale ve významu účetních dat. U fakturace do zahraničí se liší práce s DPH podle země, typu zákazníka a poskytované služby. U více měn rozhoduje kurz, okamžik přepočtu i pravidla zaokrouhlení. U záloh a dobropisů je zase nutné zachovat návaznost na původní doklad.

Zaokrouhlení DPH je konkrétní, ne kosmetické. České částky jdou na haléře. Float v aplikaci a účetní software na stejné položce umí skončit o haléř vedle. Import to pak odmítne, nebo vznikne doklad, který účetní opravuje ručně. Počítejte v desetinné aritmetice a zaokrouhlujte podle stejného pravidla, jaké má účetní systém.

Poplatky brány jsou druhý klasický rozjezd. Zákazník zaplatí částku na faktuře, GoPay nebo Stripe na účet pošle míň. Obchod z brány vidí „zaplaceno“. Účetní vidí jinou částku k párování. Bez pravidla, jestli se poplatek účtuje zvlášť, integrace hledá úhradu, která v bance neexistuje.

Technický tým proto potřebuje na začátku konkrétní odpovědi od účetní nebo finančního garanta. Kdy vzniká zdanitelné plnění? Vystavuje se doklad při objednávce, při dodání, nebo po přijetí platby? Co má aplikace udělat při částečné úhradě? Bez těchto pravidel může být integrace technicky funkční a účetně nepoužitelná.

To platí i pro uzávěrky. Pokud je účetní období uzavřené, aplikace by neměla umožnit zpětně měnit údaje, které by narušily zaúčtované doklady. Někdy stačí změnu zablokovat, jindy je správnou cestou vytvoření opravného dokladu. Záleží na procesu firmy a použitém účetním řešení.

Ověřujte na situacích, které nastanou v reálném provozu

Integraci netestujeme jen na jedné správně vyplněné faktuře. Před nasazením má smysl projít scénáře, které běžně vznikají: opakované odeslání požadavku, výpadek účetního systému, storno po vystavení faktury, změna sazby DPH, platba v jiné výši, částečná úhrada i zákazník se stejným názvem jako jiný subjekt.

Důležité je také ověřit, kdo chybu uvidí a jak ji opraví. Pokud účetní musí kvůli každému neúspěšnému přenosu psát vývojářům, provoz se zbytečně brzdí. Naopak administrace aplikace může ukázat stav přenosu, důvod chyby a bezpečnou možnost záznam znovu odeslat až po opravě dat.

Po spuštění je vhodné první období porovnávat data v obou systémech. Ne proto, že integraci nedůvěřujete, ale protože až skutečný provoz ukáže výjimky, které se do zadání nedostaly. V Nextrey podobné napojení navrhujeme jako součást konkrétního pracovního toku, stejně jako u automatizace fakturace, ne jako izolovanou technickou funkci.

Dobře propojené účetnictví nevypadá navenek efektně. Poznáte ho ve chvíli, kdy obchodní tým vidí správný stav zákazníka, účetní nemusí dohledávat původ každého dokladu a změna v aplikaci nevytvoří nepořádek ve financích.