68. EPO podání, archív a daňová rekonciliace

Tato kapitola vysvětluje rozdíl mezi výpočtem, vygenerovaným XML, skutečně odeslaným podáním a pozdějším potvrzením správce daně. Tyto stavy se nesmějí zaměňovat: soubor uložený v MyÚčto není sám o sobě důkazem, že byl přijat finanční správou.

Související výpočty jsou popsány v kapitolách Výkazy DPH, Souhrnné hlášení a Daň z příjmů.

68.1 Stavy daňového výstupu

Samostatnou obrazovku otevřeš v Nástroje → EPO podání a archív. Zobrazuje vygenerované snapshoty, výsledek lokální validace, historii předání do EPO, uložené důkazní dokumenty a stav podání. Záznam, ke kterému už existuje EPO pokus, dokument nebo potvrzený stav, nelze smazat.

68.2 Co se v archivu ukládá

Při ostrém exportu se uchovává přesný XML obsah, velikost, SHA-256 otisk, typ formuláře, období, varianta podání a výsledek dostupné validace. Otisk umožňuje později ověřit, že stažený soubor odpovídá archivované verzi.

Při prvním předání nebo nahrání dokumentu se stejný zdrojový XML snapshot uloží také do modulu Dokumenty. Aplikace k němu připojí další nahrané artefakty, například XML stažené z EPO, podepsané potvrzení P7S/P7M nebo PDF doručenku. Každý soubor má vlastní SHA-256 otisk a výsledek dostupného ověření. Automaticky vytvořené názvy obsahují formulář, období, ID archivního snapshotu, čas s mikrosekundami a u EPO dokumentů také ID konkrétního pokusu. Opakované vygenerování DPH za stejné čtvrtletí ani opakovaný stavový dokument proto nepřepíše předchozí soubor.

Přímé rozhraní automaticky uloží podepsaný odchozí balíček, XML odpovědi a vrácené potvrzení P7S. Dokumentované odesílací API neposkytuje ZFO ani renderovaný PDF opis. PDF nebo P7S/P7M získané později z portálu lze přidat přetažením; ZFO zatím není podporovaný typ ručního uploadu.

V nastavení archívu lze vybrat dva kořeny: jeden pro DPH, kontrolní a souhrnné hlášení a OSS, druhý pro DPFO a DPPO. Pod kořenem vzniká automaticky strom rok → měsíc/čtvrtletí → druh formuláře. Bez vlastního nastavení aplikace založí výchozí kořeny DPH a hlášení a Daň z příjmů.

U DPFO vzniká ostré XML jen z finalizovaného neměnného snapshotu. Změna živých dokladů po finalizaci proto nesmí tiše změnit dříve vytvořené podání; oprava se řeší novou revizí, opravným nebo dodatečným přiznáním. Pracovní XML z náhledu není podáním a nearchivuje se jako finální daňový výstup.

U DPHDP3, KH a souhrnného hlášení je archivovaný soubor technickým obrazem vygenerovaného výkazu. Před odesláním vždy porovnej období, typ podání, identifikační údaje a součty s náhledem a související kontrolní sestavou.

68.3 Přímé podání přes EPO API

Přímý režim vytvoří uznávaný elektronický podpis ZAREP, provede test oficiální podatelny a po samostatném potvrzení odešle skutečné podání. Potřebuješ osobní kvalifikovaný certifikát pro elektronický podpis ve formátu P12/PFX se soukromým klíčem. Certifikát patří fyzické osobě, která podání podepisuje; v MyÚčtu jej lze vědomě povolit pro jednu nebo více spravovaných firem.

Jak získat vhodný certifikát

Pro přímé EPO objednej kvalifikovaný certifikát pro elektronický podpis fyzické osoby (případně zaměstnanecký/OSVČ profil), jehož soukromý klíč lze exportovat do souboru P12/PFX. Neobjednávej certifikát pro elektronickou pečeť. Pokud zvolíš čipovou kartu, token, eObčanku nebo jiný kvalifikovaný prostředek QSCD, soukromý klíč obvykle exportovat nelze a do serverového trezoru MyÚčta jej proto nepůjde vložit.

