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

Föstudagur, kl. 15:40: Innkomandi reikningur stendur. Ekki alveg – en nákvæmlega þannig að það sársaukast. Hluti af innkomandi E‑reikningum fer hreint í gegn, annar hluti festist í innflutningsleiðinni. Fagdeildin segir: „Í PDF-inu lítur allt rétt út.“ IT sér í logginu: „Prófill ekki leyfður“ og „Viðskiptareglan brotin“. Frá þeim tímapunkti verður þetta pólitískt: Innkaup vilja háan gegnumstreymi, bókhald vill öryggi, og IT vill enga sérreglu fyrir hvern birgja.

Sá sem á að yfirfara rafræna reikninga í þessari stöðu sér fljótt: ZUGFeRD, XRechnung, Peppol og EN 16931 eru ekki orðakarlast, heldur vegið og metið. Fer eftir hversu stranglega þið yfirfarið, færist vinnuframlag og áhætta – og þar með arkitektúrákvarðanir (miðlægur prófunarþjónn vs. viðbót í ERP), rekstrartengdar spurningar (eftirlit, uppfærslur, varaplan) og innleiðingarmál (prófunarhópar, samskipti við birgja, villuflokkar).

Tvö markmið sem toga hvor aðra í daglegu starfi

Markmið 1: Sjálfvirkni með miklu gegnumstreymi. Mörg fyrirtæki vilja setja upp móttöku reikninga þannig að uppbyggðir reikningar komi inn í ERP, vinnuflæði og skjalasafn án miðlabrúa. Þetta dregur úr handvirkri skráningu og flýtir samþykktum – en aðeins ef gögnin eru áreiðanleg.

Markmið 2: Staðfesting á prófun með rekjanlegum sönnunargögnum. Á sama tíma verður að vera hægt að sanna, sé deilt, hvers vegna reikningur var samþykktur eða hafnað: hvaða prófíll, hvaða regla, hvaða útgáfa. Þetta verður sérstaklega mikilvægt þegar birgjar kvarta („þið hafið hafnað, en hjá öðrum gekk það“) eða innra eftirlit spyr um hreina skjalskeðju.

Báðar kröfurnar eru réttmætar. Áreksturinn myndast vegna þess að hver viðbótarprófun minnkar vissulega áhættu en getur líka skapað fleiri undantekningar. Þetta á sérlega við þegar birgjar senda mismunandi prófíla eða þegar útgáfubreyting í tilgreiningunni hefur ekki borist alls staðar enn.

EN 16931: Hvers vegna við skoðun ætti að stýra merkingu (semantík) fremur en „skráarsniði“

Í daglegu verkefnaverki er EN 16931 gjarnan nefndur „XML-sniðið“. Hagnýtara sjónarhorn er þó annað: EN 16931 er semantískt gagnalíkan fyrir kjarnaþætti rafræns reiknings – þ.e. merking gagnareita og viðeigandi viðskiptareglur (Business Rules) fyrir samræmi. Framkvæmdastjórnin flokkar EN 16931 nákvæmlega svona: sem semantískt gagnalíkan kjarnaþátta með reglunum um samræmi.^[Heimild]

Hagnýt niðurstaða fyrir IT og rekstur: „XML er rétt uppbyggt“ er aðeins inngangur. Mikilvægt er hvort reikningur sé í merkingu samræmdur (samræmi summna, skattaupplýsingar, skyldureitir, kóðar). Og hvort hann sé í rétta prófílnum – því prófílar skilgreina hvaða hlutar stöðulsins gilda í hvaða mynd.

Mikilvægt er jafnframt að staðlar frjósi ekki. Í staðlasafni er þegar skráð uppfærð útgáfa sem EN 16931‑1:2026.^[Heimild] Það þýðir ekki að þið verðið að skipta yfir strax. Það þýðir hins vegar að prófunar- og rekstrarlíkan ykkar ætti að vera byggt þannig að reglur og sannprófunartól séu útgáfustýrð og geti verið uppfærð á stjórnandi hátt – án þess að allri vinnslu verði ógnað eða hún verði óróleg við hverja uppfærslu.

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

Í Þýskalandi rekast í mörgum fyrirtækjum á tvær algengar útfærslur:

