E‑Rechnungen prüfen: ZUGFeRD, XRechnung, Peppol und EN 16931 verstehen

Petak, 15:40: Prijem faktura stoji. Ne potpuno – ali baš toliko da boli. Dio pristiglih e‑faktura prolazi uredno, drugi dio ostaje zapet u procesu uvoza. Struka kaže: „U PDF‑u sve izgleda ispravno.“ IT u logu vidi: „Profil nije dozvoljen” i „Poslovno pravilo prekršeno“. Odatle postaje politički: nabava želi protok, knjigovodstvo želi sigurnost, IT ne želi posebnu logiku po dobavljaču.

Ko je u ovoj situaciji provjeravati e‑fakture, brzo shvati: ZUGFeRD, XRechnung, Peppol i EN 16931 nisu puko traženje riječi, već balans. Ovisno o tome koliko strogo provjeravate, mijenjaju se troškovi i rizik – i time i arhitektonske odluke (centralna usluga provjere vs. Plugin im ERP), operativna pitanja (nadzor, Updates, Fallback) i pitanja uvođenja (pilot grupe, komunikacija s dobavljačima, klase grešaka).

Dva cilja koja se u svakodnevnom radu međusobno povlače

Cilj 1: Automatizacija visokog protoka. Mnoge kompanije žele postaviti prijem faktura tako da strukturirane fakture bez prekida medija dospiju u ERP, radni tok i arhivu. To smanjuje ručno unošenje i ubrzava odobrenja – ali samo ako su podaci pouzdani.

Cilj 2: Sigurnost provjere s provjerljivim dokazom. Istovremeno mora biti u sumnji dokazivo zašto je račun prihvaćen ili odbijen: koji profil, koje pravilo, koja verzija. To postaje relevantno najkasnije kada dobavljači reklamiraju („vi ste odbili, ali drugima je prošlo“) ili interne kontrole traže uredan lanac dokumenata.

Oba cilja su legitimna. Sukob nastaje zato što svaka dodatna provjera smanjuje rizike, ali istovremeno stvara više iznimaka. To vrijedi posebno kada dobavljači šalju različite profile ili promjena verzije u specifikaciji još nije svugdje primijenjena.

EN 16931: Warum Sie beim Prüfen Semantik statt „Dateiformat“ managen

EN 16931 se u svakodnevnom radu na projektima rado naziva „das XML-Format“. Praktičnije je drugačiji pogled: EN 16931 je semantički model podataka za ključne elemente elektronskog računa – dakle značenje podatkovnih polja i pripadajuća poslovna pravila (Business Rules) za usklađenost. EU-Kommission svrstava EN 16931 upravo tako: kao semantički model podataka ključnih elemenata uključujući pravila usklađenosti.^[Quelle]

Praktična posljedica za IT i operacije: „XML ist wohlgeformt“ je samo ulazna vrata. Presudno je je li račun semantički konzistentan (logika suma, podatci o porezu, obavezna polja, šifre). I je li u ispravnom profilu – jer profili određuju koje se dijelove standarda i u kojem obliku primjenjuju.

Također je važno da standardi nisu statični. U katalozima normi već je navedeno ažurirano izdanje kao EN 16931‑1:2026.^[Quelle] To ne znači da morate odmah prijeći. Ali znači: vaš model provjere i rada treba biti konstruiran tako da se pravilnici i validatori mogu verzionirati i kontrolirano ažurirati – bez da cjelokupna obrada pri svakom ažuriranju postane nestabilna.

ZUGFeRD und XRechnung: Zwei Wege, dieselbe Pflicht praktisch zu machen

U Njemačkoj se u mnogim kompanijama susreću dvije uobičajene varijante:

• 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: čitljiv dokument plus strojno čitljiv XML u PDF/A‑3.^[Quelle]
• XRechnung kao potpuno strukturirani format: fokus je u potpunosti na strojno obradivim podacima, bez toga da PDF kao sastavni dio „dolazi sa sobom“.

Ravnoteža je manje ideološka nego operativna: ZUGFeRD od odjela često lakše prihvaćaju jer postoji čitljiv dokument. Istovremeno PDF ne smije navoditi na zanemarivanje XML-provjere. XRechnung je jasno orijentiran na podatke i time dobar za automatizaciju, ali u svakodnevnoj upotrebi gotovo uvijek zahtijeva solidan alat za prikaz i provjeru koji sadržaj razumljivo predstavlja.

Rechtlicher Rahmen: Was ab 2025 als „E‑Rechnung“ zählt