Finanční správa požaduje pro přímé rozhraní třetích stran uznávaný elektronický podpis ZAREP založený na kvalifikovaném certifikátu. V žádosti výslovně zvol vložení identifikátoru klienta MPSV (IK MPSV); nevymýšlej ani nezadávej vlastní identifikátor. Poskytovatel jej ověří nebo zajistí v rámci vydání. Finanční správa uvádí, že IK MPSV není v certifikátu automaticky a jeho vložení je bezplatné.

Praktický postup:

1. Nejrychlejší ověřená cesta je PostSignum – certifikát online. Při online identifikaci může být osobní kvalifikovaný certifikát hotový během několika minut; konkrétní doba závisí na úspěšném ověření a provozu služby. Alternativně vyber kvalifikovaného poskytovatele a produkt pro podpis fyzické osoby: eIdentity, PostSignum – fyzické osoby nebo I.CA – kvalifikovaný certifikát pro ePodpis.
2. Žádost vytvářej na počítači a v uživatelském profilu, ve kterém budeš certifikát přebírat. Zvol uložení klíče v počítači / softwarovém úložišti, nikoli na neexportovatelném QSCD.
3. V žádosti zaškrtni vložení IK MPSV. U eIdentity je volba Use IkMPSV in the certificate přímo v žádosti. Pokud portál vyžádá samostatnou žádost či potvrzení MPSV, postupuj podle pokynu eIdentity nebo registračního místa; do pole se nevkládá rodné číslo ani vlastní text. PostSignum má volbu Vložit Identifikátor klienta MPSV ve formuláři fyzické osoby. I.CA umožňuje IK MPSV zvolit při generování žádosti nebo o něj požádat při vydání na registrační autoritě.
4. Dokonči registraci a ověření totožnosti podle pokynů poskytovatele. U prvního certifikátu počítej s kontrolou osobních dokladů na registračním místě.
5. Certifikát převezmi a nainstaluj ve stejném profilu, ve kterém vznikl soukromý klíč. Samotný veřejný soubor CER/CRT nestačí.
6. Ve Windows otevři správu certifikátů aktuálního uživatele (certmgr.msc), najdi certifikát v Osobní → Certifikáty a zvol Všechny úkoly → Exportovat → Ano, exportovat soukromý klíč → PKCS #12 (.PFX). Zahrň certifikační řetězec, nastav silné jedinečné heslo a soubor ulož jen do zabezpečeného dočasného umístění.
7. Před importem zkontroluj, že PFX obsahuje soukromý klíč, certifikát je platný a určený pro digitální podpis. Po importu do MyÚčta bezpečně ulož zálohu a údaje pro zneplatnění; pracovní kopii z běžné složky smaž.

Užitečné oficiální odkazy Finanční správy:

• ePodatelna Finanční správy
• Elektronická podání pro Finanční správu (EPO)
• Technické požadavky na uznávaný elektronický podpis
• Oficiální popis rozhraní EPO pro třetí strany
• Zjištění stavu podání na portálu MOJE daně

Certifikát prokazuje totožnost podepisující fyzické osoby, ne její oprávnění jednat za každou firmu. Jednatel může podepisovat za společnost v rozsahu svého oprávnění; účetní nebo daňový poradce musí mít odpovídající pověření či plnou moc. Certifikát se u finančního úřadu předem samostatně neregistruje, rozhodující je identita z podpisu a existující právní oprávnění zastupovat daňový subjekt.

Správce instalace musí před použitím nastavit samostatný app.secret_encryption_key. Bez něj MyÚčto soukromý klíč nepřijme. P12/PFX i jeho heslo jsou v databázi uložené pouze šifrovaně a API je nikdy nevrací. Uložení, povolení pro firmu, odstranění, testovací podpis i ostré podání vyžaduje znovu aktuální heslo uživatele a při zapnutém 2FA také TOTP kód. Máš-li přístupový klíč, nahradí tlačítko Ověřit přístupovým klíčem heslo i TOTP naráz — ověření je jednorázové a vázané přímo na tuhle operaci, takže proof z jiné akce ani samotné přihlášení certifikát neodemknou. Cesta přes heslo zůstává dostupná vždy. Šifrované EPO údaje jsou navíc vázané na svůj účel, takže například ciphertext hesla dodejky nelze zaměnit za ciphertext PFX. Při rotaci klíče správce nastaví nový app.secret_encryption_key a původní klíč dočasně ponechá v app.secret_encryption_previous_keys; staré záznamy zůstanou čitelné a nové se už zapisují novým klíčem. Starý klíč lze odebrat až po řízeném přešifrování nebo odstranění všech dat, která jej používají.