• ZUGFeRD sem tvíeðlis snið: PDF/A‑3-skrá þar sem uppbyggð reikningsgögn (XML) eru innfelld. FeRD lýsir ZUGFeRD 2.2 skýrt sem tvíeðlis módeli: lesanlegt reikningsskjal auk vélalesanlegs XML í PDF/A‑3.^[Heimild]
• XRechnung sem hreint strúktúra-snið: áherslan er alfarið á vélvinnanleg gögn, án þess að PDF fylgi sem hluti.

Matið er fremur rekstrarlegt en hugmyndafræðilegt: ZUGFeRD er oft auðveldara fyrir fagdeildir að samþykkja vegna þess að til er lesanlegt reikningsskjal. Á sama tíma má PDF-ið ekki leiða til þess að XML-prófun sé vanrækt. XRechnung er skýrlega gagnamegin og því hentug fyrir sjálfvirkni, en krefst í venjulegu rekstrarumhverfi nánast alltaf góðs birtingar- og prófunartækis sem gerir innihaldið skiljanlegt.

Lagarammi: Hvað telst frá og með 2025 sem „E‑Rechnung“

Fyrir verkefnisáætlun er ein fullyrðing sérstaklega áhrifarík: Í virðisaukaskattslegu samhengi telst rafrænn reikningur aðeins frá og með 01.01.2025 ef hann er útgefinn/sendur/móttakaður í uppbyggðu rafrænu formi og gerir rafræna vinnslu mögulega.^[Quelle] Hreint PDF án uppbyggðra gagna fellur því ekki undir þá skilgreiningu sem hér skiptir máli.

BMF nefnir jafnframt XRechnung ásamt ZUGFeRD frá útgáfu 2.0.1 (með undantekningum á prófílum) sem snið sem á grundvallarnivå uppfylla kröfur virðisaukaskatts.^[Quelle] Rekstrarlega leiðir þetta ekki til „Format-Religionsfrage“, heldur skýrrar skyldu: Þið þurfið að greina prófíl og útgáfu, athuga þau og skjalfesta á eftirfylgjanlegan hátt. Annars er hvorki mögulegt að hafa áreiðanlegt „Gate“ né að leggja fram skýran sönnunargagn fyrir því hvers vegna reikningur var meðhöndlaður á þann hátt.

Setja Peppol í rétt samhengi: Flutningur og samvirkni fremur en „annað snið“

Í daglegu rekstri er Peppol oft meðhöndlað sem eitt til viðbótar reikningssnið. Það veldur röngum væntingum. Peppol er fyrst og fremst yfirfærslu- og samvirknirammi fyrir uppbyggð viðskiptagögn. Fyrir reikninga er Peppol BIS Billing 3.0 viðeigandi þáttur.

Í opinberu BIS-Billing-skjölunum sést EN‑16931-samhæfi í gegnum CustomizationID-skjemað (þ.e. með auðkenni sem lýsir prófíl-/„Customization“-samhenginu). Þetta er mikilvægt vegna þess að það sýnir: Í Peppol-umhverfi eru prófíls- og samræmisauðkenni hluti af vélrænum úrvinnslu og ekki aðeins „nice to have“.^[Quelle]

Af þessu leiðir í rekstri mjög handfast niðurstaða: Fyrir utan skjalaskoðun bætast við flutningsmál. Heimilisfangssetning, þátttakenda-auðkenni, tæknilegar höfnanir, afhendingarvottorð – allt þetta skapar sérkennd villumynstur. Ef þið flokkið þessar villur ekki aðskildar endar allt saman sem „reikningur ónýtur“ hjá fjármáladeild eða sem „Peppol er að bila“ hjá upplýsingatæknideildinni.

Leitweg-ID & Peppol-ID: Af hverju auðkenni eru gagnrýniverð í framleiðslu

Leiðarvísirinn um notkun inntakskanalsins Peppol fyrir sambandsstjórnina lýsir til dæmis myndun Peppol-ID úr forskeytinu 0204 og Leitweg-ID fyrir tengdar sambandsstofnanir og staðsetur Peppol Authority Deutschland hjá KoSIT.^[Quelle] Þetta er sértækt samhengi (Bund). Flytjanleg lærdómur fyrir fyrirtæki er engu að síður skýr: Auðkenni eru ekki jaðarmál. Þau eiga heima í Runbooks, prófunartilvikum og stillingum – því „rangt ID“ hindrar í rekstri á sama hátt og „rangt prófíl“.

