API integrace: jak propojit účetní systém s e‑shopem a CRM

13. července 2026 · Ing. Martin Procházka · ai

API integrace bez bolesti: nauč se propojit účetní systém s e‑shopem a CRM, automatizuj faktury, platby i sklad. Prakticky, s tipy a příklady.

API integrace: jak propojit účetní systém s e‑shopem a CRM

Sedíš nad výpisem z banky a ručně spáruješ platby s objednávkami? Fakt super zábava, že. A pak ti přijde reklamace, protože doklad z CRM neodpovídá faktuře v účetnictví. Hádáš se s tabulkou a přísaháš, že to příště uděláš líp. Přesně. Řeší to API integrace.

API integrace ti propojí účetní systém s e‑shopem a CRM tak, aby doklady, platby a zákazníci běhali sami. Bez kopírování, bez chyb, bez drama.

Co přesně znamená API integrace a proč tě má zajímat?

API integrace je automatizované napojení dvou (nebo více) systémů přes jejich rozhraní – Application Programming Interface. Prakticky: e‑shop vytvoří objednávku, CRM přidá zákazníka, účetnictví vystaví fakturu, banka pošle notifikaci o platbě a všechno se samo spáruje. Když to funguje, nepoznáš, že se „něco” děje. Prostě jedeš.

Méně ruční práce. Mnohem méně.
Méně chyb. A když se něco pokazí, víš kde.
Lepší cash flow – faktury odchází hned, párování plateb je automat.
UX zákazníka: bleskové potvrzení objednávky, faktura v mailu, status v klientské zóně.

💡 Tip: Nezačínej integrací všeho najednou. Vem největší bolest – třeba faktury z objednávek – a zautomatizuj jen to. Za týden uvidíš, jak moc se ti uvolnily ruce.

Jak funguje datový tok mezi e‑shopem, CRM a účetnictvím?

Bez mapy se ztratíš. Tohle je základní flow, které držím roky:

E‑shop přijme objednávku → uloží ji a přes webhook pošle událost.
CRM vytvoří/aktualizuje kontakt a obchodní případ.
Účetní systém z objednávky vygeneruje zálohovku nebo rovnou fakturu.
Platební brána/banka pošle informaci o úhradě.
Účetnictví spáruje platbu s fakturou, e‑shop/CRM aktualizuje stav.
Sklad se průběžně synchronizuje (rezervace, výdejky, dobropisy).

Tvoje role? Definovat přesná pravidla a edge casy: kdy záloha, kdy rovnou daňový doklad, jak řešit nedostupné zboží, co s dobírkou, co s B2B cenami.

Jak připravit API integraci krok za krokem (bez chaosu)

1) Seznam dat a odpovědností

Rozděl si, co je „master” a co je „slave”:

Zákazníci: master CRM (nejbohatší profil), účetnictví = evidence pro faktury.
Produkty: master e‑shop (SKU, ceny), účetnictví čte kvůli fakturaci a skladovým pohybům.
Objednávky: master e‑shop, účetnictví generuje doklady.
Platby: master banka/platební brána, účetnictví je spotřebitel.

2) Mapa polí a transformace

Udělej si mapu polí. Jinak budeš lovit bugy týdny. Příklad u faktury:

order.number → invoice.external_id
customer.email → invoice.customer.email
shipping.total_with_vat → invoice.items[shipping].unit_price_gross
payment_method → invoice.tags[payment]

3) Události a webhooky

Definuj, co spouští akci:

order.created → vytvoř zálohovou fakturu
order.paid → vystav daňový doklad/konvertuj zálohu
order.cancelled → vystav dobropis
product.updated → aktualizuj ceník v účetnictví (nebo jen DPH sazbu)

4) SLA a retry strategie

Chceš robustní integraci? Bez retry mechanizmu to nedáš.

Exponenciální backoff (např. 1s, 2s, 4s, 8s, 5 pokusů)
Idempotence (unikátní request-id, aby nevznikly duplicitní faktury)
Dead-letter queue (ruční dořešení chyb)