Osobní certifikát uložený pro EPO může přihlášený uživatel připojit ke svému profilu v Systém -> Elektronické podpisy a použít ho také pro PDF nebo S/MIME. Nevzniká druhá kopie PFX ani hesla; podpisový profil ukládá pouze vazbu na osobní trezor. Připojení vyžaduje stejné ověření jako výše. Dokud certifikát používá aktivní podpisový profil, nelze ho z trezoru smazat ani odebrat z příslušné firmy.

Správce může pro dodejky nastavit vlastní CA bundle v epo.ca_bundle_path a allowlist SHA-256 otisků podpisových certifikátů EPO v epo.receipt_signer_fingerprints_sha256. Je-li vlastní bundle nastaven, ale není dostupný, ověření selže bezpečně; aplikace nespadne zpět na jiný trust store. Pro zkušební prostředí je kvůli testovacímu certifikátu bez produkčního řetězce povinný samostatný allowlist epo.test_receipt_signer_fingerprints_sha256. Lze jej předat také jako čárkami oddělenou proměnnou MYINVOICE_EPO_TEST_RECEIPT_SIGNER_FINGERPRINTS_SHA256. Bez přesné shody otisku se dodejka pouze archivuje a pokus se automaticky nepotvrdí.

Zkušební prostředí pro vývoj

Instalace může přímé podepsané EPO operace přepnout na veřejné zkušební prostředí Finanční správy. V cfg.php nastav:

'epo_test' => true,

V Dockeru nebo jiné konfiguraci přes proměnné prostředí lze použít MYINVOICE_EPO_TEST=true. Výchozí hodnota v aplikaci i v cfg.sample.php je false.

Po zapnutí míří přímá kontrola s test=1, následné odeslání, vyzvednutí rozsáhlého podání i dotaz na stav na zkus.mojedane.gov.cz. Zkušební podání se na ostrém portálu neprojeví. MyÚčto přesto uloží pokus, podepsaný balíček, odpovědi, dodejku, stavové události a dokumenty; v uživatelském rozhraní je označí jako TEST. Potvrzení ze zkušebního prostředí nikdy nezmění stav archivovaného snapshotu na skutečně podaný.

Asistované otevření formuláře používá vždy ostrý interaktivní portál MOJE daně. Předání pouze předvyplní formulář a samo jej neodešle; právní účinek vzniká až vědomým odesláním uživatelem na portálu.

Každý pokus si ukládá prostředí, ve kterém vznikl. Když správce později epo_test přepne, rozpracovaný pokus se na jiný server nepřesměruje. Odeslání i obnovení jeho stavu se bezpečně odmítne, dokud aktuální konfigurace znovu neodpovídá prostředí uloženému u pokusu. Zkušební prostředí může být dočasně nedostupné kvůli servisu nebo aktualizaci. Technické struktury a rozhraní popisuje dokumentace MOJE daně.

Postup:

