Co je ISDOC: český formát elektronické faktury a jak ho zpracovat

ISDOC je český otevřený formát elektronické faktury založený na XML. Doklad v něm není obrázek ani text, ale strukturovaná data: dodavatel, IČO, DIČ, jednotlivé položky, sazby DPH, datum splatnosti a variabilní symbol jsou uložené v pojmenovaných polích. Účetní software je proto přečte přímo — bez opisování a bez OCR. Soubor má příponu .isdoc, případně .isdocx, což je ZIP kontejner, ve kterém je vedle XML dat přibalené i PDF pro lidské čtení. ISDOC vznikl v roce 2008 z iniciativy sdružení SPIS (dnes ICT Unie) jako společný standard tuzemských výrobců ekonomických systémů a od té doby ho podporuje drtivá většina českých účetních programů.

Proč ISDOC vznikl a kdo za ním stojí

ISDOC vznikl proto, že si česká faktura do té doby nerozuměla sama se sebou. Každý ekonomický systém uměl exportovat vlastní formát a příjemce ho musel buď ručně přepsat, nebo si nechat naprogramovat převodník. Výrobci účetního softwaru se proto dohodli na jediném XML schématu, které bude umět každý z nich — deklarace o společném standardu byla podepsána v roce 2008 a první rozšířená verze formátu nese označení ISDOC 5.2. Ta je dodnes nejpoužívanější a novější revize jsou vůči ní zpětně kompatibilní.

Podstatné je, že ISDOC není proprietární formát jedné firmy. Schéma je veřejné, licenčně volné a implementace nic nestojí. Právě proto se prosadil napříč systémy od Pohody přes Money S3 a ABRA Flexi až po iDoklad a Fakturoid, které ho umí vystavit i přijmout. Pro účetní z toho plyne praktický důsledek: pokud vám dodavatel pošle ISDOC, s vysokou pravděpodobností ho váš program načte, i když oba pracujete v úplně jiném softwaru. To je celý smysl standardu — odstranit dohadování o formátu z běžného provozu.

Jaké verze ISDOC existují a jaký je rozdíl mezi ISDOC a ISDOCX

ISDOC je samotný XML soubor s daty, ISDOCX je ZIP kontejner, ve kterém je tentýž XML soubor plus přílohy. Nejde tedy o dvě konkurenční verze formátu, ale o dva způsoby balení. V .isdocx bývá vedle dat nejčastěji PDF vizualizace faktury, tedy to, jak by doklad vypadal vytištěný, a případně další přílohy: rozpis odpracovaných hodin, dodací list, fotodokumentace nebo protokol o předání. Data jsou v obou případech identická.

V praxi to znamená jednoduché rozhodovací pravidlo. Když vám na faktuře stačí čísla — a u většiny běžných dokladů stačí — je holý .isdoc plně dostačující a menší. Jakmile je ale podstatná i příloha nebo potřebujete mít pro kontrolní účely vizuální podobu dokladu tak, jak ho vystavil dodavatel, žádejte .isdocx. Typicky jde o stavební fakturace, servisní zásahy s výkazem práce a dodávky, kde se ceny odvozují z odsouhlaseného soupisu.

Co se týče verzí schématu, v oběhu je hlavně řada 5.x a označení verze najdete přímo v atributu kořenového elementu. Pokud vám import někdy selže s hláškou o neznámé verzi, je téměř vždy problém na straně staršího účetního programu, ne v souboru samotném.

Jak vypadá ISDOC soubor uvnitř

Otevřete-li .isdoc v textovém editoru, uvidíte XML. Kořenovým prvkem je Invoice a pod ním hierarchie elementů: AccountingSupplierParty a AccountingCustomerParty nesou identifikaci dodavatele a odběratele včetně IČO a DIČ, InvoiceLines obsahuje jednotlivé položky s množstvím, jednotkovou cenou a sazbou DPH, TaxTotal rekapitulaci daně po sazbách a PaymentMeans číslo účtu a variabilní symbol.

Následující zkrácená ukázka je zjednodušená — reálný soubor obsahuje víc elementů a delší hlavičku jmenných prostorů — ale ukazuje kostru, se kterou se v praxi setkáte:

