FAQ: CPDS, digitálny poštár a e-fakturácia 2027

CPDS je certifikovaný poskytovateľ doručovacej služby. V praxi ide o poskytovateľa, cez ktorého firma posiela a prijíma štruktúrované elektronické faktúry v slovenskom modeli eFaktúry.

„Digitálny poštár” je praktické pomenovanie pre CPDS. Právne a technicky je presnejší pojem CPDS, teda certifikovaný poskytovateľ doručovacej služby.

Elektronická faktúra je štruktúrovaný dátový doklad, ktorý vie softvér spracovať automaticky. Pri povinnej e-fakturácii nestačí iba PDF, sken alebo obrázok faktúry.

PDF môže byť vizualizácia alebo príloha, ale samo o sebe nespĺňa požiadavku štruktúrovanej e-faktúry. Rozhodujúci je dátový formát, ktorý spĺňa pravidlá eFaktúry, Peppol BIS/UBL a príslušné slovenské požiadavky.

Účtovný softvér rieši vystavenie, účtovanie a spracovanie dokladu. CPDS rieši doručenie štruktúrovanej faktúry medzi odosielateľom a príjemcom. Niektoré účtovné systémy sa na CPDS napoja priamo, inde firma používa dashboard CPDS.

Subjekt, na ktorý sa vzťahuje príjem eFaktúr, musí mať zabezpečenú doručovaciu službu. Nemusí však vždy podpisovať samostatnú zmluvu s CPDS: služba môže byť súčasťou účtovného systému alebo ju môže sprostredkovať iný dodávateľ. Platiteľ DPH rieši pri zákonom určených tuzemských dodaniach aj odosielanie.

Áno, minimálne na strane prijímania. Ak vám obchodný partner pošle e-faktúru cez CPDS/Peppol, potrebujete spôsob, ako ju prijať, zobraziť, exportovať a uložiť pre účtovníctvo.

Najprv zistite, či budete faktúry len prijímať cez dashboard, alebo potrebujete napojenie na účtovný/ERP systém. Potom overte CPDS, Peppol participant ID, export XML, archív, cenník, podporu a testovanie.

Aktuálny slovenský systém eFaktúra je určený pre tuzemskú výmenu B2B a B2G. Najnovšie FAQ Finančnej správy predpokladá podporu cezhraničných eFaktúr od roku 2030. Peppol technicky umožňuje aj inú cezhraničnú výmenu, ale nemožno ju automaticky vydávať za splnenie dnešného slovenského zákonného režimu.

Samotné PDF e-mailom nie je štruktúrovaná eFaktúra. Iný kanál než doručovacia služba môže byť pri splnení zákonných podmienok použitý so súhlasom príjemcu, ale dokument musí zostať v štruktúrovanom formáte UBL 2.1 alebo CII podľa EN 16931. Príjemca si aj tak musí zabezpečiť schopnosť prijímať cez doručovaciu službu.

Overte si poskytovateľa v oficiálnom zozname Finančnej správy SR. Certifikovaný poskytovateľ má identifikátor v slovenskom zozname a má byť schopný vysvetliť, ako rieši participant ID, doručovanie, export a podporu.

Záleží od poskytovateľa a balíka. Niektorí poskytovatelia ponúkajú základný príjem cez dashboard zdarma, iní účtujú mesačný poplatok alebo poplatok podľa objemu faktúr. Pred podpisom zmluvy si overte aj export dát a archiváciu.

Pre konkrétne participant ID je v SMP na príjem registrovaný jeden poskytovateľ. Na odosielanie môže mať subjekt zmluvne viac poskytovateľov alebo systémov. Pri zmene prijímacieho CPDS riešte migráciu ID, export dát a presný čas prechodu.

Overte certifikáciu, cenu príjmu a odosielania, export pôvodného XML, dostupnosť API, podporu účtovného softvéru, SLA, archív, možnosť zmeny poskytovateľa a proces riešenia validačných chýb.

