Provjera e-računa: razumijevanje ZUGFeRD, XRechnung, Peppol i EN 16931

Petak, 15:40: Prijem računa stoji. Ne u potpunosti – ali baš toliko da boli. Dio pristiglih E‑računa prolazi uredno, drugi dio zapinje u importnom toku. Struka kaže: „Im PDF sieht alles korrekt aus.“ IT vidi u logu: „Profil nicht zulässig“ und „Business Rule verletzt“. Od tog trenutka postaje politično: nabava želi veću propusnost, računovodstvo želi sigurnost, IT ne želi posebnu logiku po dobavljaču.

Tko u takvoj situaciji treba provjeravati E‑račune, brzo uči: ZUGFeRD, XRechnung, Peppol i EN 16931 nisu puka igra riječi, već pitanje procjene. Ovisno o tome koliko strogo provjeravate, mijenjaju se napor i rizik – a time i arhitekturne odluke (centralni servis za provjeru vs. plugin u ERP), operativna pitanja (nadgledanje, ažuriranja, fallback) i pitanja uvođenja (pilotne skupine, komunikacija s dobavljačima, klase pogrešaka).

Dva cilja koja se u svakodnevnom radu međusobno vuku

Cilj 1: Automatizacija s velikom propusnošću. Mnoge tvrtke žele postaviti prijem računa tako da strukturirani računi bez prekida medija završavaju u ERP, radnom toku i arhivu. To smanjuje ručni unos i ubrzava odobrenja – ali samo ako su podaci pouzdani.

Cilj 2: Sigurnost provjere s rekonstruibilnim dokazom. Istovremeno mora biti moguće dokazati, u slučaju sumnje, zašto je račun prihvaćen ili odbijen: koji profil, koje pravilo, koja verzija. To postaje relevantno najkasnije kada dobavljači ulože pritužbu („odbili ste, ali kod drugih je prošlo“) ili kada interne kontrole traže uredan lanac dokaza.

Oba cilja su legitimna. Sukob nastaje jer svaka dodatna provjera smanjuje rizike, ali također može proizvesti više posebnih slučajeva. To vrijedi osobito kad dobavljači šalju različite profile ili kada promjena verzije u specifikaciji još nije posvuda primijenjena.

EN 16931: Zašto pri provjeri trebate upravljati semantikom umjesto „formata datoteke“

EN 16931 se u projektnom svakodnevnom radu često naziva „XML-formatom“. Praktičnije je drugo gledanje: EN 16931 je semantički podatkovni model za jezgrene elemente elektroničkog računa – odnosno značenje polja podataka i pripadajuća poslovna pravila (Business Rules) za usklađenost. Europska komisija tako klasificira EN 16931: kao semantički podatkovni model jezgrenih elemenata uključujući pravila usklađenosti.^[Quelle]

Praktična posljedica za IT i operacije: „XML je dobro formiran“ je samo ulazna točka. Presudno je je li račun u značenju konzistentan (logika zbrojeva, porezni podaci, obvezna polja, šifre). I nalazi li se u ispravnom profilu – jer profili definiraju koje dijelove standarda i u kojem obliku treba primijeniti.

Važno je također da se standardi ne zamrzavaju. U popisima normi već je navedeno ažurirano izdanje kao EN 16931‑1:2026.^[Quelle] To ne znači da morate odmah prijeći na novu verziju. Znači, međutim, da vaš model provjere i rada treba biti dizajniran tako da se pravila i validatori mogu verzionirati i kontrolirano ažurirati – bez da cjelokupna obrada pri svakom ažuriranju postane „na rubu“.

ZUGFeRD i XRechnung: dva puta da se ista obveza praktično ostvari

U Njemačkoj se u mnogim poduzećima susreću dva uobičajena oblika:

• ZUGFeRD kao hibridni format: PDF/A‑3 datoteka u koju su ugrađeni strukturirani podaci računa (XML). FeRD opisuje ZUGFeRD 2.2 eksplicitno kao hibridni model: vidljivi račun plus strojno čitljiv XML u PDF/A‑3.^[Quelle]
• XRechnung kao potpuno strukturirani format: fokus je u potpunosti na strojno obradivim podacima, bez da PDF kao sastavni dio „dolazi sa sobom“.

Procjena je manje ideološka, a više operativna: ZUGFeRD je odjela često lakše prihvatiti jer postoji čitljiv dokaz. Istovremeno PDF ne smije navesti na zanemarivanje provjere XML-a. XRechnung je jasno orijentirana na podatke i stoga pogodna za automatizaciju, ali u praksi gotovo uvijek zahtijeva dobar alat za prikaz i provjeru koji sadržaj jasno predstavlja.

Pravni okvir: Što se od 2025. računa kao „E‑Račun“

Za planiranje projekata osobito je djelotvorna jedna izjava: U kontekstu PDV‑a od 01.01.2025. E‑račun postoji samo ako je izdan/preuzet/primljen u strukturiranom elektroničkom formatu i omogućuje elektroničku obradu.^[Quelle] Čisti PDF bez strukturiranih podataka time ne ulazi u relevantnu definiciju.