<Invoice version="5.2" xmlns="http://isdoc.cz/namespace/2013">
  <DocumentType>1</DocumentType>
  <ID>2026000147</ID>
  <IssueDate>2026-07-14</IssueDate>
  <TaxPointDate>2026-07-14</TaxPointDate>
  <VATApplicable>true</VATApplicable>

  <AccountingSupplierParty>
    <Party>
      <PartyIdentification><ID>27082440</ID></PartyIdentification>
      <PartyName><Name>Dodavatel s.r.o.</Name></PartyName>
      <PostalAddress>
        <StreetName>Dlouhá</StreetName>
        <BuildingNumber>12</BuildingNumber>
        <CityName>Praha</CityName>
        <PostalZone>11000</PostalZone>
      </PostalAddress>
      <PartyTaxScheme><CompanyID>CZ27082440</CompanyID></PartyTaxScheme>
    </Party>
  </AccountingSupplierParty>

  <InvoiceLines>
    <InvoiceLine>
      <ID>1</ID>
      <InvoicedQuantity unitCode="hod">8</InvoicedQuantity>
      <LineExtensionAmount>9600</LineExtensionAmount>
      <LineExtensionAmountTaxInclusive>11616</LineExtensionAmountTaxInclusive>
      <ClassifiedTaxCategory>
        <Percent>21</Percent>
        <VATCalculationMethod>0</VATCalculationMethod>
      </ClassifiedTaxCategory>
      <Item><Description>Konzultace</Description></Item>
    </InvoiceLine>
  </InvoiceLines>

  <TaxTotal>
    <TaxSubTotal>
      <TaxableAmount>9600</TaxableAmount>
      <TaxAmount>2016</TaxAmount>
      <TaxInclusiveAmount>11616</TaxInclusiveAmount>
      <TaxCategory><Percent>21</Percent></TaxCategory>
    </TaxSubTotal>
    <TaxAmount>2016</TaxAmount>
  </TaxTotal>

  <LegalMonetaryTotal>
    <TaxExclusiveAmount>9600</TaxExclusiveAmount>
    <TaxInclusiveAmount>11616</TaxInclusiveAmount>
    <PayableAmount>11616</PayableAmount>
  </LegalMonetaryTotal>

  <PaymentMeans>
    <Payment>
      <PaidAmount>11616</PaidAmount>
      <PaymentMeansCode>42</PaymentMeansCode>
      <Details>
        <PaymentDueDate>2026-07-28</PaymentDueDate>
        <ID>2701234567</ID>
        <BankCode>0100</BankCode>
        <VariableSymbol>2026000147</VariableSymbol>
      </Details>
    </Payment>
  </PaymentMeans>
</Invoice>

Projděme si, co jednotlivé bloky znamenají. Hlavička nese typ dokladu (DocumentType s hodnotou 1 označuje běžnou fakturu, jiné hodnoty se používají pro dobropisy a zálohové doklady), číslo faktury v ID, datum vystavení a datum uskutečnění zdanitelného plnění v TaxPointDate. Příznak VATApplicable říká, zda je vystavitel plátcem DPH — u neplátce je zde false a rekapitulace daně chybí. Už z těchto pár polí sestaví účetní systém většinu hlavičky přijaté faktury.

Blok stran je nejdůležitější pro párování s adresářem. PartyIdentification/ID obsahuje IČO, PartyTaxScheme/CompanyID DIČ. Účetní program podle IČO dohledá dodavatele ve svém číselníku a pokud ho nenajde, obvykle nabídne založení nového z údajů v souboru. Analogický blok AccountingCustomerParty nese vaše údaje a je to první místo, kde se pozná omyl — pokud v něm sedí cizí IČO, dodavatel poslal fakturu špatnému příjemci.

Položky v InvoiceLines jsou to, co u PDF stojí nejvíc práce. Každá položka má množství s jednotkou v atributu unitCode, částku bez daně, částku s daní a vlastní sazbu v ClassifiedTaxCategory/Percent. Element VATCalculationMethod určuje, zda se daň počítá zdola (z částky bez daně) nebo shora (z ceny včetně daně) — právě tohle je zdroj haléřových rozdílů, které při ručním přepisu neodhalíte. Na položce může být i členění na střediska nebo zakázky, pokud ho dodavatel vyplňuje.