Firma by mala mať export svojich dokladov, jasné zmluvné podmienky a plán migrácie. CPDS nie je účtovná zodpovednosť firmy; zmluva má riešiť dostupnosť dát, logy, výpovedné lehoty a prechod k inému poskytovateľovi.

Nie. Odoslanie výberu je prejav záujmu a súhlas s odovzdaním údajov vybranému poskytovateľovi a sprostredkovateľovi. Zmluvu, overenie klienta a technickú registráciu do SMP treba dokončiť osobitne.

Najprv skontrolujte, či má prihlásený používateľ oprávnenie konať za konkrétny daňový subjekt. Samotná registrácia používateľa na portáli Finančnej správy nestačí; registrácia a oprávnenie k subjektu sú odlišné kroky.

Výber poskytovateľa je možný iba pre subjekt s prideleným a oznámeným DIČ, pretože slovenské participant ID používa tvar 0245:DIČ. Postup pridelenia závisí od typu subjektu; pri mimovládnych organizáciách Finančná správa v auguste 2026 opísala aj automatické pridelenie pre väčšinu subjektov zapísaných v Registri právnických osôb.

Informácia o výsledku sa uloží do osobnej internetovej zóny a podľa nastavenia môže prísť notifikácia. Vybraný poskytovateľ alebo sprostredkovateľ dostane kontaktné údaje a má so subjektom dokončiť onboarding. Až následná aktivácia potvrdí, že príjem funguje.

Výber na portáli zákazníka ani poskytovateľa nenahrádza zmluvu. Ak sa onboarding nedokončí, subjekt si má vybrať iného poskytovateľa a overiť úspešnú registráciu participant ID a skúšobný príjem.

Samotné odosielanie nie je viazané na jedného poskytovateľa vybraného cez portál. Na príjem môže mať subjekt registrovaného iba jedného poskytovateľa, na odosielanie môže zmluvne používať viacerých. Odosielajúci poskytovateľ však môže na overenie subjektu požadovať verifikačný token získaný cez portál Finančnej správy; od roku 2027 si dotknutý subjekt musí osobitne zabezpečiť aj príjem.

Podľa augustového FAQ treba zahraničného poskytovateľa kontaktovať a požiadať o zrušenie registrácie slovenského identifikátora 0245:DIČ. Ak subjekt nevie poskytovateľa identifikovať, po overení mu jeho názov poskytne call centrum Finančnej správy. Slovenské subjekty majú byť vedené v slovenskom centrálnom SMP.

Peppol je sieť a súbor pravidiel na výmenu štruktúrovaných obchodných dokumentov. Pri e-faktúrach umožňuje, aby odosielateľ a príjemca komunikovali cez svojich poskytovateľov, nie cez jeden centrálny portál.

Peppol Access Point je technická rola v Peppol sieti. CPDS je slovenský certifikovaný poskytovateľ doručovacej služby. V slovenskom kontexte má CPDS plniť rolu poskytovateľa doručovania v ekosystéme eFaktúry.

Participant ID je adresa účastníka v Peppol sieti. Slovenský formát používa schému `0245:DIČ`, napríklad `0245:1234567890`, bez prefixu `SK` pred DIČ.

EN 16931 je európska norma pre sémantický model elektronickej faktúry. Hovorí, aké obchodné údaje má faktúra niesť. UBL a Peppol BIS riešia technickejšiu podobu a pravidlá prenosu.

UBL je XML syntax pre obchodné dokumenty. Pri Peppol BIS Billing sa používa UBL faktúra alebo UBL credit note, ktoré musia prejsť technickými a obchodnými validačnými pravidlami.

Ak faktúra neprejde validáciou pred odoslaním, opravuje sa dátový súbor a posiela sa znovu. Nie je to dobropis ani storno, lebo príjemca ešte nedostal platný doručený doklad.

