Ako prejsť na eFaktúru bez okamžitej výmeny účtovného systému

Krátka odpoveď

Účtovný systém nemusíte automaticky vymeniť. Musí však vedieť vytvoriť alebo odovzdať údaje, z ktorých vznikne eFaktúra podľa európskej normy a slovenskej technickej špecifikácie. Zároveň potrebujete spoľahlivo dostať prijaté XML späť do účtovného procesu.

Rozhoduje reálna schopnosť konkrétnej verzie systému a konkrétneho prepojenia, nie všeobecný prísľub, že softvér „podporuje XML“, EDI alebo Peppol.

Tri použiteľné integračné cesty

Neexistuje jedno štátne „CPDS API“. Rozhranie medzi vaším systémom a poskytovateľom je produktová vlastnosť konkrétnej služby. Zákon, slovenská technická špecifikácia a pravidlá OpenPeppol určujú výsledný dokument a doručovací rámec, nie názvy REST endpointov alebo webhookov.

Čo si vypýtať od dodávateľa softvéru

Nestačí otázka „budete podporovať eFaktúru?“. Pýtajte si písomnú odpoveď na tieto body:

• ktorú verziu slovenskej technickej špecifikácie systém podporuje,
• či generuje platný dokument alebo iba export údajov na ďalšiu konverziu,
• ktoré typy dokladov podporuje: faktúra, faktúra k prijatej platbe, oprava, dobropis a samofakturácia,
• ako importuje prijaté XML a prílohy,
• ako zobrazuje validačné, doručovacie a nedoručovacie stavy,
• s ktorými poskytovateľmi má otestované prepojenie,
• či je dostupné testovacie prostredie a kto rieši incidenty,
• ako sa z dokumentov robí hromadný export pre archiváciu alebo zmenu poskytovateľa.

Odpoveď „UBL exportujeme“ nie je dôkaz kompatibility. Všeobecne platný UBL dokument ešte nemusí spĺňať Peppol BIS Billing, slovenské pravidlá ani aktuálny súbor validačných pravidiel.

Postup pri natívnom module

1. Overte presnú verziu účtovného systému a licenčné podmienky modulu.
2. Vyberte certifikovaného poskytovateľa zo zoznamu Finančnej správy.
3. Dokončite zmluvu, overenie subjektu a technickú registráciu; prejavenie záujmu na portáli Finančnej správy samo osebe zmluvu nenahrádza.
4. V testovacom prostredí odošlite syntetické doklady pre hlavné obchodné scenáre.
5. Overte spätný import prijatých dokladov a všetky chybové stavy.
6. Až po úspešných testoch prepnite produkčné smerovanie.

Postup pri manuálnom importe a exporte

Manuálny proces môže byť rozumný pri malom objeme, no musí byť presne popísaný:

1. Fakturant pripraví údaje v účtovnom systéme.
2. Schválené údaje sa prenesú do aplikácie poskytovateľa alebo sa z nich vytvorí podporované XML.
3. Poskytovateľ dokument validuje a odošle.
4. Fakturant kontroluje konečný doručovací stav, nie iba úspešné nahratie súboru.
5. Prijaté XML a prílohy sa odovzdajú do účtovníctva a archívu.
6. Nesprávne alebo nedoručené dokumenty majú určeného vlastníka a lehotu nápravy.

CSV, PDF, ISDOC alebo vlastný XML export nie sú automaticky slovenskou eFaktúrou. Ak prebieha konverzia, zmluvne si určte, kto zodpovedá za mapovanie údajov a validáciu výsledku.

Postup pri API alebo middleware

Pri vlastnej integrácii navrhnite minimálne tieto funkcie:

• vytvorenie alebo odovzdanie dokumentu,
• validáciu pred odoslaním,
• jednoznačný identifikátor požiadavky a ochranu pred duplicitou,
• asynchrónne sledovanie konečného stavu,
• bezpečný príjem dokumentov a príloh,
• opakovanie dočasne neúspešných operácií bez vytvárania duplikátov,
• auditný záznam bez zapisovania citlivého obsahu do bežných aplikačných logov,
• export a obnovu pri zmene alebo výpadku poskytovateľa.

Konkrétny spôsob autentizácie, názvy endpointov, webhookové podpisy, limity a stavový model preberte výlučne z aktuálnej dokumentácie a zmluvy vybraného poskytovateľa.

Čo otestovať

Testovanie robte v testovacom prostredí so syntetickými údajmi. Neposielajte fiktívne faktúry v produkcii a nepoužívajte reálne osobné údaje len preto, aby test vyzeral realisticky.

Minimálny balík scenárov:

• bežná faktúra s jednou aj viacerými sadzbami DPH,
• faktúra k prijatej platbe,
• opravný doklad s referenciou na pôvodný doklad,
• príloha a jej export na strane príjemcu,
• chýbajúce povinné pole alebo nesprávny identifikátor,
• neznámy alebo nepripravený príjemca,
• dočasný výpadok poskytovateľa,
• opakovaná požiadavka s rovnakým identifikátorom,
• zmena stavu od prijatia požiadavky po konečné doručenie alebo zlyhanie,
• hromadný export pôvodných XML, príloh a auditných údajov.

Kedy už výmena systému dáva zmysel

Výmenu zvážte, ak dodávateľ nevie preukázať podporu aktuálnych pravidiel, neponúka bezpečný export ani integráciu, systém nevie spracovať prijaté štruktúrované údaje alebo prevádzka závisí od ručného prepisovania v rozsahu, ktorý vytvára neprimerané riziko.

Nie je možné poctivo určiť všeobecnú cenu ani čas implementácie bez poznania objemu, počtu systémov, typov dokladov, požadovaného SLA a rozhrania vybraného poskytovateľa. Takéto čísla musia vychádzať z konkrétnej ponuky a otestovaného rozsahu.

Kontrolný zoznam

• Máme potvrdenú presnú verziu slovenskej špecifikácie.
• Vieme, kto vytvára výsledné XML a kto zodpovedá za mapovanie.
• Máme vybraného certifikovaného poskytovateľa a dokončenú zmluvu.
• Poznáme proces pre prijatie, odoslanie, opravu a nedoručenie.
• Testujeme iba v určenom testovacom prostredí so syntetickými údajmi.
• Vieme exportovať pôvodné XML, prílohy a relevantnú auditnú stopu.
• Máme runbook pre výpadok, zmenu poskytovateľa a ukončenie zmluvy.

Súvisiace čítanie

Pokračujte cez checklist e-fakturácie 2027, zdroje pre vývojárov a výber digitálneho poštára.

Tento článok opisuje integračné vzory, nie funkcie konkrétneho produktu. Aktuálne možnosti, ceny, lehoty a zodpovednosti si potvrďte s dodávateľom účtovného systému a vybraným certifikovaným poskytovateľom.