ISDOC formát: struktura XML, elementy, verze a validace

ISDOC formát je XML dokument s pevně danou hierarchií elementů: kořenový prvek Invoice, pod ním hlavička dokladu, dva bloky se smluvními stranami (AccountingSupplierParty a AccountingCustomerParty), seznam položek InvoiceLines, rekapitulace daně TaxTotal, souhrnné částky LegalMonetaryTotal a platební údaje PaymentMeans. Struktura je popsaná veřejným XSD schématem, proti kterému lze každý soubor strojově ověřit — buď projde, nebo ne, o výkladu se nediskutuje. Tenhle článek je technický průvodce tou strukturou: co který blok obsahuje, co je povinné, jak se liší .isdoc a .isdocx a proč import nejčastěji spadne. Pokud hledáte spíš obecný úvod — k čemu formát slouží, čím se liší od PDF a jak ho otevřít — začněte u článku Co je ISDOC.

Jak je ISDOC formát strukturovaný

ISDOC je jeden XML dokument s jediným kořenovým elementem, který má deklarovaný jmenný prostor a atribut s verzí schématu. Všechno ostatní je jeho potomek. Hierarchie je striktní: pořadí sourozenců je dané schématem, takže bloky nelze prohodit, i kdyby výsledek dával logicky smysl. Právě tahle přísnost je důvod, proč se ISDOC dá importovat bez interpretace — parser nemusí hádat, co která hodnota znamená, protože ji najde na jednom jediném přípustném místě.

Zjednodušená kostra dokladu vypadá takto. Hodnoty jsou ilustrativní, jmenný prostor a číslo verze si vždy ověřte proti schématu, které používá váš systém:

<?xml version="1.0" encoding="UTF-8"?>
<Invoice xmlns="http://isdoc.cz/namespace/2013" version="6.0.1">
  <DocumentType>1</DocumentType>        <!-- typ dokladu: faktura, dobropis, zálohová -->
  <ID>2026001234</ID>                    <!-- číslo dokladu, jak ho vidí člověk -->
  <UUID>f1a3...</UUID>                   <!-- strojový identifikátor dokladu -->
  <IssueDate>2026-07-26</IssueDate>      <!-- datum vystavení -->
  <TaxPointDate>2026-07-26</TaxPointDate><!-- datum zdanitelného plnění -->
  <VATApplicable>true</VATApplicable>    <!-- je dodavatel plátce DPH? -->
  <AccountingSupplierParty> ... </AccountingSupplierParty>
  <AccountingCustomerParty> ... </AccountingCustomerParty>
  <InvoiceLines> ... </InvoiceLines>
  <TaxTotal> ... </TaxTotal>
  <LegalMonetaryTotal> ... </LegalMonetaryTotal>
  <PaymentMeans> ... </PaymentMeans>
</Invoice>

Z ukázky je vidět dvojí povaha hlavičky. Část elementů je identifikační (ID, UUID), část daňová (TaxPointDate, VATApplicable) a část měnová — pokud je doklad v cizí měně, přibývá kód měny a kurz vůči lokální měně. Datumy jsou vždy v podobě RRRR-MM-DD, žádný český formát s tečkami schéma nepřipouští. Logická hodnota se zapisuje jako true nebo false, ne jako ano/ne nebo jednička a nula. Tyhle drobnosti jsou zdrojem většiny chyb ve vlastních exportech.

Jaké elementy popisují dodavatele a odběratele

Obě smluvní strany mají v ISDOC identickou strukturu — liší se jen názvem obalového elementu. Uvnitř AccountingSupplierParty i AccountingCustomerParty je element Party, a v něm se opakuje stále stejná trojice: identifikace subjektu, obchodní jméno a poštovní adresa rozložená na jednotlivá pole. Pokud je subjekt plátce DPH, přibývá blok s daňovým identifikačním číslem. Rozpad adresy na pole je pro zpracování zásadní — město a PSČ se nemusí parsovat z jednoho řetězce, ale čtou se přímo.

<AccountingSupplierParty>
  <Party>
    <PartyIdentification>
      <ID>12345678</ID>             <!-- IČO dodavatele -->
    </PartyIdentification>
    <PartyName>
      <Name>Dodavatel s.r.o.</Name>
    </PartyName>
    <PostalAddress>
      <StreetName>Dlouhá</StreetName>
      <BuildingNumber>12</BuildingNumber>
      <CityName>Praha</CityName>
      <PostalZone>11000</PostalZone>
      <Country>
        <IdentificationCode>CZ</IdentificationCode>
      </Country>
    </PostalAddress>
    <PartyTaxScheme>
      <CompanyID>CZ12345678</CompanyID>  <!-- DIČ včetně předpony státu -->
    </PartyTaxScheme>
  </Party>
