Propojení CRM s účetnictvím nevázne na technice, ale na datech.

Obchod a účetnictví popisují jednu firmu dvakrát.

Autor blogu Mecanik Dev to říká na začátku svého textu takhle: "propojení CRM a ERP se téměř vždy popisuje jako problém spojení a téměř nikdy o problém spojení nejde" (Mecanik Dev, dev.to, 16. 9. 2026). Oba systémy mají popsané rozhraní a hotové konektory. Potíž je jinde: obchod a finance roky popisují tutéž firmu jinými slovy a propojení je místo, kde se musí shodnout.

Česká firma to pozná ve chvíli, kdy někdo položí první otázku. Má se zákazník, kterého obchodník v CRM založil podruhé, propsat do účetnictví jako jeden odběratel, nebo jako dva? Od té chvíle už nejde o techniku. Tu samou otázku pak musíte rozhodnout u každého sdíleného údaje a to je vlastní práce projektu.

Kde se dva správné modely rozcházejí.

CRM je postavené kolem získávání obchodu. Jeho hlavní objekty jsou lidé, příležitosti a aktivity, a snese nepřesnost, protože napůl známý zájemce je stejně cenný záznam. Účetnictví eviduje závazky, a proto nesnese nic, co by nesedělo. Autor to shrnuje větou: "nic z toho nejsou vady, jsou to dva správné modely téhož podniku" (Mecanik Dev, dev.to, 16. 9. 2026).

V praxi se to láme na třech místech. Zákazník: jedna firma v CRM je v účetnictví několik odběratelů, protože nakupuje přes více dceřiných společností s různou splatností. Zakázka: jedna položka v CRM je v účetnictví řada měsíčních plateb. Cena: součet nabídky, který spočítal obchodník, se liší od faktury, protože daň a zaokrouhlení žijí v účetním systému a obchod je jen odhadl. Slevu a stav objednávky každá strana chápe po svém.

Nikdo z nich nemá špatně. Rozhodnout musí lidé z obou oddělení u jednoho stolu, ne dodavatel konektoru. Kdo začne stavět dřív, odkládá nejtěžší část na dobu, kdy je změna nejdražší.

Kdo smí který údaj změnit.

Podle autora zdrojového textu funguje vlastnictví po jednotlivých polích, ne po celých záznamech: obchod vlastní jméno kontaktu, telefon a fázi příležitosti, finance kreditní limit, platební podmínky a fakturační adresu (Mecanik Dev, dev.to, 16. 9. 2026). Každé pole teče jedním směrem a druhý systém ho ukazuje jen ke čtení, aby nikdo neopravoval hodnotu, kterou noční přenos přepíše.

Já bych to v české firmě nastavil stejně a přidal jednu věc navíc: párování odběratelů podle IČO. Tam, kde IČO chybí nebo se liší zápis názvu, patří záznam do fronty ke schválení člověkem, ne do automatického sloučení. Špatně sloučené dva různé zákazníky se rozplétají hůř než pár nespárovaných záznamů. Po spárování se uloží dvojice identifikátorů, aby se firma příště nepárovala znovu.

Chcete-li vidět, jak vypadá propojení s konkrétním systémem, přečtěte si, jak se Raynet CRM napojuje na účetnictví, nebo co se dá propojit s Pohodou. Tady jde o to, co musí být dohodnuto před nimi.

Na co se zeptat, než začne vývoj.

Otázky, které z tohoto pohledu rozhodují o tom, jestli propojení obstojí i po měsíci provozu:

1. Který systém vlastní které pole a co se stane, když ho někdo změní na druhé straně?
2. Podle čeho se pozná, že firma v CRM a odběratel v účetnictví jsou tentýž subjekt?
3. Kdy se údaj přenáší a ví o tom uživatel? Autor upozorňuje, že většina stížností na propojení jsou stížnosti na nevysvětlené zpoždění.
4. Kam se dostane záznam, který se nepodařilo přenést, a kdo ho opraví?
5. Kdo se dozví, že přenos selhal, a kdo pravidelně porovnává součty v obou systémech?

Poslední otázku je lepší vyřešit předem. Autor píše, že když srovnání součtů nepostaví firma formálně, postaví ho finance neformálně a bude to tabulka (Mecanik Dev, dev.to, 16. 9. 2026). Souhlasím a dodávám, že takovou tabulku pak nikdo nevlastní.

Co s tím teď.

Pokud CRM nepoužíváte, nebo do účetnictví putuje jen pár dokladů, nepotřebujete mapu vlastnictví ani propojení. Stačí pravidelný export. Jakmile se stejný zákazník nebo zakázka zapisuje na dvou místech a někdo z toho přepisuje čísla, začíná se to vyplácet dohodnout jako první.