Ákvörðunarkort: Prófastefna eftir ávinningi, fyrirhöfn og áhættu

Hagnýt stefna skiptir prófunum í stig. Þið ákveðið meðvitað hvaða stig virkar sem hart „Gate“ (höfnun) og hvaða stig aðeins kallar fram viðvörun (skýring). Eftirfarandi kort hjálpar til við að bera saman dæmigerða valkosti.

E‑reikninga skoða: Prófunarleið sem stendur undir rekstri

Ef þið orðar prófunarferlið þannig að það finnst í loggum, runbooks og tikettakerfum, minnkar seinna rekstrarviðnám. Eftirfarandi leið er meðvitað rekstrarorientuð og óháð því hvort inntakið kemur með E‑pósti, upphleðslu, API eða Peppol.

1. Skrá móttöku: rás, tími, sendanda-/móttakanda-ID, tæknileg metagögn. Þetta er endurskoðunarspor ykkar.
2. Greina container: Hreint XML? ZUGFeRD (PDF/A‑3 með innfelldu XML)? Annað? Í hybridtilvikum: ná út XML og meðhöndla sem aðskilið prófunarefni.
3. Ákvarða prófíl og útgáfu: Hvaða útgáfa liggur fyrir (t.d. EN‑16931-prófíl, XRechnung-útgáfa, Peppol BIS Billing með CustomizationID)? Án þessara upplýsinga er prófun blind.
4. Strúktúrstaðfesting: Snið-/prófílskoðun með skrásettri Validator-útgáfu og stöðu reglusetts. Niðurstaðan verður að vera endurleikin.
5. Merkingarreglur: EN‑16931 viðskiptareglur og samhengisprófanir (samtalsupphæðir/skattar/skyldulógík) skoðaðar.
6. Innri viðskiptareglur: samanburður grunnupplýsinga, tenging við pöntun, tvítekningaathugun, samþykktar reglur, kröfur um færslugerð. Þessar reglur eru fyrirtækissértækar og breytast oftar en staðlar.
7. Stýra niðurstöðu: Sjálfvirk áframvísun/bókun, senda til úrvinnslu eða hafna – með villuflokki, stuttri röksemd og tilvísun í prófunarskrá.

Takmörk þessa ferils: Hann svarar ekki sjálfkrafa hvaða regla þarf að vera „hörð“ hjá ykkur. Þetta er stjórnunarleg ákvörðun milli ferilsflæðis og áhættu – og ætti að vera skjalfest svo breytingar verði hægt að rekja síðar.

Arkitektúrleiðingar: Miðlæg prófunarþjónusta eða prófun í markkerfinu?

Í verkefninu vaknar oft á yfirborðinu lítil spurning: „Hvar prófum við?“ Í raun og veru ræður hún um viðhald og rekstrarkostnað.

Miðlæg staðfesting (Service oder Integrationsplattform)

Staðfestingin keyrir sem miðlæg þjónusta: samræmdar reglur, samræmdir villuflokkar, einn staður fyrir uppfærslur. Þetta einfaldar eftirlit (t.d. höfnunarhlutfall per birgir/prófíl) og auðveldar úttektir, því niðurstöður prófana eru vistaðar á samræmdan hátt.

Kostnaðurinn: Þið rekið aukahluta. Hátiltækni, viðhaldsgluggar, útgáfustýring og afturköllun fyrir reglufriss verða nauðsyn. Í skiptum öðlast þið betri stjórn.

Dreifð staðfesting (ERP/DMS-Plugins, Clients)

Hér er prófað í mörgum kerfum. Þetta getur virst aðlaðandi til skemmri tíma („ERP kann das schon“), en leiðir oft til driftingar: mismunandi validator-útgáfur, mismunandi villuskilaboð, mismunandi undantekningar. Og einmitt það er eitrið fyrir stöðlun og stuðning.

Fyrir IT-stjórn er einföld regla gagnleg: Ef mörg inngönguleiðir og mörg markkerfi koma til greina, er miðlægur prófunarþjónusta oft traustari langtímaákvörðun. Ef aðeins er ein skýr leið (eitt ERP, eitt inntak) getur dreifð prófun verið ásættanleg – en þá ætti útgáfustjórnun samt að vera vel mótuð.

Hvað í verkefnum kostar raunverulega tíma við prófanir