💡 Tip: Loguj korelační ID napříč systémy (order_id, invoice_id, payment_id). Když zákazník zavolá, dohledáš vše za minutu.

Jaké scénáře API integrace dávají největší smysl?

Fakturace z objednávek e‑shopu

„Objednávka zaplacena? Faktura do minuty v mailu.” Pokud to tak nemáš, zbytečně pálíš důvěru zákazníků a čas účetní. Scénář:

order.created → proforma (zálohovka)
order.paid → daňový doklad
refund.requested → dobropis

Automatické párování plateb

Přijatá platba = aktualizace stavu faktury. Ideálně i s variabilním symbolem a částkou.

bank.webhook → match podle VS/částky
partial payment → částečné uhrazení
overpayment → přeplatek = kredit nebo vratka

Synchronizace kontaktů z CRM

Když obchod uzavře deal v CRM, přeskočí se data do účetnictví bez ručního přepisu. Přenos IČ, DIČ, adres, fakturační měny, splatnosti podle segmentu.

Sklad a B2B ceníky

U B2B to drží cash flow pohromadě. Mnoho firem dělá chybu: integruje pouze objednávky a zapomene na rezervace a stavy skladu. Výsledek? Přesliby, dobropisy, nasupení zákazníci.

Co si pohlídat u DPH, měn a číselníků

DPH sazby a pravidla

Sjednoť číselníky DPH: 0 %, 12 %, 21 % – stejné kódy napříč systémy.
VAT režimy: reverse charge, OSS/IOSS, mimo EU. Každý režim = jasné pravidlo v integraci.
Zaokrouhlování: definuj přesnost a směr (na haléře, bankerské, nahoru).

Měny a kurzy

Master měny je objednávka. Účetnictví přebírá měnu a přepočet dělá kurz k DUZP.
Kurzy: ČNB denní vs. fixní z e‑shopu. Rozhodni a drž konzistentně.

Číselné řady a idempotence

Číselnou řadu drž v účetnictví. E‑shop posílá pouze externí reference.
Idempotentní klíč: invoice.external_id = order.number. Nikdy duplicitně.

Příklad datových struktur a endpointů (ilustrační)

Ne každý účetní systém je stejný, ale logika je podobná. Níže je zkrácený příklad requestu na vystavení faktury na základě objednávky.

POST /api/v1/invoices
{
  "external_id": "ORDER-2026-000123",
  "customer": {
    "name": "ACME s.r.o.",
    "ic": "12345678",
    "dic": "CZ12345678",
    "email": "fakturace@acme.cz",
    "address": {
      "street": "U Příkladu 12",
      "city": "Praha",
      "zip": "11000",
      "country": "CZ"
    }
  },
  "items": [
    {"sku": "SKU-001", "name": "Tričko černé M", "qty": 2, "unit_price": 350.0, "vat_rate": 21},
    {"sku": "SHIP-PPL", "name": "Doprava PPL", "qty": 1, "unit_price": 89.0, "vat_rate": 21}
  ],
  "currency": "CZK",
  "payment_method": "card",
  "due_days": 0,
  "issue_date": "2026-07-13",
  "tax_point_date": "2026-07-13",
  "tags": ["eshop", "paid"],
  "note": "Objednávka #100123 z eshopu"
}

Webhook o přijetí platby může vypadat třeba takto:

POST /webhooks/bank/payment
{
  "payment_id": "BNK-998877",
  "vs": "2026000123",
  "amount": 789.0,
  "currency": "CZK",
  "paid_at": "2026-07-13T10:32:11Z",
  "reference": "ORDER-2026-000123"
}

Bezpečnost a právo: jak nepřepálit GDPR a klíče

OAuth2 nebo tokeny s omezeným rozsahem. Klíče nikdy nenechávej v kódu, použij secret manager.
IP whitelist na webhook endpointy. Podpis událostí (HMAC) a časové okno.
GDPR: minimalizuj data – na faktuře není potřeba celé CRM CRM story, jen povinné náležitosti.
Audit log: kdo co kdy poslal/vystavil/smazal. Věř mi, jednou se to hodí.