Za planiranje projekta posebno je djelotvorna izjava: U kontekstu PDV‑a od 01.01.2025. postoji e‑račun samo ako je izdan/poslan/primljen u strukturiranom elektronskom formatu i omogućuje elektronsku obradu.^[Izvor] Jednostavni PDF bez strukturiranih podataka time ne spada u definiciju koja je ovdje relevantna.

BMF također navodi XRechnung kao i ZUGFeRD od verzije 2.0.1 (s izuzecima profila) kao formate koji u principu ispunjavaju PDV zahtjeve.^[Izvor] Operativno iz toga ne proizlazi „pitanje formata po religiji“, nego jasna obaveza: morate prepoznati, provjeriti i dokumentovati profil i verziju. Inače nije moguć pouzdan gate niti uredan dokaz zašto je faktura tako obrađena.

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

Peppol se u svakodnevnom radu često tretira kao još jedan format računa. To stvara pogrešna 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 usklađenost sa EN‑16931 vidljiva je preko CustomizationID‑šeme (dakle preko identifikatora koji opisuje profil/„Customization“ kontekst). To je važno jer pokazuje: u Peppol okruženju oznake profila i usklađenosti čine dio mašinske obrade i nisu samo „lijepo imati“.^[Izvor]

Što iz toga slijedi u radu, vrlo je opipljivo: pored provjere dokumenta pojavljuju se i transportna pitanja. Adresiranje, ID‑jevi sudionika, tehnička odbijanja, dokazi o dostavi – sve to generira vlastite greške. Ako te greške ne klasificirate odvojeno, na kraju će sve završiti kao „račun pokvaren“ u Finance ili kao „Peppol ne radi“ u IT‑u.

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

Vodič za korištenje ulaznog kanala Peppol za saveznu upravu, na primjer, opisuje formiranje Peppol‑ID‑a iz prefiksa 0204 i Leitweg‑ID‑a za povezane savezne ustanove i locira Peppol Authority Deutschland pri KoSIT.^[Izvor] To je specifičan kontekst (Bund). Preneseno na preduzeća, pouka je ipak jasna: identifikatori nisu marginalna tema. Oni pripadaju u Runbooks, 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 razdvaja provjere u faze. Svjesno odlučujete koja faza djeluje kao strogo granično pravilo (odbijanje), a koja faza izaziva samo upozorenje (razjašnjenje). Sljedeća karta pomaže usporediti tipične opcije.

Provjera E‑računa: put provjere koji opstaje u operativnom radu

Ako proces provjere formulirate tako da se može pronaći u logovima, runbookovima i ticket-sistemima, kasnije trenje u radu se smanjuje. Sljedeći put je namjerno „operativno orijentiran“ i neovisno o tome dolazi li ulaz putem E‑Maila, uploada, API-ja ili Peppol-a.

1. Zabilježiti prijem: Kanal, vremenska oznaka, ID pošiljaoca/primatelja, tehnički metapodaci. To je vaš auditorski trag.
2. Prepoznati kontejner: Čisto XML? ZUGFeRD (PDF/A‑3 s ugrađenim XML-om)? Nešto drugo? U slučaju hibrida: izdvojite XML i tretirajte ga kao zasebni objekt provjere.
3. Odrediti profil i verziju: Koja je varijanta prisutna (npr. EN‑16931-Profil, XRechnung-Version, Peppol BIS Billing mit CustomizationID)? Bez tih informacija provjeravate u prazno.
4. Validacija strukture: Provjera sheme/profila s evidentiranom verzijom validatora i stanjem seta pravila. Rezultat mora biti reproduktivan.
5. Semantička pravila: Procijeniti EN‑16931 poslovna pravila i provjere konzistentnosti (sume/porezi/logika obaveznih polja).
6. Interna poslovna pravila: Usklađivanje osnovnih podataka, veza s narudžbom, provjera duplikata, pravila odobrenja, zahtjevi za kontiranje. Ta pravila su specifična za preduzeće i često se mijenjaju češće od standarda.
7. Upravljati rezultatom: Automatski proslijediti/knjižiti, staviti u razjašnjenje ili odbiti – uključujući klasu greške, kratko obrazloženje i referencu na log provjere.

Granica ovog puta: ona automatski ne odgovara na pitanje koje pravilo kod vas mora biti „strogo“. To je menadžerska odluka između propusnosti procesa i rizika – i treba biti dokumentovana kako bi se promjene kasnije mogle pratiti.

Posljedice za arhitekturu: centralna usluga provjere ili provjera u ciljnom sistemu?

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

Centralna validacija (Service oder Integrationsplattform)