BMF navodi također XRechnung kao i ZUGFeRD od verzije 2.0.1 (s izuzecima profila) kao formate koji u načelu ispunjavaju PDV‑zahtjeve.^[Quelle] Operativno iz toga ne proizlazi „pitanje religije formata“, već jasna obveza: morate prepoznati, provjeriti i obnovljivo dokumentirati profil i verziju. Inače nije moguć pouzdan gate niti uredan dokaz zašto je račun tako obrađen.

Peppol richtig einordnen: Transport und Interoperabilität statt „noch ein Format“

U svakodnevnom radu Peppol se često tretira kao još jedan format računa. To vodi do pogrešnih očekivanja. Peppol je prije svega okvir za prijenos i interoperabilnost strukturiranih poslovnih dokumenata. Za račune je relevantna komponenta Peppol BIS Billing 3.0.

U službenoj BIS‑Billing dokumentaciji EN‑16931‑konformnost je vidljiva preko CustomizationID‑Schemes (dakle preko oznake koja opisuje profil/„Customization“ kontekst). To je važno zato što pokazuje: u Peppol‑okruženju oznake profila i konformnosti su dio strojne evaluacije, a ne samo „nice to have“.^[Quelle]

Operativne posljedice iz toga su vrlo opipljive: uz provjeru dokumenta dolaze i transportne teme. Adresiranje, IDs sudionika, tehničke odbijanja, potvrde o isporuci – sve to stvara vlastite obrasce pogrešaka. Ako te pogreške ne klasificirate zasebno, na kraju sve završava kao „račun pokvaren“ u financijama ili kao „Peppol šepa“ u IT‑u.

Leitweg-ID & Peppol-ID: Warum Identifikatoren produktionskritisch sind

Vodič za korištenje ulaznog kanala Peppol za saveznu upravu, primjerice, opisuje formiranje Peppol‑ID iz prefiksa 0204 i Leitweg‑ID za povezane savezne urede te smješta Peppol Authority Deutschland pri KoSIT.^[Quelle] To je specifičan kontekst (država). Prijenosna lekcija za poduzeća ipak je jasna: identifikatori nisu sporedna tema. Oni pripadaju u runbookove, test‑slučajeve i konfiguraciju – jer „pogrešan ID“ u radu blokira jednako kao i „pogrešan profil“.

Abwägungskarte: Prüfstrategie nach Nutzen, Aufwand und Risiko

Praktična strategija dijeli provjere u stupnjeve. Vi svjesno odlučujete koji stupanj djeluje kao tvrdi gate (odbijanje) i koji stupanj izaziva samo upozorenje (razjašnjenje). Sljedeća karta pomaže usporediti tipične opcije.

Provjera e-računa: Put provjere koji opstaje u radu

Ako proces provjere formulirate tako da se može pronaći u logovima, runbookovima i sustavima za tikete, kasniji gubici zbog trenja se smanjuju. Sljedeći put je namjerno „orijentiran na rad“ i neovisno o tome dolazi li ulaz putem e-pošte, uploada, API-ja ili Peppol-a.

1. Zabilježiti ulaz: kanal, vremenska oznaka, ID-ovi pošiljatelja/primatelja, tehnički metapodaci. To je vaš audit trag.
2. Prepoznati kontejner: Čisto XML? ZUGFeRD (PDF/A‑3 s ugrađenim XML-om)? Ostalo? U slučaju hibrida: ekstrahirati XML i tretirati ga kao zaseban objekt provjere.
3. Odrediti profil i verziju: Koja varijanta je prisutna (npr. EN‑16931-profil, XRechnung-verzija, Peppol BIS Billing s CustomizationID)? Bez tih informacija provjera je jalova.
4. Strukturna validacija: provjera sheme/profila s zabilježenom verzijom validatora i stanjem skupa pravila. Rezultat mora biti reproducibilan.
5. Semantička pravila: evaluirati EN‑16931 poslovna pravila i provjere konzistentnosti (sume/porezi/obvezna logika).
6. Interna poslovna pravila: usklađivanje osnovnih podataka, veza s narudžbom, provjera duplikata, pravila odobrenja, zahtjevi za kontiranje. Ta su pravila specifična za tvrtku i često se mijenjaju češće od standarda.
7. Upravljati rezultatom: automatski proslijediti/knjižiti, poslati na razjašnjenje ili odbiti – uključujući klasu pogreške, kratko obrazloženje i referencu na zapisnik provjere.

Granica ovog puta: Ona automatski ne odgovara koja pravila kod vas moraju biti „stroga“. To je menadžerska odluka između propusnosti procesa i rizika – i treba biti dokumentirana kako bi se promjene kasnije mogle pratiti.

Posljedice za arhitekturu: središnji servis za provjeru ili provjera u ciljanom sustavu?

U projektu se često pojavi naizgled malo pitanje: „Gdje provjeravamo?“ U praksi ono odlučuje o održivosti i troškovima poslovanja.

Središnja validacija (Service oder Integrationsplattform)