Monitoring: jak poznáš, že integrace funguje, i když spíš

Health-check endpointy a metriky (počet zpracovaných událostí, chybovost, latence).
Alerty při pádu webhooku, růstu chyb 5xx/4xx, nárůstu DLQ.
Metriky byznysu: čas od order.created → invoice.issued → payment.matched.

Tabulka pro rychlou orientaci:

Metrika	Cíl	Co když to zhorší?
Čas vystavení faktury od objednávky	< 60 s	Zkontroluj frontu a idempotenci
Podíl ručních zásahů	< 2 % dokladů	Přidej pravidla pro edge casy
Chybovost webhooků	< 0,5 %	Aktivuj retry a podpisy událostí
Nesoulad DPH vs. ceník	0	Sjednoť číselníky a validace

Implementace v praxi: tři modely, které dávají hlavu a patu

A) Přímé napojení e‑shop → účetnictví

Rychlé, levné, minimum mezivrstev.
Minus: při růstu narazíš na limity a edge casy.

Kdy: malý/mid e‑shop, 1–2 země, standardní DPH.

B) E‑shop + integrační mezivrstva + účetnictví + CRM

Mezivrstva (např. serverless nebo iPaaS) řeší mapování, retry, DLQ.
Škáluje, zvládne různé systémy najednou.

Kdy: rosteš, máš více prodejních kanálů, marketplaces.

C) Event-driven architektura

Každá událost je zpráva (order.created, invoice.issued). Systémy jsou méně provázané.
Nejrobustnější, ale potřebuje disciplínu a monitoring.

Kdy: B2B, zahraničí, více měn, vlastní sklady.

Testování: jak ověřit, že faktury sedí a platby se párují

Sandbox účty ve všech systémech. Vytvoř si 10–20 scénářů (dobírka, částečná úhrada, sleva, storno, OSS, reverse charge).
Golden dataset: vzorové objednávky s ručním výpočtem DPH.
Contract testy pro API (schémata, povinná pole, verze).
E2E test: objednávka → faktura → bankovní platba → účetní deník.

Jak to celé rozjet v Doklad.ai (best practice)

Jasně, teď prakticky. Běžný scénář, který nasazuju klientům:

V Doklad.ai vytvoř API klíč s rozsahem „Faktury, Kontakty, Webhooky”.
V e‑shopu nastav webhook na order.created a order.paid, směruj na integrační endpoint.
V integrační vrstvě mapuj data na schéma Doklad.ai a používej idempotentní external_id.
Zapni webhook banky nebo platební brány a ověř podpis.
Otestuj sandboxem: 5 objednávek, 2 vrácení, 1 částečná úhrada.
Přepni do produkce, sleduj metriky, ladíš edge casy první týden.

Pro přenos dokladů do účetnictví externí účetní můžeš použít exporty:

Export účetních deníků (ISDOC/CSV/JSON)
Export saldokonta
Export skladových pohybů

A následný import v účetním softwaru, pokud nejde přímé API napojení.

Nejčastější chyby, které vídám u API integrací (a jak jim předejít)

Dvojité doklady kvůli chybějící idempotenci. Léčba: external_id a kontrola před vložením.
Špatné sazby DPH po synchronizaci ceníků. Léčba: pouze jedna autorita pro DPH kódy.
Závislost na jednom člověku. Léčba: dokumentace, runbook, ownership v týmu.
Webhook bez podpisu. Léčba: HMAC + rotace klíčů.
Ignorovaný retry. Léčba: fronta, backoff, DLQ, alerty.

Příklady pravidel, co si zapiš do integrační logiky

Pokud payment_method = COD (dobírka), vystav fakturu až po potvrzení převzetí.
Pokud country != CZ a VAT_ID je platné, aplikuj reverse charge na služby.
Pokud sleva > 50 %, kontrola minimální marže a ruční approval.
Pokud shipping = Zásilkovna a weight > 10 kg, změň dopravce a pošli notifikaci.