Validacija radi kao centralna usluga: jedinstvena pravila, jedinstvene klase grešaka, jedno mjesto za ažuriranja. To čini monitoring jednostavnijim (npr. stopa odbijanja po dobavljaču/profilu) i olakšava revizije, jer se rezultati provjere dosljedno pohranjuju.

Cijena: upravljate dodatnom komponentom. Visoka dostupnost, prozori za održavanje, verzioniranje i rollback za ažuriranja pravila postaju obaveza. Za uzvrat dobivate veću kontrolu.

Decentralizirana validacija (ERP/DMS-Plugins, Clients)

Ovdje se provjera izvodi u više sistema. To može kratkoročno djelovati privlačno („ERP to već može“), ali često vodi do odstupanja: različite verzije validatora, različite poruke o greškama, različite iznimke. A upravo je to otrov za standardizaciju i podršku.

Za IT‑upravljenje korisno je pravilo palca: ako je u igri više ulaznih kanala i više ciljnih sistema, centralna usluga provjere često je robusnije dugoročno rješenje. Ako postoji samo jedan jasan put (jedan ERP, jedan ulaz), decentralizirana provjera može biti prihvatljiva – ali i tada treba uredno regulisati verzioniranje.

Šta u projektima pri provjerama zaista oduzima vrijeme

Tehnički, učitavanje XML‑a rijetko predstavlja problem. Vrijeme i rizik nastaju na rubovima:

• Raznolikost profila i verzija: Bez transparentnosti koji partneri šalju koje profile, svaki release postaje let na slijepo. Telemetrija (profil/verzija po ulazu) stoga nije luksuz, već instrument upravljanja.
• Prevođenje grešaka: Izlazi validatora često su previše sirovi za poslovne odjele ili dobavljače. Potrebno ih je mapirati na razumljive kategorije i opcije za djelovanje.
• Osnovni podaci i procesi: Strukturirane fakture otkrivaju probleme s osnovnim podacima (nedostajuće dodjele kreditoru, nekonzistentni brojevi narudžbi). To je dobro, ali u početku stvara više slučajeva za razjašnjenje.
• Lanac dokumenata i arhiva: Za sljedivost nije dovoljno „Datei abgelegt“. Presudni su: original (PDF/XML), rezultat provjere, verzija skupa pravila, vrijeme i veza s poslovnim procesom (odobrenje, knjiženje).

Rollout bez prekida procesa: talasi, fallback i mjerljivi kriteriji

Stabilan Rollout nastaje ako ne aktivirate sve odjednom. Pokazala se logika valova:

• Pilot: nekoliko dobavljača i tipova dokumenata, vrlo detaljno logiranje, dnevna provjera najčešćih klasa grešaka.
• Stabilizacija: dotjerivanje pravila, ali uz prozore za promjene i jasnu komunikaciju. Ponavljajuće greške uzorka ciljano razjasnite s nabavom/dobavljačima.
• Skaliranje: prebaciti monitoring u redovni rad (stopa odbijanja, trajanje razjašnjenja, najčešća kršenja pravila, udio ručnih intervencija).

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

Tri tipična nesporazuma koja biste trebali odmah razjasniti

1) „ZUGFeRD je kao prije PDF.“ U procesu se računa 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 automatski sve čini usklađenim.“ Peppol pomaže u razmjeni i interoperabilnosti. Usklađenost nastaje tek kroz ispravne sadržaje i odgovarajuće profile. Dostava nije isto što i validacija.

3) „Ako je validator zelen, može se knjižiti.“ Standardna usklađenost je osnova, ne potpuna procesna odobrenja. Interna pravila (obaveza narudžbe, prijem robe, granice odobrenja) ostaju na snazi i trebala bi se voditi kao zasebna razina, umjesto da se miješaju u logiku validatora.

Zaključak: Dobra provjera rasterećuje – ako je izgrađena kao operativni proces

Provjera e‑faktura nije svrha sama po sebi. Korist nastaje kada se validacija zamišlja kao operativni sustav: verzioniran, promatran, s jasnim klasama grešaka i povratnim kanalom koji ne završava u zagušenju sustava za tikete. Tada standardi poput EN 16931, profili poput XRechnung/ZUGFeRD i transportni putevi poput Peppol ne postaju dugotrajni gradilište, već upravljivi građevni blokovi u vašem procesnom lancu.

Za ovu temu su također važne provjera Zugferd i validacija Xrechnung. Članak svrstava ove aspekte na razumljiv način i pokazuje na što je važno obratiti pažnju u svakodnevnom radu.

Razgovarajte o projektu ili planu modernizacije sa Net-Base.