Jak generovat správné faktury Peppol BIS 3.0 z Česka a Slovenska

Nejčastější důvod, proč faktura z českého nebo slovenského systému neprojde na straně příjemce správně, není chybný formát XML – je to nesoulad mezi tím, jak fakturační software chápe pojmy jako dobropis, vrubopis nebo zálohová faktura, a tím, jak je umí vyjádřit norma EN 16931 a formát Peppol BIS Billing 3.0. Ten zná jen dva typy dokladu, Invoice a CreditNote, a pevný číselník typů dokladu – takže každý lokální pojem se musí namapovat správně, jinak vyjde částka, kterou má zákazník zaplatit, špatně.

Sepsali jsme, jak tyto věci řešíme na našem accesspointu, aby to mohli integrátoři a účetní software zkontrolovat proti vlastní implementaci.

Typy dokladů: nepoužívejte všude kód 380

BT-3 (cbc:InvoiceTypeCode, případně cbc:CreditNoteTypeCode) říká příjemci, o jaký doklad jde. Český i slovenský účetní software rozlišuje víc typů dokladů, než kolik jich běžně vidíme na fakturách posílaných přes Peppol – a defaultní kód 380 pro všechno tuto informaci ztrácí.

Jedna věc integrátory dost často překvapí: BIS 3.0 nemá vlastní typ dokladu pro vrubopis. Musí se poslat jako Invoice s kódem 384 a odkazem na původní doklad přes cac:BillingReference – ne jako CreditNote se záporným zbožím, kterou řada přijímajících systémů odmítne nebo špatně zpracuje.

Platební symboly: VS, KS a SS

Banky a účetní software v Česku a na Slovensku párují platby podle tří symbolů, pro které UBL nemá vlastní pole:

• VS (variabilní symbol) – identifikuje, ke kterému dokladu se platba vztahuje, nejčastěji číslo faktury.
• KS (konstantní symbol) – čtyřmístný kód udávající charakter platby.
• SS (specifický symbol) – desetimístný doplňkový údaj; banky ho čím dál méně podporují (SEPA pro něj nemá pole), ale řada příjemců ho stále očekává.

BT-83 (cbc:PaymentID) je v EN 16931 definováno přímo jako „hodnota spojující platbu s fakturou“ – přesně to, co samotný VS má dělat. Když máme jen VS, patří proto jako holá hodnota přímo tam, bez prefixu a bez cac:PaymentMeans/cbc:InstructionID:

1
2
3
4

<cac:PaymentMeans>
  <cbc:PaymentMeansCode>42</cbc:PaymentMeansCode>
  <cbc:PaymentID>176692026</cbc:PaymentID>
</cac:PaymentMeans>

Strukturovanou kombinaci VS:…;KS:…;SS:… v InstructionID (a jako čitelnou zálohu i v PaymentID ve tvaru VS…/KS…/SS…) používáme až ve chvíli, kdy je potřeba zakódovat víc než jeden symbol najednou – tedy jakmile se objeví KS nebo SS:

1
2
3
4
5

<cac:PaymentMeans>
  <cbc:PaymentMeansCode>42</cbc:PaymentMeansCode>
  <cbc:InstructionID>VS:176692026;KS:0008;SS:1234567890</cbc:InstructionID>
  <cbc:PaymentID>VS176692026/KS0008/SS1234567890</cbc:PaymentID>
</cac:PaymentMeans>

Nejčastější chyba je vynechání VS – platba se pak na účtu příjemce objeví, ale nespáruje se s fakturou, která ji vyvolala. Druhá nejčastější je obalování samotného VS do prefixu VS: a InstructionID, i když žádný KS ani SS není k dispozici – pro běžného (ne-českého/slovenského) příjemce je to jen šum v poli, kde by měla být čistá reference.

Zálohy a jejich odpočet

Standardní tuzemský postup má tři kroky: zálohová faktura (výzva k platbě, kód 386, není daňovým dokladem) → po přijetí platby daňový doklad k přijaté platbě (kód 388, DPH je nutné přiznat do 15 dnů od přijetí úplaty) → po dodání zúčtovací faktura, která musí každou přijatou a zdaněnou zálohu odečíst.

Ten odpočet je v Peppolu pole BT-113, cbc:PrepaidAmount v cac:LegalMonetaryTotal, a musí se promítnout do cbc:PayableAmount podle standardního vzorce (BR-CO-16):

PayableAmount = TaxInclusiveAmount − PrepaidAmount + PayableRoundingAmount

Příklad: zboží za 25 000 Kč + 21 % DPH (30 250 Kč celkem). Na zálohu 10 000 Kč + DPH (12 100 Kč) už byl vystaven a zaplacen daňový doklad. Zúčtovací faktura pak musí obsahovat:

1
2
3
4
5