Tæknilega er innlestur XML sjaldan vandamálið. Tími og áhætta skapast á jaðrinum:

• Fjölbreytileiki prófíla og útgáfa: Án gagnsæis um hvaða samstarfsaðilar senda hvaða prófíla verður hver útgáfa blindflugsverk. Telemetría (prófíl/útgáfa per inntak) er því ekki lúxus heldur stjórnunarverkfæri.
• Villuflokkun: Úttökur frá Validator eru oft of hráar fyrir fagdeildir eða birgja. Þær þarf að kortleggja í skiljanlega flokka og viðbragðsvalkosti.
• Grunnupplýsingar og ferlar: Uppbyggðir reikningar gera vandamál í grunnupplýsingum sýnileg (vantar úthlutun birgja, ósamræmi í pöntunarnúmerum). Það er gott, en veldur í byrjun fleiri skýringarmálum.
• Skjalakeðja og skjalageymsla: Fyrir eftirrekjanleika nægir ekki einungis „skrá vistuð“. Ákvarðandi eru: upprunalegt skjal (PDF/XML), niðurstaða prófunar, útgáfunúmer reglusetts, tímasetning og tenging við viðskiptaferilinn (samþykki, bókun).

Innleiðing án ferlabrests: bylgjur, fallback og mælanleg skilyrði

Stöðug innleiðing fæst þegar ekki er allt virkjað í einu. Bylgjuaðferð hefur reynst vel:

• Pilot: fáir birgjar og skjalaflokkar, mjög nákvæm atburðaskráning (logging), daglegt yfirlit yfir algengustu villuflokka.
• Stöðugleiki: skerpa reglur, en með stjórnðum breytingaglugga og skýrum samskiptum. Endurtekna mynsturvillur skal leysa markvisst með innkaupadeild/ birgjum.
• Uppskalun: flytja monitoring inn í reglubundinn rekstur (höfnunarhlutfall, skýringartími, helstu reglubrots, hlutfall handvirkra tilfella).

Skipuleggið einnig neyðarrekstur. Ef reglufrísuppfærsla hindrar skyndilega mörg reikningsmál þarfnast þið stjórnaðrar varaleiðar (t.d. tímabundinn viðvörunarhamur í stað harðrar synjunar) – með skjalfestri ákvörðun og síðar endurskoðun. Þetta er ekki „mjúkandi aðferð“, heldur rekstrarhemlar gegn óstýrðum stöðvunum.

Þrjú algeng misskilningamál sem þarf að leysa snemma

1) „ZUGFeRD ist wie früher ein PDF.“ Í ferlinu skiptir innfellt XML mestu. PDF er hjálplegt fyrir mannfólk en kemur ekki í stað vélrænnar prófunar. Ef PDF og XML fara ekki saman þarf skýrt að ákvörða hvor uppspretta ræður í ferlinu.

2) „Peppol macht automatisch alles konform.“ Peppol hjálpar við flutning og samvirkni. Samræmi fæst fyrst með réttu innihaldi og viðeigandi prófílum. Sending er ekki jafngilt staðfestingu.

3) „Wenn der Validator grün ist, kann gebucht werden.“ Staðlað samræmi er grunnur, ekki full útgáfa ferilsins. Innri reglur (pöntunarskylda, móttaka vöru, samþykkismörk) halda áfram að gilda og eiga að vera reknar sem sértakt stig fremur en að blanda þær inn í validator-rökfræði.

Lokaorð: Góð staðfesting dregur úr álagi – ef hún er uppbyggð sem rekstrarferli

Að sannreyna rafræna reikninga er ekki sjálfstæður tilgangur. Ávinningurinn kemur þegar gildisskoðun er hugsuð sem rekstrarkerfi: með útgáfustýringu, eftirlitsmöguleikum, skýrum villuflokkum og bakleið sem festist ekki í miðaþröng. Þá verða staðlar eins og EN 16931, prófílar eins og XRechnung/ZUGFeRD og flutningsleiðir eins og Peppol ekki sífellt viðhaldsmál heldur stýranlegir þættir í ferlaketju ykkar.

Fyrir þetta efni skipta einnig Zugferd Prüfen und Xrechnung Validieren máli. Greinin setur þessa þætti í skiljanlegt samhengi og sýnir, hvað skiptir máli í daglegu starfi.

Ræddu verkefni eða nútímavæðingarverkefni með Net-Base.