Rekapitulace DPH v TaxTotal je samostatný element, ne dopočet. Pro každou sazbu je zde základ, daň a částka včetně daně, a nad nimi celkový TaxAmount. Když má doklad dvě sazby, jsou zde dva bloky TaxSubTotal. LegalMonetaryTotal pak nese součty za celý doklad a PayableAmount je částka k úhradě — tedy to jediné číslo, které při vytěžování z obrázku hledáte očima.

Platební údaje v PaymentMeans obsahují číslo účtu, kód banky, variabilní symbol a datum splatnosti. Z nich vzniká příkaz k úhradě bez jediného překlepu. Klíčový rozdíl proti PDF: v ISDOC nemá částka žádnou pozici na stránce. Nehledá se „vpravo dole pod čarou“, ale čte se z pole. Tím padá celá kategorie chyb, kterou přináší rozpoznávání obrazu — přehozené řády, zaměněná nula a písmeno O, špatně přiřazená sazba u dokladu se dvěma sazbami. Data jsou buď validní podle schématu, nebo soubor neprojde.

Jak otevřít ISDOC soubor

ISDOC otevřete třemi způsoby podle toho, co s ním potřebujete udělat. Pro pouhé prohlédnutí slouží bezplatná aplikace ISDOCReader, která XML vykreslí do podoby běžné faktury; u .isdocx stačí přípona přejmenovaná na .zip a uvnitř najdete PDF náhled. Pro zaúčtování soubor neotvírejte vůbec — importujte ho rovnou do svého účetního systému, protože ruční opis dat z náhledu maří celý smysl formátu. Pro kontrolu struktury poslouží libovolný textový editor nebo XML validátor.

Časté nedorozumění: dvojklik na .isdoc ve Windows nemusí udělat nic, dokud nemáte nainstalovanou aplikaci, která si příponu zaregistruje. Neznamená to, že je soubor poškozený. Pokud potřebujete jen rychle zkontrolovat obsah a nechcete nic instalovat, přetáhněte soubor do okna prohlížeče — ten XML zobrazí jako strom a údaje si v něm přečtete, byť neformátované.

Pozor na jednu praktickou věc: ISDOC přijatý e-mailem je plnohodnotný daňový doklad a platí pro něj stejná pravidla archivace jako pro papír, tedy uchování po dobu deseti let podle zákona o DPH. Archivovat je nutné samotný soubor, ne jeho vytištěnou podobu. Vytištěný ISDOC je jen vizualizace dat, nikoli originál — a při kontrole je rozhodující to, co je v souboru.

ISDOC vs. PDF faktura vs. papír

Rozdíl mezi formami dokladu je v tom, kolik práce zbývá na účetní. Papír je nejhorší varianta — doklad se musí naskenovat nebo vyfotit a pak celý přepsat, přičemž originál je nutné fyzicky uskladnit. PDF faktura odpadá skladování, ale data v ní pořád nejsou strukturovaná: PDF je popis vzhledu stránky, ne obsahu. Software z něj musí údaje vytěžit — dnes už spolehlivě, ale vždy s nenulovou chybovostí, kterou někdo musí zkontrolovat. ISDOC je jediná z těch forem, kde nedochází k žádné interpretaci: co je v poli, to se naimportuje.

V praxi ale kancelář nemá luxus vybrat si. Klienti posílají všechno dohromady — pár dodavatelů ISDOC, většina PDF, někdo fakturu vypíše do těla e-mailu a někdo pořád posílá papír vyfocený mobilem. Rozumný postup je zpracovat ISDOC nativně a zbytek vytěžit, ne čekat, až se všichni dodavatelé přeorientují.

ISDOC a e-faktura podle EN 16931