Zákonnú zodpovednosť za uchovanie účtovných a daňových dokladov má firma alebo účtovná jednotka. CPDS môže ponúkať archív alebo uloženie v balíku, ale treba si zmluvne overiť rozsah, dobu uchovania a export.

Pri účtovných a daňových dokladoch sa v praxi počíta s desaťročným uchovávaním. Firma má riešiť nielen PDF náhľad, ale aj pôvodné XML, prílohy, auditnú stopu a väzby na účtovníctvo.

Nie je to bezpečný postup. Pri štruktúrovanej e-faktúre je podstatný pôvodný dátový dokument, typicky XML. PDF môže byť čitateľný náhľad, ale nemá nahradiť originálne dáta, ktoré systém prijal alebo odoslal.

Nie. Logy dokazujú stav doručenia alebo technického spracovania. Účtovný archív musí obsahovať doklady a údaje potrebné pre účtovníctvo, daňové kontroly a interné procesy firmy.

Technická chyba pred odoslaním sa opravuje v XML. Ak bola faktúra doručená a mení sa obchodný alebo účtovný stav, treba nový opravný doklad, často dobropis/credit note alebo novú faktúru podľa konkrétneho prípadu.

Záleží od účtovného alebo ERP systému a od konkrétneho CPDS. Pred výberom si overte podporu importu/exportu XML, API, webhooks, sandbox, mapovanie polí a proces riešenia validačných chýb.

Nie vždy. Menšia firma môže začať dashboardom CPDS a exportom pre účtovníka. Pri väčšom objeme faktúr, schvaľovaní, skladoch alebo ERP procesoch je vhodnejšie priame napojenie.

Menšie firmy môžu začať výberom CPDS a testovacím príjmom. Firmy s ERP, API integráciou, viacerými workflowmi alebo veľkým objemom faktúr by mali začať skôr, aby zostal čas na testovanie a školenie.

ERP musí riešiť generovanie a spracovanie XML, validáciu, mapovanie na EN 16931/UBL/Peppol BIS, stavové správy, prílohy, dobropisy, export, archív a integráciu s CPDS.

Rozdeľte klientov podľa DPH, objemu faktúr a softvéru. Pripravte checklist: kto vyberá CPDS, kto má prístup, ako sa doručujú XML, kde sa archivuje a ako sa riešia výnimky.

Najnovšie FAQ pri neoznámených, nesprávnych alebo oneskorených údajoch uvádza pokutu do 10 000 eur a pri opakovanom porušení do 100 000 eur. Podľa § 85o sa pokuta neuloží pri opravených nesprávnych údajoch, ak z povahy veci vyplýva zrejmý omyl; samostatne ani pri preukázanej technickej poruche na strane PDS, ak sa údaje oznámia bezodkladne po odstránení poruchy. Iné porušenia sa posudzujú podľa príslušného zákona.

Peppol doručenie nie je reklamácia. Ak príjemca nesúhlasí s obsahom faktúry po obchodnej stránke, má riešiť vec s dodávateľom a následne sa vystaví príslušný opravný doklad.

Prílohy sa riešia podľa pravidiel Peppol BIS a UBL cez referencie alebo vložené dokumenty. Overte veľkosť, povolené typy súborov a či príloha nenahrádza údaje, ktoré majú byť priamo v štruktúrovanej faktúre.

Zaokrúhľovanie musí sedieť s validačnými pravidlami. Dôležité sú riadkové sumy, základ dane, DPH, celkové sumy a prípadne `PayableRoundingAmount`. ERP by malo výpočty testovať na reálnych scenároch.

Nie automaticky. Niektorí poskytovatelia majú úložisko alebo archív v balíku, ale firma si musí overiť zmluvu, dobu uchovania, export, dostupnosť po ukončení služby a zodpovednosť za účtovné doklady.