</AccountingSupplierParty>

Praktický důsledek: DIČ patří do bloku daňového režimu, ne do identifikace subjektu, a uvádí se včetně dvoupísmenné předpony státu. IČO naopak jde do PartyIdentification jako holé číslo. Zaměnit tato dvě pole je jedna z nejčastějších chyb vlastních implementací a projeví se tím, že příjemce nespáruje doklad se stávajícím dodavatelem v adresáři. Schéma navíc umožňuje uvést vedle sídla i odlišnou dodací nebo korespondenční adresu, což využívají firmy s více provozovnami a e-shopy s dropshippingem.

Jak jsou v ISDOC zapsané položky faktury

Element InvoiceLines je obal, jednotlivé řádky dokladu jsou v opakujícím se elementu InvoiceLine. Každý řádek nese vlastní pořadové číslo, množství s jednotkou, částku bez daně, částku s daní, vyčíslenou daň, sazbu DPH a popis položky. Redundance je záměrná: soubor obsahuje jak základ, tak daň, tak částku včetně daně, aby si příjemce nemusel nic dopočítávat a mohl místo toho hodnoty zkontrolovat. Právě na téhle kontrole většina vadných souborů selže.

<InvoiceLines>
  <InvoiceLine>
    <ID>1</ID>
    <InvoicedQuantity unitCode="KUS">2</InvoicedQuantity>
    <LineExtensionAmount>2000.00</LineExtensionAmount>              <!-- základ -->
    <LineExtensionAmountTaxInclusive>2420.00</LineExtensionAmountTaxInclusive>
    <LineExtensionTaxAmount>420.00</LineExtensionTaxAmount>         <!-- daň -->
    <ClassifiedTaxCategory>
      <Percent>21</Percent>
      <VATCalculationMethod>0</VATCalculationMethod>
    </ClassifiedTaxCategory>
    <Item>
      <Description>Konzultace, 2 hodiny</Description>
    </Item>
  </InvoiceLine>
</InvoiceLines>

Za pozornost stojí element pro metodu výpočtu daně. ISDOC rozlišuje, jestli se DPH počítá zdola ze základu, nebo shora z částky včetně daně — a obě metody dávají u některých čísel výsledek lišící se o haléře. Když se odesílatel a příjemce v metodě neshodnou, rozdíl se nasčítá přes všechny řádky a rekapitulace přestane sedět. Jednotka v atributu unitCode je textová (kus, hodina, kilogram) a schéma ji nevaliduje proti pevnému číselníku, takže si ji každý systém mapuje po svém.

Jak ISDOC popisuje DPH a celkové částky

Rekapitulace daně je v TaxTotal a člení se po sazbách do opakujících se podbloků, souhrn celého dokladu je pak v LegalMonetaryTotal. Pro každou použitou sazbu vzniká jeden podblok se základem daně, vyčíslenou daní a částkou včetně daně. Součet těchto podbloků musí odpovídat součtu řádků v InvoiceLines — a právě tuhle rovnost si importní rutiny kontrolují nejtvrději, protože nesedící rekapitulace znamená chybně přiznanou daň.

<TaxTotal>
  <TaxSubTotal>
    <TaxableAmount>2000.00</TaxableAmount>
    <TaxAmount>420.00</TaxAmount>
    <TaxInclusiveAmount>2420.00</TaxInclusiveAmount>
    <TaxCategory><Percent>21</Percent></TaxCategory>
  </TaxSubTotal>
  <TaxAmount>420.00</TaxAmount>          <!-- daň za celý doklad -->
</TaxTotal>

<LegalMonetaryTotal>
  <TaxExclusiveAmount>2000.00</TaxExclusiveAmount>
  <TaxInclusiveAmount>2420.00</TaxInclusiveAmount>
  <PayableRoundingAmount>0.00</PayableRoundingAmount>
  <PayableAmount>2420.00</PayableAmount>  <!-- kolik se reálně platí -->
</LegalMonetaryTotal>

