Blog SealDoc
Hloubkové články o PDF/A-3, e-fakturaci, auditních stopách a souladu.
Elektronická fakturace v Belgii od roku 2026: co potřebuje vědět každá firma
Belgie nařizuje strukturovanou elektronickou fakturaci přes Peppol od 1. ledna 2026. Co to znamená pro vaši firmu, vaše dodavatele a váš fakturační software.
Číst dáleOd dat k zapečetěnému PDF v jednom API volání
Převod Markdown nebo JSON faktury přímo do PDF/A-3 Factur-X, v jednom API volání. Bez mezikroku, bez nástroje třetí strany, evidence pack v balíku.
Číst dáleDostupnost PDF/UA-1, ve výchozím stavu zapnutá, přes API
Od vstupu Evropského aktu o přístupnosti v platnost dne 28. června 2025 musí být každý PDF určený zákazníkům, který banka, telco či e-commerce firma odesílá, přístupný pro čtečky obrazovky. SealDoc nyní produkuje hybridní dokumenty PDF/A-3 + PDF/UA-1 přes `/api/documents/generate` a `/api/invoices/generate` s jediným dodatečným polem.
Číst dáleČasté validační chyby Peppol BIS 3.0 a jak je opravit
Schematron validace Peppol BIS 3.0 produkuje chybové zprávy odkazující na kódy BR, čísla BT a umístění XPath. Tento článek mapuje nejčastější validační selhání na jejich příčiny a opravy, zahrnuje aritmetická pravidla, chyby povinných polí a selhání rozšíření pro jednotlivé země.
Číst dáleJak generovat vyhovující Peppol fakturu pomocí n8n a SealDoc
Průvodce krok za krokem k automatizaci generování Factur-X e-faktur v n8n pomocí uzlů SealDoc. Bez nutnosti psát kód.
Číst dáleFactur-X vs ZUGFeRD vs UBL: praktický průvodce evropskou fakturací
Tři názvy, dva formáty, jedna specifikace pod tím. Jak spolu Factur-X, ZUGFeRD a UBL skutečně souvisejí, kdy použít který a proč většina přeshraničních pipelines musí pracovat se všemi třemi.
Číst dáleFrancouzský mandát pro elektronické faktury: co se mění 1. září 2026
Od 1. září 2026 musí být každá firma ve Francii technicky schopna přijímat strukturované elektronické faktury. Povinnost odesílat se zavádí postupně do roku 2027. Jak kalendář skutečně vypadá, co dělat nyní a jak jsou na tom přeshraniční odesílatelé.
Číst dálePolský KSeF spuštěn 2. dubna 2026: co potřebují vědět přeshraniční odesílatelé
Polský národní systém elektronické fakturace KSeF se stává povinným pro velké daňové poplatníky od 2. dubna 2026, menší daňoví poplatníci následují v roce 2026 a 2027. Co KSeF vlastně je, jak se liší od Peppol a co musejí zahraniční dodavatelé fakturující polským kupujícím nastavit.
Číst dáleTři uzly n8n, jeden archiv připravený na compliance
Jak zapojit SealDoc do n8n workflow, který každé příchozí PDF promění v PDF/A-3 archiv s vloženým Factur-X a časovým razítkem RFC 3161, ve třech propojených uzlech. S funkční konfigurací ke zkopírování.
Číst dálePDF/A-3 vs PDF/A-1: který archivní formát vyžaduje EU elektronická fakturace?
Nařízení EU o elektronické fakturaci vyžadují konkrétně PDF/A-3B. Zde je, proč PDF/A-1 a prosté PDF nestačí a co tento rozdíl v praxi znamená.
Číst dáleRFC 3161 časová razítka: co jsou, proč na nich záleží a kdy jsou ze zákona povinná
RFC 3161 časové razítko prokazuje, že dokument existoval v konkrétní chvíli a od té doby nebyl pozměněn. Zde je, proč to má zásadní význam pro shodu s nařízením EU o elektronické fakturaci a právní archivaci.
Číst dáleXRechnung 3.0: co se změnilo a jak dosáhnout shody
XRechnung 3.0 zavedl nová povinná pole a zpřísnil validaci. Co se změnilo, koho se to týká a jak generovat vyhovující faktury.
Číst dáleZákonné doby uchovávání dokumentů v EU: jaký dokument, jak dlouho, který zákon
Členské státy EU stanovují vlastní požadavky na uchovávání dokumentů nad rámec pravidel EU. Tento článek poskytuje praktický přehled dob uchovávání podle typu dokumentu a jurisdikce pro faktury, smlouvy, záznamy o zaměstnancích a účetní dokumenty v Německu, Francii, Nizozemsku, Belgii a Polsku.
Číst dáleDokumentové pipeline: od DOCX přes PDF/A-3 po podepsaný archiv v jednom API volání
Konverze DOCX na vyhovující archiv PDF/A-3 je vícekrokový proces, kde každý krok může selhat tiše. Tento článek prochází tím, jak vypadá kompletní konverzní řetězec, co se v každém kroku láme a jak vybudovat pipeline, která spolehlivě produkuje ověřitelný archivní výstup.
Číst dáleWorkflowsy dokumentů bezpečné vůči halucinacím: použití AI v právně citlivých kontextech
Systémy AI produkují věrohodně vypadající výstupy, které mohou být věcně nesprávné, aniž by signalizovaly, že je něco špatně. V právně citlivých workflowsech dokumentů to vyžaduje specifická architektonická rozhodnutí. Tento článek popisuje vzory, které dělají generování dokumentů asistované AI bezpečným pro compliance využití.
Číst dáleDokumenty generované AI a právní platnost: mezera v souladu s předpisy
AI dokáže generovat smlouvy, zprávy, faktury a compliance dokumenty rychleji než jakýkoli člověk. Co nedokáže, je zaručit, že výstup bude právně platný. Tento článek zkoumá mezeru v souladu s předpisy mezi textem generovaným AI a právně přijatelnými dokumenty a to, jaká infrastruktura je potřeba k jejímu překlenutí.
Číst dáleDlouhodobá validace PDF: proč dnes vyhovující PDF může selhat při ověření v roce 2035
Soubor PDF/A-3, který dnes správně validuje, může za deset let selhat při ověření, pokud vypršel platnost podpisového certifikátu, řetěz certifikátů TSA razítek již není dostupný nebo kryptografické algoritmy byly zastaralé. Tento článek vysvětluje, co vyžaduje dlouhodobá validace a jak budovat archivy, které zůstanou ověřitelné po desetiletí.
Číst dáleDigitální suverenita v dokumentové infrastruktuře: co to znamená a proč na tom záleží
Digitální suverenita dokumentové infrastruktury znamená kontrolu nad tím, kde jsou vaše dokumenty uloženy, kdo k nim má přístup a zda je můžete načíst a ověřit nezávisle na jakémkoli dodavateli. Tento článek vysvětluje, co skutečná suverenita vyžaduje a kde většina cloudových platforem pro dokumenty selhává.
Číst dáleWORM úložiště a právní blokace: kdy potřebujete archivy pro zápis jednou
WORM úložiště zabraňuje jakékoli úpravě archivovaných dat na úrovni úložiště. Právní blokace pozastavuje mazání dokumentů, které jsou předmětem šetření nebo sporu. Tento článek vysvětluje oba mechanismy, kdy jsou ze zákona povinné a jak se vztahují k integritě hašového řetězce.
Číst dáleDetekce manipulace v archivech dokumentů: jak fungují hašové řetězce
Hašové řetězce dělají manipulaci s archivovanými dokumenty matematicky detekovatelnou. Tento článek vysvětluje, jak funguje řetězení hašů SHA-256, proč je odolné vůči manipulaci a jak se srovnává s jinými mechanismy integrity pro dlouhodobé archivy dokumentů.
Číst dáleŘetězec kontroly pro digitální dokumenty: co skutečně vyžadují auditoři a daňové úřady
Řetězec kontroly digitálního dokumentu znamená schopnost prokázat, co se s ním stalo, v jakém pořadí a kým, od vzniku až po archivaci. Tento článek vysvětluje, co hledají daňové úřady a auditoři a jaké technické mechanismy tyto požadavky splňují.
Číst dáleČasová razítka RFC 3161 vysvětlena: jak učinit digitální podpis právně trvalým
Digitální podpis dokazuje, kdo dokument podepsal. Časové razítko RFC 3161 dokazuje, kdy. Jak fungují důvěryhodná časová razítka, proč je každý dlouhodobý archiv potřebuje a jak jedno ověřit bez nadměrné důvěry v autoritu časového razítka.
Číst dáleCo je balíček právních důkazů a co obsahuje?
Balíček právních důkazů je strukturovaný archiv dokazující, že dokument existoval v konkrétní podobě v konkrétním čase a byl správně zpracován. Tento článek vysvětluje, co obsahuje, kdy ho potřebujete a jaký je rozdíl mezi uložením dokumentu a právně přijatelným důkazem.
Číst dáleChyby validace XML Signature v Peppol
Validace XMLDSig podpisů na Peppol SMP odpovědích je obtížnější, než vypadá. Dynamické prefixy jmenných prostorů, povýšení jmenných prostorů při opětovné serializaci a C14N kanonizace interagují způsoby, které narušují standardní ověřovatelé XML podpisů v .NET a Java.
Číst dáleJak skutečně funguje Peppol SMP a SML discovery
Peppol používá řetězec discovery založený na DNS pro směrování faktur ke správnému přístupovému bodu. Tento článek vysvětluje, jak funguje SML a SMP discovery, co DNS dotaz vrátí a co obsahuje odpověď SMP.
Číst dáleUBL vs CII: kterou syntaxi XML faktury zvolit?
UBL 2.1 a UN/CEFACT CII jsou obě syntaxe XML kompatibilní s EN16931 pro elektronické faktury. Tento článek vysvětluje strukturální rozdíly, které formáty nařizují jakou syntaxi a praktické důsledky pro vývojáře budující fakturační pipelines.
Číst dálePovinnost Peppol v Belgii: co se změnilo 1. ledna 2026
Od 1. ledna 2026 musí každá belgická B2B faktura být odeslána přes síť Peppol ve strukturovaném formátu. Co to v praxi znamená a jak ověřit, zda jsou vaši obchodní partneři připraveni.
Číst dáleJak generovat faktury Peppol BIS 3.0 v C#
Praktický průvodce generováním platných faktur Peppol BIS Billing 3.0 UBL 2.1 v C#, zahrnující povinná pole, nastavení jmenných prostorů, položky řádků, daňové součty a Schematron validaci se Saxon HE.
Číst dálePorozumění EN16931: evropský datový model faktury
EN16931 je evropský standard definující, co musí elektronická faktura obsahovat. Tento článek vysvětluje obchodní termíny, obchodní skupiny, obchodní pravidla a jak se sémantický model mapuje na UBL a CII, z inženýrského pohledu.
Číst dáleFactur-X vs ZUGFeRD vs XRechnung vs Peppol: jaký je mezi nimi rozdíl?
Factur-X, ZUGFeRD, XRechnung a Peppol BIS 3.0 jsou postaveny na stejném základním standardu, ale slouží různým trhům a doručovacím kanálům. Přehledné srovnání v přehledném jazyce.
Číst dáleCo je PDF/A-3 a proč je důležitý pro elektronické faktury
PDF/A-3 je archivační formát PDF, který umožňuje vložit strukturované XML do dlouhodobě čitelné faktury. Co přesně zaručuje, co nezaručuje a proč je výchozím kontejnerem pro Factur-X a ZUGFeRD.
Číst dáleCo je Peppol BIS 3.0? Praktický vývojářský úvod
Peppol BIS Billing 3.0 je standard XML faktur používaný napříč evropskými sítěmi elektronické fakturace. Technický úvod v přehledném jazyce pokrývající UBL, EN16931, SMP discovery a validační úskalí.
Číst dáleZatím žádné články — vraťte se brzy.