Áno. Sprievodca Finančnej správy pre obce uvádza, že obec musí byť pripravená prijímať eFaktúry bez ohľadu na svoje postavenie k DPH. Odosielanie sa posudzuje osobitne podľa postavenia platiteľa DPH a konkrétneho tuzemského dodania.

Nie vždy. Doručovacia služba môže byť súčasťou ekonomického alebo účtovného systému, ktorý obec používa. Obec si musí u dodávateľa potvrdiť konkrétny CPDS, rozsah služby, cenu, export XML, podporu a výsledok testovania.

Áno. Každú samostatnú právnickú osobu, jej DIČ, ekonomický systém, prístupy a fakturačné toky treba skontrolovať osobitne. Pripravenosť obce automaticky nepreukazuje pripravenosť všetkých jej organizácií.

Nie iba preto, že je právnickou osobou alebo má DIČ. Podľa osobitného sprievodcu musí vedieť eFaktúry prijímať; povinné odosielanie sa viaže najmä na platiteľa DPH a zákonom určené tuzemské dodanie.

Finančná správa uvádza približne 58-tisíc MNO bez DIČ, ktorým ho pridelí automaticky, ak sú zapísané v Registri právnických osôb. Rozhodnutie má prísť do elektronickej schránky na slovensko.sk alebo poštou. Osobitné organizačné jednotky môžu musieť požiadať samy.

Nie. Pridelenie DIČ samo osebe nemení postavenie k DPH a automaticky nevytvára povinnosť podávať daňové priznanie. DIČ je však kľúčový identifikátor pre slovenské Peppol participant ID 0245:DIČ.

eFaktúra je faktúra vytvorená, zaslaná a prijatá v štruktúrovanom XML formáte podľa EN 16931 a UBL, aby ju účtovný program vedel automaticky spracovať. Nejde len o PDF alebo sken.

Hlavný prínos je automatizované spracovanie bez ručného prepisovania, nižšia chybovosť, bezpečnejší prenos dát, pripravenosť na Peppol výmenu a súlad so slovenskou a európskou legislatívou.

Nie. FAQ uvádza, že aktuálny režim sa týka B2B a B2G fakturácie, nie spotrebiteľských B2C faktúr.

Prijímať eFaktúry musí vedieť právnická osoba a podnikateľ, ktorý je zdaniteľnou osobou. Prakticky ide aj o živnostníkov, slobodné povolania, samostatne hospodáriacich roľníkov či prenajímateľov v postavení zdaniteľnej osoby.

Áno. FAQ uvádza najmä prípady spojené s utajovanými skutočnosťami alebo bezpečnostnými zložkami štátu, kde sa používa iný režim než elektronická faktúra.

FAQ uvádza zrušenie až od 1.7.2030. Do tohto obdobia treba počítať s prechodným režimom a existujúcimi výkazmi podľa platných pravidiel.

Pri povinnom režime nie je súhlas príjemcu hlavným predpokladom tak ako pri dobrovoľnom posielaní mimo povinného režimu. Pri dobrovoľných alebo výnimkových tokoch treba posúdiť zákon a súhlas príjemcu.

Nestačí faktúru do zákonnej lehoty iba vytvoriť v účtovnom systéme. Pri doručení cez PDS je rozhodujúci deň, keď bola odovzdaná doručovacej službe; pri inom spôsobe deň odoslania alebo sprístupnenia príjemcovi. Pri prípadoch podľa § 85o musí byť tento krok vykonaný najneskôr do 15 dní od dodania alebo od prijatia platby, ak ňou vznikla daňová povinnosť.

Firma potrebuje prístup k doručovacej službe, teda cez účtovný systém, ERP integráciu alebo aplikáciu digitálneho poštára/CPDS.

Áno, ale oficiálne zdroje používajú pojem v dvoch kontextoch. Aktuálne FAQ ním označuje dobrovoľnú fázu od 1.1. do 31.12.2026. Nadpis § 85o zákona o DPH a informácia 1/DPH/2026/I používajú prechodnú terminológiu aj pre zákonné obdobie od 1.1.2027 do 30.6.2030. Dátumy si neprotirečia; pri citovaní treba uviesť konkrétny zdroj a fázu.