Validacija se izvodi kao središnja usluga: jedinstvena pravila, jedinstvene klase pogrešaka, jedno mjesto za ažuriranja. To olakšava nadzor (npr. stopa odbijanja po dobavljaču/profilu) i pojednostavljuje revizije jer se rezultati provjere dosljedno pohranjuju.

Cijena: morate održavati dodatnu komponentu. Visoka dostupnost, prozori za održavanje, verzioniranje i rollback za ažuriranja pravila postaju obvezni. Za uzvrat stječete kontrolu.

Decentralizirana validacija (ERP/DMS-Plugins, Clients)

Ovdje se provjera odvija u više sustava. To može na kratki rok djelovati privlačno („ERP kann das schon“), ali često vodi do razilaženja: različite verzije validatora, različite poruke o pogrešci, različiti izuzeci. I upravo je to otrov za standardizaciju i podršku.

Za IT‑upravu korisno je pravilo palca: ako je u igri više ulaznih kanala i više ciljnih sustava, središnja usluga za provjeru često je robusnija dugoročna odluka. Ako postoji samo jedan jasan put (jedan ERP, jedan ulaz), decentralizirana provjera može biti prihvatljiva – ali tada bi verzioniranje i dalje trebalo biti uredno regulirano.

Što u projektima kod provjere zaista oduzima vrijeme

Tehnički je čitanje XML‑a rijetko problem. Vrijeme i rizik nastaju na prijelazima:

• Raznolikost profila i verzija: Bez transparentnosti koji partneri šalju koje profile, svaki Release postaje letenje na slijepo. Telemetrija (profil/verzija po ulazu) stoga nije luksuz, nego alat za upravljanje.
• Prevođenje pogrešaka: Izlazi validatora često su previše sirovi za poslovne odjele ili dobavljače. Potrebno ih je mapirati na razumljive kategorije i jasne opcije za postupanje.
• Osnovni podaci i procesi: Strukturirane fakture otkrivaju probleme s osnovnim podacima (nedostajuće dodjeljivanje kreditoru, nekonzistentni brojevi narudžbi). To je korisno, ali isprva stvara više slučajeva za razjašnjenje.
• Lanac dokumenata i arhiva: Za sljedivost nije dovoljno „datoteka pohranjena“. Presudno su: original (PDF/XML), rezultat provjere, verzija seta pravila, vremenska točka i veza s poslovnim procesom (odobrenje, knjiženje).

Uvođenje bez prekida procesa: valovi, fallback i mjerljivi kriteriji

Stabilno uvođenje nastaje kada ne uključujete sve odjednom. Dokazala se logika valova:

• Pilot: mali broj dobavljača i vrsta dokumenata, vrlo detaljno logiranje, svakodnevni pregled najčešćih klasa pogrešaka.
• Stabilizacija: pravila oštriti, ali uz prozore za promjene i jasnu komunikaciju. Ponavljajuće obrasce pogrešaka ciljano razjasniti s nabavom/dobavljačima.
• Skaliranje: nadzor prebaciti u redovni pogon (stopa odbijanja, trajanje razjašnjenja, vodeća kršenja pravila, udio ručnih postupaka).

Planirajte također rad u nuždi. Ako ažuriranje pravila iznenada blokira mnogo računa, trebate kontrolirani fallback (npr. privremeni režim upozorenja umjesto stroge odbijanja) — s dokumentiranom odlukom i naknadnom provjerom. To nije „omekšivač“, nego operativna kočnica protiv nekontroliranih zastoja.

Tri tipična nesporazuma koje biste trebali rano razjasniti

1) „ZUGFeRD ist wie früher ein PDF.“ U procesu je odlučujući ugrađeni XML. PDF je koristan za ljude, ali ne zamjenjuje strojnu provjeru. Ako se PDF i XML razilaze, mora biti jasno koji izvor vrijedi u procesu.

2) „Peppol macht automatisch alles konform.“ Peppol pomaže pri razmjeni i interoperabilnosti. Usklađenost nastaje tek kroz točan sadržaj i odgovarajuće profile. Dostava nije isto što i validacija.

3) „Wenn der Validator grün ist, kann gebucht werden.“ Standardna usklađenost je osnova, a ne potpuna dozvola za proces. Interna pravila (obveznost narudžbe, primitak robe, granice odobrenja) ostaju i trebaju se voditi kao zasebna razina, umjesto da se miješaju u logiku validatora.

Zaključak: Dobra provjera smanjuje opterećenje — ako je koncipirana kao operativni proces

Provjera E‑računa nije sama sebi svrha. Korist nastaje kad se validacija promišlja kao operativni sustav: verzionirana, promatrana, s jasnim klasama pogrešaka i povratnim kanalom koji ne zapada u gužvu tiketa. Tada standardi poput EN 16931, profili poput XRechnung/ZUGFeRD i transportni putovi poput Peppol ne postaju trajna gradilišta, nego upravljivi građevni blokovi u vašem procesnom lancu.

Za ovu temu su također važni provjera ZUGFeRD i validacija XRechnung. Članak te aspekte jasno stavlja u kontekst i pokazuje što je važno u svakodnevnom radu.

Razgovarajte o projektu ili modernizacijskom pothvatu s Net-Base.