ISDOC je český standard, kdežto EN 16931 je evropská norma pro elektronickou fakturaci, kterou zavedla směrnice 2014/55/EU pro veřejné zakázky. Norma definuje takzvaný sémantický datový model — seznam údajů, které musí e-faktura obsahovat — a jeho zápis ve dvou syntaxích, UBL 2.1 a UN/CEFACT CII. ISDOC z UBL vychází, takže obsahově se s normou z velké části překrývá, ale není s ní formátově totožný.

Pro běžnou tuzemskou fakturaci mezi firmami zůstává ISDOC dostatečný. Rozdíl začne být podstatný ve chvíli, kdy fakturujete do zahraničí nebo veřejnému zadavateli, který přijímá pouze formát podle EN 16931 — typicky profil Peppol BIS. Většina českých systémů proto dnes umí obojí a mezi formáty převádí. Pokud tedy plánujete expanzi nebo se chystáte na zakázky pro veřejný sektor v EU, neřešte to jako volbu mezi formáty, ale jako otázku, zda váš systém umí vystavit i evropskou variantu.

Jak naimportovat ISDOC do účetního systému

Import ISDOC je ve všech běžných českých systémech otázkou několika kliknutí v agendě přijatých faktur. ISDOC podporují mimo jiné Pohoda, Money S3, ABRA Flexi, iDoklad, Fakturoid, Helios i Duel — hledejte volbu pojmenovanou „Import ISDOC“, „Načtení elektronické faktury“ nebo podobně v nabídce přijatých dokladů, případně v sekci datové komunikace či datové výměny. Konkrétní název a umístění se mezi verzemi liší, takže je spolehlivější hledat podle klíčového slova „ISDOC“ v nápovědě programu než podle popisu cesty z internetu.

Systém ze souboru založí přijatou fakturu včetně položek a rekapitulace DPH. Zbytek práce zůstává stejný jako u papíru: doplnit předkontaci, ověřit, že IČO a DIČ dodavatele sedí s registrem, a zkontrolovat, jestli stejná faktura už v systému neleží. Právě tyhle tři kroky jsou důvod, proč sám import ISDOC ušetří míň času, než by se zdálo — odpadne přepis, ne kontrola.

Řada systémů umí ISDOC načítat i dávkově z určené složky nebo přímo z e-mailové schránky. Pokud dostáváte ISDOC pravidelně od několika dodavatelů, vyplatí se to nastavit hned — jednorázový import po jednom souboru se u vyššího objemu stane úzkým hrdlem stejně jako ruční přepis.

Jak přimět dodavatele posílat ISDOC

Nejrychlejší cesta k vyššímu podílu ISDOC nevede přes technické řešení, ale přes jednu větu v objednávce nebo v dodatku ke smlouvě: „Faktury zasílejte ve formátu ISDOC na adresu …“. Většina dodavatelů používá systém, který ISDOC umí vystavit jedním zaškrtnutím, jen ho ve výchozím nastavení nemá zapnutý — pošle PDF, protože to je přednastavená volba, ne protože by jinak nemohl.

U klíčových dodavatelů s desítkami dokladů měsíčně se to vyplatí řešit adresně. U dlouhého ocasu drobných dodavatelů to smysl nedává; tam je levnější doklad vytěžit, než vést korespondenci o formátu. Realistický cíl proto není „všechno v ISDOC“, ale převést na strukturovaná data ty dodavatele, kteří tvoří většinu objemu — u typické kanceláře je to několik desítek firem z mnoha stovek.

Nejčastější problémy při práci s ISDOC

Systém odmítne import. Nejčastější příčinou je novější verze schématu, než jakou váš program zná. Pomůže aktualizace účetního softwaru, nebo požádat dodavatele o export ve verzi 5.2, kterou umí prakticky všechno. Druhá častá příčina je banální: soubor se poškodil při přeposílání e-mailem, typicky když ho někdo otevřel, uložil a poslal dál. Vyžádejte si originál znovu, ideálně jako přílohu bez dalších úprav.

Nesedí rekapitulace DPH. Pokud součet TaxSubTotal neodpovídá celkovému TaxAmount nebo se rozchází se součtem položek, jde o chybu na straně vystavitele — obvykle způsobenou mícháním výpočtu daně zdola a shora u dokladu s více sazbami. V ISDOC ji poznáte okamžitě, protože rekapitulace je samostatný element a nemusíte ji dopočítávat z obrázku. Doklad v takovém případě nezaúčtujte a vyžádejte si opravný, protože nesprávná rekapitulace se propíše do kontrolního hlášení.