Aktuálny slovenský systém eFaktúra je určený na výmenu v rámci Slovenskej republiky. Najnovšie FAQ predpokladá podporu cezhraničných eFaktúr od roku 2030. Samotná technická schopnosť Peppol siete preniesť dokument preto nie je dôkazom, že ide o dnešný slovenský zákonný tok.

Peppol autoritou Slovenskej republiky je Finančná správa SR. Preto treba pri slovenských pravidlách sledovať jej stránku eFaktúra, zoznam CPDS a technické dokumenty.

Poskytovateľom môže byť subjekt, ktorý splní podmienky akreditácie/certifikácie a je uvedený v príslušnom procese alebo zozname Finančnej správy.

FAQ uvádza faktúry, samofaktúry a dobropisy. Technicky to znamená najmä Peppol BIS/UBL invoice, credit note a self-billing dokumenty podľa podporovaných typov.

SMP publikuje metadáta o účastníkovi v Peppol sieti: kam sa majú doručovať dokumenty a aké dokumenty príjemca podporuje.

EDIFACT môže zostať interný alebo partnerský zdroj dát, ale pre slovenskú povinnú eFaktúru treba údaje konvertovať do formátu súladného s EN 16931 a UBL/CII. Samotný EDIFACT nebude slovenskou eFaktúrou pre účely DPH.

Ak sa použije doručovacia služba a formát Peppol BIS, oznámenie vykonáva poskytovateľ doručovacej služby. Ak sa doručovacia služba nepoužije, režim oznamovania treba posúdiť podľa platných pravidiel pre daný spôsob zaslania.

Pri opakovaných službách po 1.1.2027 treba posúdiť, či má platiteľ povinnosť vystaviť elektronickú faktúru za konkrétne dodanie alebo prijatú platbu. FAQ upozorňuje, že dohoda o platbách nájomného nemá nahradiť povinnú eFaktúru tam, kde zákon vyžaduje elektronickú faktúru.

Proforma výzva na úhradu nie je faktúra podľa zákona o DPH a nie je predmetom systému eFaktúra. Ak však prijatím platby pred dodaním vzniká povinnosť vystaviť daňový doklad, tento doklad môže podliehať režimu eFaktúry.

FAQ uvádza, že neexistuje osobitná legislatívna povinnosť posielať odmietnutie prijatej faktúry cez Peppol. Vecný spor alebo nesprávnu faktúru treba riešiť priamo s obchodným partnerom.

Pre konkrétny Participant ID je v SMP na prijímanie registrovaný jeden poskytovateľ. Na odosielanie môže mať subjekt zmluvne viac možností; výber konkrétneho poskytovateľa je otázka konfigurácie a zmluvy.

FAQ výslovne pomenúva prípady, kde sa eFaktúra nesmie vyhotoviť, napríklad utajované plnenia alebo vybrané bezpečnostné zložky. Pri ostatných subjektoch treba posúdiť povinnosť podľa zákona a identifikácie príjemcu.

Ak platiteľ po 1.1.2027 prijme platbu pred tuzemským dodaním tovaru alebo služby a príjemca patrí do režimu podľa § 85o, vzniká povinnosť vyhotoviť elektronickú faktúru aj na prijatú platbu.

FAQ uvádza DIČ ako hlavný identifikátor pre slovenské Peppol/PASR prostredie. Aj pri organizáciách bez IČ DPH je pre smerovanie eFaktúry rozhodujúca použiteľná identifikácia v slovenskom Peppol modeli.

Bez DIČ nemožno vytvoriť slovenské participant ID 0245:DIČ. Subjekt má vyriešiť pridelenie DIČ podľa svojho typu. Pri väčšine mimovládnych organizácií zapísaných v Registri právnických osôb Finančná správa opisuje automatické pridelenie; niektoré organizačné jednotky musia požiadať samy.