Klíčový element celého dokladu je PayableAmount — částka k úhradě. Není to prostý součet, protože do něj vstupuje zaokrouhlení a případné odečtení už uhrazených záloh; schéma pro zálohy nabízí samostatné elementy. Pokud tedy vidíte, že PayableAmount neodpovídá TaxInclusiveAmount, nemusí jít o chybu: rozdíl bývá právě v zaokrouhlení nebo v zálohovém odpočtu. Chybou je až situace, kdy rozdíl není podložený žádným elementem — pak soubor sice projde validací, ale příjemce ho zpravidla odmítne.

Jaké platební údaje ISDOC nese

Blok PaymentMeans obsahuje bankovní spojení a symboly platby, tedy přesně ta pole, která se jinak přepisují do příkazu k úhradě ručně. Uvnitř najdete číslo účtu s kódem banky, IBAN a BIC pro zahraniční platby, datum splatnosti a variabilní, konstantní i specifický symbol. Součástí je i kód způsobu úhrady, který rozlišuje převod, hotovost, kartu nebo dobírku.

<PaymentMeans>
  <Payment>
    <PaidAmount>2420.00</PaidAmount>
    <PaymentMeansCode>42</PaymentMeansCode>  <!-- převod na účet -->
    <Details>
      <PaymentDueDate>2026-08-09</PaymentDueDate>
      <ID>1234567890</ID>                    <!-- číslo účtu -->
      <BankCode>0800</BankCode>
      <IBAN>CZ6508000000001234567890</IBAN>
      <VariableSymbol>2026001234</VariableSymbol>
    </Details>
  </Payment>
</PaymentMeans>

Doklad může obsahovat víc plateb — typicky když je faktura splatná ve splátkách nebo když dodavatel nabízí úhradu na dva různé účty. Pozor na to, že datum splatnosti je součástí platebního bloku, ne hlavičky dokladu; systémy, které ho hledají v hlavičce, ho prostě nenajdou a doplní si vlastní výchozí lhůtu. Variabilní symbol se velmi často shoduje s číslem dokladu, ale schéma to nevyžaduje — spoléhat na tuhle shodu při párování plateb je proto chyba, která se projeví až u dodavatele s odlišnou číselnou řadou.

Které elementy jsou povinné a které volitelné

Povinné je jádro, které dělá z dokladu daňový doklad; drtivá většina ostatního je volitelná. Bez identifikace dokladu, data vystavení, obou smluvních stran, alespoň jedné položky a souhrnných částek soubor proti schématu neprojde. Naopak volitelné je téměř všechno, co běžnou fakturu jen upřesňuje: odkaz na objednávku a smlouvu, poznámky, kontaktní osoby, dodací adresa, přílohy nebo kód střediska a zakázky.

Tady je ale past, na kterou se v praxi naráží nejčastěji: volitelné podle schématu a volitelné pro váš účetní program nejsou totéž. Soubor může být formálně dokonale validní, a přesto ho cílový systém odmítne, protože v něm chybí údaj, který si vyžaduje pro zaúčtování — nejčastěji DIČ u plátce DPH, jednotka u položky nebo bankovní spojení. Validita je tedy nutná podmínka, ne dostatečná. Když ladíte vlastní export, počítejte s druhým kolem ladění proti konkrétnímu příjemci.

Jaké verze ISDOC formátu existují a co je isdocx

V oběhu jsou řady 5.x a 6.x; novější revize jsou vůči starším zpětně kompatibilní a číslo verze najdete přímo v atributu kořenového elementu. Novější verze přidávaly hlavně nepovinné elementy — rozšíření o další typy dokladů, přesnější popis záloh a doplňující identifikátory. Základní kostra se nemění, takže parser napsaný proti starší verzi zpravidla přečte i novější soubor a jen ignoruje elementy, které nezná. Když import hlásí neznámou verzi, problém bývá na straně staršího účetního programu.

Čím se liší isdocx od isdoc

isdocx není jiná verze formátu, ale ZIP kontejner, ve kterém je tentýž XML soubor plus přílohy. Nejčastější přílohou je PDF vizualizace dokladu, tedy jak by faktura vypadala vytištěná; dál se přibalují výkazy práce, dodací listy nebo předávací protokoly. Data jsou v obou variantách identická. Prakticky to znamená, že .isdocx si můžete přejmenovat na .zip, rozbalit a s XML uvnitř dál pracovat úplně stejně. Pokud vyvíjíte import, ošetřete obě přípony — odesílatelé mezi nimi přepínají podle toho, jestli zrovna mají přílohu.

Jak ISDOC validovat a co dělat, když neprojde