Minimalistický governance: kdo za co ručí

Business owner: definuje pravidla (DPH, měny, splatnost, workflow storna).
Tech owner: API klíče, retry, monitoring, incidenty.
Účetní: kontrola vzorku dokladů, nastavení číselných řad, DPH přiznání.

Bez těchto tří rolí končí integrace v šedé zóně „nějak to funguje”, což je přesně to, co nechceš.

Jak navázat banku a spárování plateb

Napojení banky přes API nebo PSD2 konektory ti uzavře smyčku. Platba dorazí, faktura se označí jako uhrazená, CRM zavře deal.

Základ: variabilní symbol = order number nebo invoice number.
Fallback: fuzzy matching podle částky a účtu plátce.
Vratky: tvorba dobropisu a odeslání bankovního příkazu ke schválení.

Když chceš komfort, přidej i notifikace do Slacku/Teams:

Nová úhrada nad 50 000 Kč
Nezaplacená faktura 3 dny po splatnosti

Výkon a limity API: ať tě netrápí throttling

Respektuj rate‑limits, dávkuj požadavky (batch 50–200 položek podle API).
Cache referenčních dat (sazby DPH, produkty) na 5–15 minut.
Pagination u exportů – táhni jen změny dle updated_since.
Webhooky jsou signál, ne transport dat – data si doťáhni přes GET detailu.

Kolik to stojí a kdy se integrace zaplatí?

Upřímně: záleží na rozsahu. Ale čísla mám rád:

1000 objednávek/měsíc, ruční vystavení a párování 2–3 min/objednávka.
Automatizace ušetří 35–45 hodin měsíčně.
Při sazbě 600 Kč/h je to 21–27 tisíc Kč/měsíc. Integrace je rázem levná.

Závěrem: API integrace není luxus, je to nutnost

Ruční práce v účetnictví a e‑shopu je daň za odkládání. API integrace ti dá rychlost, méně chyb a klid v hlavě. Začni jedním tokem (objednávka → faktura), přidej platby a CRM, a za měsíc nebudeš chtít zpátky. A když budeš chtít jistotu, Doklad.ai ti s tím pomůže – od webhooků po exporty.

Klíčové slovo dne? API integrace. Ať ti vydělává, ne překáží.

Časté otázky

Jak propojit účetní systém s e‑shopem, když nemám programátora?

Můžeš použít iPaaS nástroje (Make, Zapier) nebo hotové konektory. Začni jednoduchým tokem: objednávka → faktura. Až to poběží, přidej párování plateb. Když narazíš na limit, oslov integrátora na pár hodin.

Jak vyřešit párování plateb bez přímého bankovního API?

Využij exporty výpisů (CSV) a denní import do účetnictví. Shodu hlídej podle VS a částky, chybějící párování řeš pravidly. Lepší je ale webhook od platební brány, který přijde okamžitě.

Co když mám objednávky v EUR a účetnictví v CZK?

Fakturuj v měně objednávky a v účetnictví ulož i kurz k DUZP. Rozdíly z kurzu řeš účetními zápisy. Hlavně měj jasně daný zdroj kurzu (ČNB vs. fixní) a používej ho konzistentně.

Jak ošetřit duplicitní faktury při výpadku e‑shopu?

Používej idempotentní external_id (typicky číslo objednávky) a před vytvořením dokladu v účetnictví vždy ověř, zda už záznam s tímto ID neexistuje. Zabráníš tak duplicitám i při retriích.

Kdy vystavit zálohovou fakturu a kdy rovnou daňový doklad?

U on‑line plateb klidně rovnou daňový doklad po potvrzení platby. U dobírky a bankovního převodu je jistější zálohovka a konverze na daňový doklad po úhradě. Snížíš riziko storen a dobropisů.

Co když měním sazby DPH u produktů v e‑shopu?

Zaveď jediný zdroj pravdy pro DPH kódy a synchronizuj je jedním směrem. Při změně DPH vždy spusť validační job, který zkontroluje, že sazba existuje i v účetnictví, jinak požadavek zamítni s chybou.