Od roku 2027 má príjemca, na ktorého sa režim vzťahuje, zabezpečiť prijímanie. Ak dodávateľ riadne odovzdá eFaktúru doručovacej službe a doručenie zlyhá pre nepripravenosť príjemcu, svoju zákonnú povinnosť tým splní. Dodatočné sprístupnenie tej istej faktúry e-mailom zákon výslovne nezakazuje; pri alternatívnom doručovaní je vhodný preukázateľný súhlas. Samotné neskoršie doručenie iným spôsobom nie je dôvodom na odmietnutie odpočtu DPH, ak sú splnené všetky ostatné zákonné podmienky.

Postup je obdobný ako pri nevyžiadanej papierovej alebo e-mailovej faktúre: overiť vzťah, kontaktovať vystavovateľa a pri podozrení na podvod riešiť vec s príslušnými orgánmi.

FAQ počíta s dobrovoľným použitím Peppol/doručovacej služby v roku 2026. Pri dokladoch s IČ DPH môže nastať aj technické oznamovanie údajov, ak sú na to pripravené príslušné uzly.

Samofakturácia zostáva možná pri splnení existujúcich podmienok, najmä písomnej dohody. Technicky ide o osobitný typ dokumentu/procesu rozpoznateľný v Peppol modeli.

Ak faktúra nezodpovedá reálnemu dodaniu alebo zmluvnému vzťahu, príjemca ju nemá vecne uznať a má situáciu riešiť priamo s vystavovateľom. Samotné doručenie neznamená obchodnú akceptáciu.

Najčistejší postup je často credit note/dobropis k pôvodnej faktúre a následne nová správna faktúra. Alternatívna opravná faktúra musí spĺňať Peppol BIS pravidlá a jasne referencovať pôvodný doklad.

Neplatiteľ DPH nemá povinnosť vyhotovovať elektronické faktúry ako platiteľ, ale môže byť povinný vedieť eFaktúry prijímať, ak je zdaniteľnou osobou a dodávateľ mu vystaví povinnú eFaktúru.

Pri tuzemských dodaniach oslobodených od dane podľa uvedených ustanovení FAQ uvádza, že povinnosť vyhotoviť eFaktúru nevzniká. Dobrovoľné zaslanie cez doručovaciu službu však technický systém nemusí vedieť právne odlíšiť od povinného toku.

FAQ uvádza, že povinnosť vyhotoviť elektronickú faktúru podľa § 85o sa nevzťahuje na zdaniteľnú osobu, ktorá nie je platiteľom DPH. Povinnosti príjmu však treba posúdiť osobitne.

Áno, FAQ k archivácii uvádza, že platiteľ má uchovávať elektronické faktúry v XML formáte počas zákonnej lehoty. CPDS môže pomôcť službou, ale zodpovednosť za uchovanie treba riešiť vo firme a zmluve.

Doručenie neznamená akceptáciu. Príjemca má kontaktovať dodávateľa, žiadať opravný doklad alebo dobropis a pri nekontaktnom dodávateľovi zvážiť oznámenie správcovi dane.

Monitoring vychádza z Peppol Service Level Requirements a zmluvných povinností poskytovateľa. Dôležité sú logy transakcií, časové pečiatky, MDN potvrdenia, incident management a schopnosť preukázať splnenie SLA.

Pri doručení cez Peppol sa podpis na úrovni dokumentu nevyžaduje; autenticita a integrita sa zabezpečujú sieťou, poskytovateľmi a kontrolami. Pri alternatívnom doručení mimo PDS však treba zákonným spôsobom zabezpečiť autenticitu pôvodu, integritu obsahu a čitateľnosť; kvalifikovaný podpis alebo pečať môže byť jednou z možností.