1. Otevři Certifikáty EPO, nahraj P12/PFX, zadej jeho heslo a potvrď se — buď přístupovým klíčem, nebo heslem do MyÚčta a případným TOTP. Zkontroluj vlastníka, vydavatele a platnost certifikátu.
2. Pokud certifikát používáš pro další spravovanou firmu, přepni se na ni a certifikát pro ni výslovně povol.
3. V detailu validního XML snapshotu vyber certifikát a klikni Otestovat v EPO.
4. MyÚčto vytvoří připojený podpis PKCS#7 v DER, odešle jej s test=1 a zobrazí všechny zprávy EPO. Test kontroluje podpis, strukturu i věcná pravidla, ale daňové podání nevytvoří. Úspěšný test lze pro ostré podání použít jednou a nejdéle 30 minut. Testovací podepsaný balíček je uložen jen šifrovaně a nelze jej stáhnout ani znovu použít mimo řízený tok. Kontrolní hlášení DPH MyÚčto před podpisem automaticky vloží jako jediný XML soubor do ZIP archivu, jak vyžaduje rozhraní Finanční správy; zdrojový XML snapshot i jeho SHA-256 přitom zůstávají beze změny. Do tohoto okamžiku aplikace certifikát označuje jako Dosud neověřen EPO; samotné načtení PFX neprokazuje jeho kvalifikovanost ani přijatelnost pro EPO.
5. Chyby typu struktura, kritická chyba nebo systémová výjimka musíš odstranit v datech a vygenerovat nový snapshot. Propustná upozornění jsou zobrazena, ale úspěšný test neblokují.
6. Až po úspěšném testu se zpřístupní Podepsat a podat. Znovu se ověř (přístupový klíč, nebo heslo a případný TOTP) a potvrď právně účinné odeslání.
7. MyÚčto automaticky uloží zdrojové XML, ostrý odchozí podepsaný balíček, testovací protokol a P7S potvrzení podatelny. Podací číslo a čas převezme z kryptograficky ověřeného potvrzení. Automatické potvrzení vyžaduje platný certifikační řetězec, identitu Společného technického zařízení správců daně v podpisovém certifikátu a přesnou vazbu na odeslaný CMS balíček.
8. Tlačítkem Obnovit stav EPO lze stáhnout aktuální stav zpracování. U rozsáhlého podání nejprve EPO vrátí identifikátor předání; potvrzení se vyzvedne později stejným tlačítkem. Stejné dotazy bezpečně provádí cron-epo-status s exponenciálním odstupem nejvýše jedné hodiny. Worker zná pouze heslo konkrétního stavu a nikdy nepoužívá PFX ani znovu neodesílá XML.

Pro automatickou kontrolu spusť wrapper každou minutu. Jednotlivý pokus se i tak dotazuje jen podle svého naplánovaného času a po každém neukončeném stavu prodlužuje odstup:

Linux cron:       * * * * * /cesta/k/myucto/cmd/cron-epo-status.sh
Windows Scheduler: C:\cesta\k\myucto\cmd\cron-epo-status.cmd
Docker host cron: * * * * * docker compose exec -T app php api/bin/cron-epo-status.php

Ve Windows nastav opakování úlohy každou minutu. Výsledek každého běhu je v evidenci cronů a wrapper zapisuje denní log do log/cron; při vlastním MYINVOICE_DATA_DIR pod jeho log/cron.

U kontrolního hlášení EPO z bezpečnostních důvodů vrací v dodejce redukovaný obsah. Pokud proto nelze kryptograficky prokázat přesnou shodu s odeslaným CMS, MyÚčto dodejku archivuje, ale pokus ponechá jako Výsledek je nejistý k ruční kontrole; shodu nikdy nepředpokládá pouze podle typu formuláře. Pokud dodejka obsahuje údaje pro stavový dotaz, následné potvrzení přijetí přes epo_stav doplní čas, podací číslo, původního podepisujícího i daňový zámek období.

Zkušební podatelna podepisuje dodejku certifikátem s výslovnou identitou Testovací zařízení – nelze učinit platné podání. MyÚčto v prostředí epo_test vyžaduje platný podpis, tuto přesnou identitu GFŘ, přesnou shodu SHA-256 otisku s testovacím allowlistem a vazbu na odeslaný balíček. Testovací dodejku přitom neprezentuje jako produkčně důvěryhodný řetězec ani jako právně účinné podání.

IK MPSV v kvalifikovaném certifikátu pomáhá EPO spojit podepisující osobu s evidovanou identitou. MyÚčto na jeho nerozpoznání upozorní, ale samo nerozhoduje o oprávnění jednat za konkrétní daňový subjekt. To musí odpovídat skutečnému zastoupení, funkci nebo plné moci.

68.4 Asistované podání přes EPO

1. Dokonči účetní nebo evidenční kontrolu daného období.
2. Vygeneruj XML a ověř, že interní kontrola nehlásí blokující chybu.
3. V Nástroje → EPO podání a archív najdi snapshot a zkontroluj období, formulář, variantu, otisk a stav Validní.
4. Klikni Otevřít a podat v EPO. MyÚčto odešle přesný snapshot na oficiální endpoint finanční správy a otevře předvyplněný formulář. Toto předání samo ještě není podáním.
5. V EPO spusť kontroly, porovnej zobrazené částky a typ podání s MyÚčto a až poté podání odešli.
6. Z EPO stáhni odeslané XML a potvrzení. Přetáhni je do vyznačené plochy detailu podání; složka v Dokumentech se vytvoří automaticky.
7. U podporovaného podepsaného potvrzení aplikace ověří dostupné vlastnosti podpisu a vazbu na archivovaný formulář. Protože samotný důvěryhodný certifikační řetězec ještě neprokazuje identitu EPO pečeti, po kontrole doručenky označ snapshot jako odeslaný ručně.
8. Teprve potvrzené podání používej jako poslední známý stav pro další opravné nebo dodatečné tvrzení.