<cac:LegalMonetaryTotal>
  <cbc:TaxInclusiveAmount currencyID="CZK">30250.00</cbc:TaxInclusiveAmount>
  <cbc:PrepaidAmount currencyID="CZK">12100.00</cbc:PrepaidAmount>
  <cbc:PayableAmount currencyID="CZK">18150.00</cbc:PayableAmount>
</cac:LegalMonetaryTotal>

Bez PrepaidAmount faktura projde validací podle EN 16931 v pořádku – jen bude po zákazníkovi chtít zaplatit celých 30 250 Kč znovu. Pokud zdrojový systém zálohy eviduje (ISDOC to dělá v elementech TaxedDeposits/NonTaxedDeposits), je potřeba jejich součet promítnout do BT-113 při každém exportu, nejen je uvést jako odkaz na doklad.

Dobropis, nebo vrubopis?

Oba pojmy označují opravný doklad, ale v opačném směru:

• Dobropis snižuje dlužnou částku – posílá se jako CreditNote, kód 381.
• Vrubopis dlužnou částku zvyšuje – posílá se jako Invoice, kód 384, protože BIS 3.0 nemá vlastní typ dokladu DebitNote.

Oba by měly nést cac:BillingReference s odkazem na ID původního dokladu, aby ho účetní systém na straně příjemce dokázal spárovat s opravovanou fakturou, a ne ho zpracoval jako samostatný doklad.

VAT Category Code a VATEX: proč nulová DPH nestačí

BT-118 (cbc:ID v cac:TaxCategory) určuje daňový režim dodání – ne to, kolik je na faktuře DPH. Nulová částka DPH sama o sobě neznamená kategorii Z: může jít o osvobozené plnění (E), intrakomunitární dodání (K), vývoz (G), přenesení daňové povinnosti (AE) nebo plnění mimo předmět DPH (O). Kategorii Z použijte jen tam, kde zákon skutečně stanovuje nulovou sazbu.

Pro kategorie jiné než S a Z je pak potřeba uvést důvod – buď kódem VATEX (BT-121, cbc:TaxExemptionReasonCode), nebo textem (BT-120, cbc:TaxExemptionReason), případně oběma. Podle FAQ Finanční správy SR (srpen 2026) se doporučuje uvádět primárně BT-121 a BT-120 jako doplňující text. Základní mapování pro slovenské podmínky:

VATEX je evropský/Peppol číselník, ne slovenský legislativní – ne ke každému paragrafu zákona o DPH proto existuje vlastní kód. Tam, kde nejste jistí konkrétním důvodem v rámci čl. 132, je lepší použít obecný VATEX-EU-132 než hádat konkrétní podkód.

Náš converter z ISDOC do BIS 3.0 (a zpět) toto už rozlišuje: ISDOC nemá vlastní číselník kategorií, ale má strukturovaná pole LocalReverseCharge (řádek v režimu přenesení daňové povinnosti) a VATApplicable (řádek mimo předmět DPH) – ty se teď správně překlápí na AE/O a VATEX kód, místo aby obě skončily jako běžná sazba nebo obecné “osvobozeno”.

Slovenské specifikum: SK CIUS a termín 1. ledna 2027

Slovenská Finančná správa definuje nad rámec EN 16931 / BIS 3.0 vlastní sadu povinných polí (SK CIUS): datum uskutečnění zdanitelného plnění (BT-7), datum splatnosti (BT-9), IČO a IČ DPH dodavatele (BT-30, BT-31), IČ DPH odběratele (BT-48), kompletní adresu obou stran (BT-35/37/38, BT-50/52/53), sazbu DPH (BT-119) a u osvobozených plnění i důvod osvobození (BT-120/121).

Elektronická fakturace přes Peppol je na Slovensku dobrovolná od druhého čtvrtletí 2026 a od 1. ledna 2027 povinná pro všechny plátce DPH, doručovaná přes certifikované accesspointy. Víc jsme psali v článku Slovensko vyřešilo elektronickou fakturaci za nás a v odpovědích na časté otázky k povinné e-fakturaci na Slovensku.

Shrnutí

Pro faktury směřující do Česka a na Slovensko platí, že samotná validita podle EN 16931 nestačí – schéma validaci projde i doklad se špatným typem, chybějícím odpočtem zálohy, bez VS nebo se špatnou kategorií DPH. Kontrolní seznam: opravné doklady mají správný typ (dobropis jako CreditNote/381, vrubopis jako Invoice/384), zálohy se odečítají přes PrepaidAmount, platební symboly jsou v PaymentID/InstructionID, kategorie DPH odpovídá skutečnému daňovému režimu (ne jen výši DPH) a nese odpovídající VATEX kód, a slovenské faktury nesou všechna pole podle SK CIUS. Přesně tohle při generování a validaci faktur na našem accesspointu hlídáme automaticky.

Zdroje: ISDOC – specifikace formátu, Finančná správa SR – e-faktúra, Peppol BIS Billing 3.0