Nie. Skupina údajov o daňovom zástupcovi má byť podľa FAQ relevantná iba v prípadoch, keď zahraničnú osobu zastupuje daňový zástupca.

Áno, najnovšie FAQ uvádza povinnosť od 1.7.2027, prípadne rovnocennú normu schválenú OpenPeppol. Rozsah certifikácie a právny subjekt na certifikáte musia pokrývať poskytovanú službu; nestačí nesúvisiaci certifikát inej časti skupiny.

Slovenská architektúra podľa FAQ zohľadňuje MLS, nie MLR ako samostatný nový základ. OpenPeppol vníma MLS ako vývoj oproti starším statusovým správam.

FAQ uvádza, že XML postačuje ako elektronická faktúra. Firma však musí vedieť faktúru na požiadanie v primeranom čase zobraziť v ľudsky čitateľnej forme.

Áno, Peppol prílohy umožňuje. PDF alebo obrázok však nesmie nahradiť povinné štruktúrované údaje v XML.

Peppol neurčuje jeden globálny pevný limit pre všetkých poskytovateľov. Limit môže byť súčasťou služby konkrétneho CPDS; FAQ uvádza približne 100 MB ako bežnú technickú hranicu, ktorú treba overiť v zmluve a praktickom teste.

Áno, môže byť vo vizualizácii alebo prílohe. Zdrojovým účtovným dokumentom však zostáva štruktúrované XML a platobné údaje, ktoré majú vlastné polia, nemajú zostať iba v obrázku.

Stĺpec kombinuje požiadavky slovenských predpisov a Peppol BIS 3.0 pre tvorbu slovenských faktúr. Nepoužíva sa ako samostatné technické overenie Peppol siete.

BT-120 sa vypĺňa pri transakciách oslobodených od DPH alebo s nulovou sadzbou, nie pri štandardnej sadzbe DPH. Pri bežnej kategórii S má zostať prázdny.

FAQ uvádza, že návrh IS EFA bol zrušený v roku 2024. Faktúry sa majú distribuovať cez Peppol e-delivery priamo medzi vystavovateľom a prijímateľom cez ich poskytovateľov.

Nie. FAQ uvádza, že vizuálna PDF podoba nie je povinná; je vecou dohody medzi účastníkmi alebo poskytovateľmi.

Nie je stanovený jednotný povinný štýlový predpis. Záväzný je obsah XML; vizualizácia má správne zobraziť dáta z XML.

FAQ uvádza, že Finančná správa nepripravuje samostatné mappingové súbory pre 381, 389 a 261. Používajú sa pravidlá podľa príslušných Peppol špecifikácií a rovnaký dátový základ.

Nie ako zákonná povinnosť. FAQ uvádza, že poskytovateľ doručovacej služby nemá zákonnú povinnosť uchovávať zaslané XML faktúry; uchovávanie rieši účtovná jednotka podľa zákona.

Technické vytvorenie TDD zabezpečuje poskytovateľ doručovacej služby príslušného subjektu. Povinnosť oznámenia údajov sa považuje za splnenú odovzdaním elektronickej faktúry doručovacej službe podľa zákonného režimu.

Slovenský režim používa schému 0245 s DIČ. Ak má firma historicky aj iné Peppol ID, treba rozlíšiť scenár a podporované dokumenty, ale pre slovenské PASR je rozhodujúce slovenské DIČ v schéme 0245.

Zmena poskytovateľa sa rieši cez presun registrácie a nastavenia participant ID v Peppol/SMP. V praxi treba koordinovať pôvodného a nového poskytovateľa, export dát a čas prechodu.

FAQ túto otázku rieši ako technicko-daňový prípad v Peppol BIS. Pri kombinovaných kategóriách treba dodržať správne položkové a daňové členenie v XML a validovať výsledok proti Peppol pravidlám.

FAQ rieši rozdiel medzi položkami faktúry a poľom pre preddavok. Prakticky treba testovať, či ERP používa správne UBL elementy pre uhradené platby a výsledné sumy.

