Chyby ve fakturách Peppol: 10 příčin a řešení

Peppol poskytuje standardizovanou infrastrukturu pro výměnu elektronických faktur a dalších obchodních dokumentů. Standardizace však neznamená, že každá transakce proběhne automaticky.

K zamítnutí faktury může dojít z důvodu neplatných údajů, nemožnosti dohledat příjemce, použití nesprávného obchodního procesu nebo odmítnutí faktury kupujícím po doručení. V podnikovém prostředí může příčina problému spočívat kdekoli v rámci systému ERP, mapování faktur, kmenových dat, vyhledávacích služeb Peppol a přístupového bodu.

Tato příručka vysvětluje deset běžných chyb ve fakturách formátu Peppol. Každá část začíná popisem praktického problému srozumitelným jazykem a následně se zabývá příslušnými technickými detaily určenými pro podnikové týmy a týmy zabývající se integrací ERP systémů.

Technický rozsah: Posouzeno podle specifikace Peppol „ BIS Billing “ 3.0, verze 3.0.21, a specifikací OpenPeppol eDelivery dostupných v srpnu 2026. Požadavky a specifikace specifické pro jednotlivé země se nadále mění.

Než začnete s odstraňováním závady, zjistěte, kde k poruše došlo.

Tyto chyby vyžadují různé způsoby řešení. Opětovné odeslání nezměněné faktury neopraví nesprávné údaje. Úprava faktury nepomůže, pokud je registrace příjemce v systému Peppol neúplná. Úspěšné potvrzení o doručení ještě neznamená, že kupující fakturu schválil.

Identifikátor organizace ( Peppol ID ) funguje podobně jako síťová adresa, avšak zadání správného čísla organizace nemusí vždy stačit. Identifikátor musí používat správné schéma a musí přesně odpovídat identifikátoru, pod kterým je příjemce registrován.

I zdánlivě nepodstatný rozdíl – jako například nesprávná předpona, vynechaná počáteční nula nebo použití DIČ namísto národního identifikačního čísla podniku – může způsobit, že systém Peppol nedokáže příjemce najít.

Identifikátor Peppol ukládejte jako řízená kmenová data, nikoli jako volný text. Schéma identifikátoru a jeho hodnota by měly být uchovávány odděleně a před vystavením faktury by měly být ověřeny.

Před odesláním:

Společnost může být registrována v systému Peppol, aniž by byla schopna přijímat všechny typy dokumentů Peppol.

Příjemce může být například registrován pro příjem standardních faktur ve formátu Peppol BIS Billing , ale ne pro konkrétní fakturu ve formátu PINT, objednávkovou zprávu nebo obchodní proces. Adresa Peppol ID je platná, ale požadovaná schopnost příjmu není k dispozici.

Nepovažujte registraci v systému ERP za pouhý atribut typu „ano/ne“. Důležitou otázkou je, zda příjemce může přijmout přesně tu kombinaci typu dokumentu a obchodního procesu, která mu je zasílána.

Vaše integrace by měla:

I když jsou faktura a adresa Peppol ID správné, síť může dočasně hledat na nesprávném místě.

K tomu může dojít, když společnost změní poskytovatele služeb Peppol, když zůstávají v mezipaměti staré směrovací údaje nebo během šíření změn. Odesílateli se může zobrazit chyba naznačující, že příjemce neexistuje, ačkoli skutečný problém spočívá v zastaralých informacích o vyhledávání.

Aplikace ERP by se neměly pokoušet samy reprodukovat celý proces vyhledávání v síti Peppol, pokud to není záměrnou součástí architektury produktu. Vyhledávání, ověřování certifikátů, směrování a zpracování opakovaných pokusů obvykle lépe zajišťuje poskytovatel služeb Peppol.

Týmy odpovědné za ERP a podnikové týmy by měly i nadále zajistit, aby:

Každá faktura ve formátu Peppol uvádí, podle jakých pravidel je vystavena a ke kterému obchodnímu procesu patří. Pokud tyto identifikátory chybí nebo jsou nesprávné, přijímající systém nemůže dokument spolehlivě interpretovat.

K tomu často dochází, když systém ERP exportuje starou šablonu faktury, konvertor vloží nesprávnou hodnotu nebo se mapování určené pro jednu zemi či jeden proces použije jinde.

Identifikátory profilů a specifikací by měly být spravovány centrálně. Neměly by být editovatelné uživateli ani samostatně vytvářeny v každém ERP konektoru.

Pro prostředí s více trhy:

Na faktuře musí být uvedeny údaje, z nichž kupující pozná, kdo zboží objednal, nebo ke které objednávce se faktura vztahuje.

Bez tohoto odkazu nemusí kupující vědět, kam má fakturu zaslat. Systém Peppol proto vyžaduje buď odkaz na kupujícího, nebo odkaz na objednávku.

Zadání „N/A“ sice může vzbudit dojem, že je pole vyplněno, ale kupujícímu to neposkytuje žádné užitečné informace.