Chybí příloha. Dodavatel poslal holý .isdoc bez PDF, přestože je pro schválení potřeba i výkaz práce nebo dodací list. Řešením je požádat o .isdocx, který přílohy nese v jednom kontejneru; jinak se příloha ztratí a schvalovací kolečko se zasekne.

Problémy s kódováním a diakritikou. ISDOC používá UTF-8. Rozsypaná diakritika v názvu dodavatele nebo v popisu položky obvykle znamená, že soubor prošel nástrojem, který ho převedl do jiného kódování. Bezpečnější než opravovat text ručně je vyžádat si soubor znovu.

Duplicitní zaúčtování. Nastane, když stejnou fakturu dostanete v ISDOC i v PDF a zaúčtujete obojí — každý kanál o sobě neví. Stejné riziko vzniká, když ISDOC importuje jeden člověk a PDF zpracovává druhý. Kontrolu duplicit proto nastavte na kombinaci IČO dodavatele, čísla dokladu a částky, ne jen na název souboru.

Dodavatel posílá ISDOC jen na vyžádání. Někteří dodavatelé mají ISDOC skrytý v zákaznickém portálu a v e-mailu posílají výhradně PDF. Stojí za to se jednou zeptat — bývá to otázka jednoho nastavení v jejich systému a nemusíte kvůli tomu stahovat soubory z portálu ručně.

Co dělat, když dodavatel ISDOC neumí

Realisticky vzato zůstane většina vašich přijatých dokladů ještě dlouho v PDF nebo jako fotka z mobilu. Odpověď na to není tlačit na formát u všech dodavatelů, ale zajistit, aby doklady bez strukturovaných dat procházely stejným procesem jako ISDOC — tedy se stejnou kontrolou dodavatele, stejnou detekcí duplicit a stejným exportem do účetního systému. K tomu slouží vytěžování: software z PDF nebo fotky přečte dodavatele, částky, sazby DPH, variabilní symbol i splatnost a předá je dál ve stejné podobě, v jaké by dorazily z ISDOC.

Prakticky to znamená rozdělit dodavatele na dvě skupiny. U těch, kteří tvoří většinu objemu, se vyplatí jednorázově vyjednat ISDOC. U zbytku dává větší smysl nechat doklady vytěžit a už se formátem nezabývat. Podíl ISDOC tak můžete zvyšovat postupně, aniž byste kvůli tomu museli měnit způsob práce nebo držet dva oddělené procesy.

Jak ISDOC zpracovává Lyxa

Lyxa řeší celou vstupní frontu jedním kanálem. ISDOC přečte nativně z pole, PDF a fotky vytěží — vytěžení jednoho dokladu trvá zhruba 30 sekund a přesnost dosahuje 97 %, bez nutnosti nastavovat šablony pro jednotlivé dodavatele. Doklady jí pošlete e-mailem nebo přes WhatsApp, což pokrývá i klienty, kteří nic jiného než mobil neotevřou.

U každého dokladu Lyxa navíc ověří IČO a DIČ proti registru ARES a upozorní na duplicitu, pokud stejnou fakturu už jednou dostala. Výsledek exportuje do Pohody, Money S3, ABRA Flexi, iDokladu, Fakturoidu, Helios Red a Duelu, takže na konci máte doklady ve svém systému bez ohledu na to, v jakém formátu dorazily.

Praktický přínos je v tom, že nemusíte držet dva režimy práce. Bez jednotného vstupu se ISDOC importuje jednou cestou, PDF druhou a fotky z mobilu třetí — a kontrola duplicit se rozpadne, protože každý kanál o sobě neví. Když všechno prochází jedním místem, platí stejná kontrola IČO proti ARES i stejná detekce duplicit na celý objem dokladů, ne jen na tu část, která přišla ve strukturovaném formátu. Podíl ISDOC pak můžete zvyšovat postupně, aniž byste kvůli tomu měnili proces.