Treba sledovať oficiálne dokumenty Finančnej správy, slovenské PASR a dokumentáciu Peppol BIS/OpenPeppol. Produkčný ERP by sa nemal riadiť iba príkladom, ale aktuálnym validátorom a schémami.

FAQ túto tému uvádza ako samostatnú technickú otázku. Pre slovenský B2B postup neberte kód 384 ako automatický default; pred použitím treba overiť podporu v aktuálnych Peppol/SK pravidlách a validátore CPDS/ERP.

Overenie identity používateľa je otázka poskytovateľa doručovacej služby a jeho onboarding procesu. Samotný portál FS nemusí nahradiť zmluvné a technické overenie u CPDS.

FAQ rieši túto povinnú poznámku vo väzbe na Peppol BIS pole BT-22. ERP musí zabezpečiť, aby povinný text bol v správnom poli a neporušil dĺžkové ani validačné pravidlá.

BT-33 je pole pre právne informácie o spoločnosti. Pri zápise do obchodného registra treba rešpektovať význam poľa a technické obmedzenia Peppol/UBL, najmä dĺžku a validáciu.

Nie ako samostatná schéma pre celý Peppol BIS profil. Peppol BIS Billing 3.0 je CIUS nad EN 16931, používa syntaktický základ UBL 2.1 alebo CII a nad ním validačné pravidlá vo forme Schematron. XML treba overovať proti aktuálnej Peppol dokumentácii a validátoru.

Pri zdanenej zálohe sa odpočet uvádza ako mínusový riadok faktúry s väzbou na pôvodný doklad cez BT-25. Pri nezdanenej zálohe nejde o korekciu základu dane ani DPH; prakticky sa používa PrepaidAmount (BT-113), ak suma znižuje úhradu.

Áno, FAQ uvádza, že Peppol BIS Billing 3.0 umožňuje použiť kód dokladu 383 pre ťarchopis alebo debit note podľa číselníka UNCL1001. Pri použití treba uviesť väzbu na pôvodnú faktúru cez BT-25.

Autorizačná aplikácia Finančnej správy overuje existenciu daňového subjektu a poskytovateľ dostane dôkaz o autorizácii. Overenie totožnosti konkrétnych osôb a oprávnenia konať za subjekt zostáva na poskytovateľovi doručovacej služby v jeho zmluvnom a KYC procese.

Iný spôsob doručenia je možný so súhlasom príjemcu, no faktúra musí zostať v štruktúrovanom formáte UBL 2.1 alebo CII podľa EN 16931 a musí byť zabezpečená jej autenticita, integrita a čitateľnosť. Príjemca si zároveň musí zachovať schopnosť prijímať cez PDS.

FAQ opisuje migráciu účastníka medzi SMP pomocou migračných kódov. Pôvodný poskytovateľ nastaví migračný kód, nový poskytovateľ ho použije pri registrácii a SML prepíše väzbu na nového poskytovateľa bez prerušenia dostupnosti v Peppol/SML sieti.

Podľa slovenských PASR je používanie centrálneho slovenského SMP záväzné. Slovenský zákazník má byť registrovaný v centralizovanom SMP spravovanom alebo určenom národnou autoritou; týka sa to poskytovateľov pôsobiacich v jurisdikcii Slovenskej republiky.

End User je ekonomický subjekt, nie konkrétny používateľ systému. Do EUSR a TSR sa započítavajú úspešne spracované alebo doručené výmeny na transportnej úrovni; zlyhania siete sa do reportov nezapočítavajú. Reporting poskytovateľa sa viaže na identifikátor z Peppol AP certifikátu.

FAQ odkazuje na súbor Transpozície štandardu Peppol BIS v podmienkach slovenskej legislatívy. Pri prenesení daňovej povinnosti treba sledovať najmä BT-151, BT-118, BT-95 a textový dôvod v BT-120.