Zaznamenejte požadované referenční údaje ještě před vystavením faktury. Nespoléhejte se na to, že oddělení pohledávek doplní chybějící údaje až poté, co bude faktura zamítnuta.

Škálovatelný proces by měl:

Faktura může obsahovat správnou celkovou částku, ale přesto může být zamítnuta, protože údaje o DPH nedávají smysl.

Zvolená kategorie DPH, sazba DPH a důvod osvobození od DPH se musí navzájem shodovat. V závislosti na dotčených zemích mohou platit další vnitrostátní požadavky.

Nepovažujte DPH za formátovací záležitost, kterou řeší nástroj pro převod faktur. Stanovení daně by mělo proběhnout v příslušném ERP systému nebo daňovém modulu ještě před vystavením faktury.

Kontrolní mechanismy v podniku by měly zahrnovat:

Formálně správná faktura nemusí nutně vycházet ze správného právního daňového posouzení. Nejisté daňové situace by měl posoudit kvalifikovaný daňový odborník.

Částky na faktuře se musí sečíst v souladu se stanovenými pravidly pro výpočet.

Problémy často vznikají, když systém ERP, daňový modul a konvertor faktur vypočítávají stejné hodnoty odlišným způsobem. I rozdíl jednoho centu může stačit k tomu, aby došlo k závažné chybě při ověřování.

V rámci celého fakturačního procesu používejte jeden zdokumentovaný model výpočtu a zaokrouhlování.

Zvláštní pozornost věnujte:

Vždy ověřte konečný XML soubor vygenerovaný pro přenos. Ověření pouze zdrojových dat z ERP systému nezachytí chyby vzniklé v mapovací nebo konverzní vrstvě.

Strukturovaná faktura není digitální verzí papírové faktury. Prázdné řádky, vizuální oddělovače a libovolný text by neměly být převáděny na fakturační položky.

Každé pole a každý řádek má svůj definovaný význam. Použití pole k jinému účelu sice může předat data kupujícímu, brání však spolehlivé automatizaci.

Mapování v systému ERP by mělo být spíše sémantické než vizuální. Informace mapujte podle jejich významu, nikoli podle toho, kde se na vygenerované faktuře nacházejí.

Mezi běžné ovládací prvky patří:

K faktuře ve formátu Peppol lze připojit soubor PDF nebo jiný soubor, příjemce by však neměl být nucen jej otevírat, aby transakci pochopil nebo zpracoval.

Pokud číslo objednávky, platební údaje, informace o DPH nebo popisy položek figurují pouze v souboru PDF, kupující přichází o značnou část automatizace, kterou má strukturovaná elektronická fakturace poskytovat.

Přílohy považujte za doplňkový materiál. Potřebné a provozně důležité informace uvádějte ve strukturovaných polích faktury.

Přílohy mohou být vhodné pro:

Zkontrolujte také požadavky na typ média, název souboru a velikost. Poskytovatelé služeb a přijímající systémy mohou stanovit provozní omezení, i když je daný typ souboru podporován.

„Doručeno“ neznamená „schváleno k proplacení“.

Systém Peppol může sice úspěšně doručit technicky správnou fakturu, kupující ji však může i tak zpochybnit nebo odmítnout, protože cena je nesprávná, nesouhlasí s objednávkou, zboží nebylo převzato nebo byla faktura vystavena nesprávnému právnímu subjektu.

Uživatelé ERP a finančních systémů potřebují více než jen informaci o tom, zda byla transakce odeslána či selhala. Integrace by měla rozlišovat:

Odpovědi by měly být přiřazeny k původní faktuře a předloženy tak, aby umožnily příslušnému týmu přijmout příslušná opatření. Automatické opakované pokusy nesmí vést k vytvoření duplicitních faktur.

Spolehlivá elektronická fakturace vyžaduje více než jen vytvoření platného XML souboru. Celý proces musí zahrnovat:

V případě podnikových organizací by tyto funkce měly být centralizovány, nikoli vytvářeny samostatně v každém ERP systému, v každé dceřiné společnosti nebo na každém trhu.

Pro partnery v oblasti ERP a platforem by mělo být připojení k Peppolu poskytováno jako spravovaná služba se stabilními API, jasnými kategoriemi chyb a praktickými odpověďmi. Uživatelé by neměli muset rozumět záznamům SMP ani pravidlům Schematronu, aby mohli opravit fakturu – integrace je však musí v pozadí správně zpracovat.

Qvalia poskytuje podnikům, dodavatelům ERP systémů a softwarovým platformám plnou konektivitu s Peppolem prostřednictvím API a integrací založených na souborech. Platforma zajišťuje správu strukturované výměny dokumentů, vyhledávání účastníků, ověřování, odesílání odpovědí, zpracování chyb a sledovatelnost transakcí.

Prozkoumejte přístupový bod Qvalia Peppol.