ISDOC se validuje proti oficiálnímu XSD schématu — libovolným XML validátorem, který umí načíst schéma odpovídající jmennému prostoru dokumentu. Postačí běžný XML editor, knihovna v jakémkoli jazyce nebo validační nástroj dodávaný spolu se schématem. Validace odhalí strukturální chyby: chybějící povinný element, špatné pořadí, neplatný datový typ nebo hodnotu mimo povolený číselník. Neodhalí ale chyby početní — schéma nekontroluje, že součet řádků odpovídá rekapitulaci daně.

Když soubor neprojde, postupujte odspodu. Nejdřív ověřte, že je dokument vůbec dobře utvořené XML a že deklarované kódování odpovídá skutečnému obsahu. Pak zkontrolujte jmenný prostor na kořenovém elementu — chybějící nebo překlepnutý xmlns shodí validaci hned na prvním řádku a chybová hláška přitom bývá matoucí. Teprve potom řešte konkrétní elementy, na které validátor ukazuje. Pokud soubor projde a import přesto selže, chyba je v obsahu, ne ve struktuře — a nejrychlejší cesta k odpovědi je porovnat problémový soubor s dokladem, který ze stejného systému projít umí.

Kde najít oficiální dokumentaci a XSD schéma

Formát spravuje ICT Unie a autoritativním zdrojem je oficiální web standardu na doméně isdoc.cz. Najdete tam ke stažení XSD schéma jednotlivých verzí, dokumentaci popisující význam elementů, ukázkové soubory a prohlížeč ISDOCReader pro vizuální kontrolu. Schéma je licenčně volné, takže ho můžete použít i v komerční implementaci bez poplatků. Uvádět tu přímé odkazy na jednotlivé soubory nemá smysl — jejich adresy se mezi revizemi mění, spolehlivější je vyjít z rozcestníku standardu.

Druhý zdroj, který se vyplatí mít po ruce, je dokumentace vašeho účetního systému. Výrobci obvykle publikují, kterou verzi ISDOC umí načíst, které nepovinné elementy skutečně zpracují a které naopak zahodí. Tahle informace vám ušetří hodiny hledání, proč se do systému nedostalo středisko nebo číslo objednávky, přestože je v souboru korektně vyplněné. Souvislost s evropskou normou pro elektronickou fakturaci řeší podrobněji článek Co je ISDOC.

Jaké chyby ve struktuře ISDOC se opakují nejčastěji

Nejčastější problémy nejsou exotické — opakují se pořád ty samé. První je nesedící rekapitulace DPH: součet daně z řádků se liší od TaxTotal o haléře kvůli odlišné metodě zaokrouhlování nebo výpočtu shora versus zdola. Druhá je kódování: soubor deklaruje UTF-8, ale reálně je uložený ve Windows-1250, takže se rozsypou háčky v názvech firem a položek — a někdy až tím shodí parser hned na začátku čtení.

Třetí chyba jsou desetinná místa. Částky se v XML zapisují s tečkou jako oddělovačem, ne s čárkou, a bez oddělovačů tisíců; hodnota jako 1 250,00 je neplatná. Čtvrtá je chybějící povinný element, typicky DIČ u plátce DPH nebo jednotka u položky. Pátá, o něco méně častá, je špatné pořadí elementů — schéma vyžaduje pevnou posloupnost a generátor, který skládá XML řetězením textu místo přes XML knihovnu, ji poruší velmi snadno.

Jak ISDOC zapadá do zpracování dokladů v Lyxe

Lyxa umí ISDOC číst i exportovat, takže strukturovaný doklad projde bez vytěžování a papírový nebo PDF doklad se do stejné struktury převede. Když dodavatel pošle .isdoc, data se načtou přímo z elementů a není co rozpoznávat. Když přijde sken nebo PDF, Lyxa doklad vytěží — typicky za 30 sekund a s přesností 97 % — a výsledek pak putuje do účetního systému stejnou cestou jako nativní ISDOC.

Export míří do běžných českých účetních systémů: Pohoda, Money S3, ABRA Flexi, iDoklad, Fakturoid, Helios Red a Duel. Praktický přínos pro účetní kancelář je v tom, že nemusí řešit, v jakém formátu doklad přišel — smíšený vstup se sjednotí ještě před zaúčtováním. Pokud teprve zvažujete, jestli po dodavatelích ISDOC chtít, přečtěte si nejdřív obecný přehled v článku Co je ISDOC a rozhodujte se podle toho, kolik dokladů od nich měsíčně chodí.