Dočasný odkaz vrácený EPO má krátkou platnost. Server jej neukládá do databáze ani logu; pouze aktuální prohlížeč si jej ponechá do času expirace. Formulář lze proto po obnovení stránky nebo opětovném otevření MyÚčta obnovit přes Pokračovat do EPO. Po vypršení použij Vytvořit nový odkaz EPO; dosavadní aktivní pokus se v historii označí jako zrušený a vznikne nový.

Samotné stažení XML neposouvá stav na odesláno a nemá nahrazovat ruční zámek období. Po úspěšném podání uzamkni příslušné daňové období k datu přes Měsíční kontrolu, pokud to již neprovedlo řízené workflow firmy.

68.5 Rekonciliace proti skutečně podanému XML

Rekonciliace odpovídá na otázku: „Shoduje se dnešní výpočet MyÚčto s tím, co bylo skutečně odesláno?“ Není to totéž jako kontrola, že dvě interní sestavy čerpají ze stejných dokladů.

DPPO

U DPPO lze importovat podané DPPDP9 XML a porovnat je s výpočtem stejného roku. Systém nejprve tvrdě ověří rok a typ formuláře. Poté zobrazí rozdíly po řádcích, včetně částek, které vznikly ruční úpravou nebo odlišným zaokrouhlením. Importovaný soubor výpočet nepřepisuje; slouží jako nezávislý podklad k vysvětlení rozdílu.

Praktický postup:

1. Vyber stejné období jako v podaném formuláři.
2. Nahraj XML, které bylo skutečně odesláno, nikoli nově vygenerovanou kopii.
3. Projdi všechny rozdíly, zejména výsledek hospodaření, nedaňové náklady, odpisové rozdíly, dary, ztráty a zálohy.
4. Rozdíl vysvětli opravou zdroje, doloženou ruční úpravou nebo identifikací změny, která nastala až po podání.
5. Neshodu nikdy neodstraňuj mechanickým dorovnávacím zápisem bez účetního případu.

DPH, KH, DPFO a pojistné

MyÚčto provádí interní křížové kontroly DPHDP3 proti KH, souhrnnému hlášení, knize DPH a účtu 343. To však není import a porovnání se skutečně podaným XML. U DPFO, DPHDP3, KH, sociálního ani zdravotního přehledu zatím obecná rekonciliace proti podanému souboru v uživatelském rozhraní není.

Pro tato podání uchovej finální XML i potvrzení a při opravě porovnej podané hodnoty s aktuálním náhledem ručně. Rozdíly po podání mohou znamenat pozdě doplněný doklad, změněnou klasifikaci, kurz, datum přijetí nebo ruční zásah provedený přímo na portálu.

68.6 Řádné, opravné a dodatečné podání

• Řádné je první tvrzení za období.
• Opravné nahrazuje předchozí podání před uplynutím lhůty.
• Dodatečné nebo u KH následné navazuje na poslední účinné podání po lhůtě.

Před vytvořením další varianty vždy určuj poslední účinné podání podle potvrzení správce daně, ne podle nejnovějšího souboru v archivu. Vygenerovaný, ale neodeslaný soubor se poslední známou daní nestává.

68.7 Co systém nenahrazuje

• podání na ePortál ČSSZ nebo portály zdravotních pojišťoven,
• právní oprávnění podepisující osoby jednat za konkrétní daňový subjekt,
• kontrolu stavů, které EPO rozhraní neposkytne nebo už na serveru neuchovává,
• odborné rozhodnutí, zda podat opravné nebo dodatečné tvrzení,
• univerzální import a diff všech typů podaných XML,
• kontrolu údajů, které uživatel po importu ručně změnil přímo na portálu.