E-računi za upravnike stavb: XRechnung in ZUGFeRD

Dobaviteljev račun že dvajset let potuje po isti poti: prispe kot PDF v upravnikov e-poštni predal, nekdo z zaslona prebere znesek, ga pretipka v preglednico ali računovodsko orodje, PDF shrani v mapo in upa, da bosta oba ostala usklajena. Pomnožite to z vsako pogodbo o vzdrževanju dvigala, čistilnim servisom, zavarovalno polico in enkratnim popravilom po vsem portfelju stavb, in pretipkavanje računov postane resen del pisarniškega dela ene Hausverwaltung, nemške upravniške družbe.

Ta doba se končuje, po zakonu. Od januarja 2025 mora biti vsako nemško podjetje sposobno prejeti strukturiran elektronski račun za domače posle med podjetji, obveznost izdajanja pa se uvaja postopoma v letih 2027 in 2028. Upravniki stavb so sredi tega kroga: upravljanje denarja stavbe je poslovna dejavnost, dobavitelji so podjetja in vse pogosteje bodo pošiljali XML ne glede na to, ali je prejemna stran pripravljena.

Večina zapisov to predstavlja kot breme skladnosti. Resnica je ravno nasprotna. Obveznost sili dobavitelje, da račune pošiljajo v strojno berljivi obliki, kar pomeni, da se doba pretipkavanja lahko konča, če je prejemanje postavljeno prav. Tukaj je, kaj ta formata v resnici sta in kako izgleda pravilen potek prejemanja.

PDF ni več račun

E-račun v pravnem smislu ni PDF računa. Je strukturirana datoteka, skladna z evropskim standardom EN 16931: prodajalec, zneski, datumi, plačilni podatki, vse kot strojno berljiva polja. V Nemčiji prevladujeta dva formata:

Hibridna oblika skriva past, ki jo je vredno poznati. Račun ZUGFeRD, obdelan po starem, tako da ga človek z očmi prebere iz PDF in ga pretipka, tiho spregleda strukturirano plast. Številke na vizualni plasti in v XML naj bi se ujemale, a račun je tisti strojno berljivi del. Potek dela, ki se dotakne le slikovnih pik, obdeluje sliko računa in zavrže sam račun.

Prejemanje, kot je prav: preberi, pokaži, potrdi

Pravilno prejemanje ima tri korake in le eden vključuje človeka.

Prvič, datoteka vstopi, XRechnung XML ali ZUGFeRD PDF, in stroj prebere strukturirana polja: kdo je pošiljatelj, številka računa, datum izdaje in datum zapadlosti, neto, davek in bruto znesek, IBAN za plačilo. Brez pretipkavanja, brez branja številk z zaslona.

Drugič, ta prebrana polja se vam pokažejo v jasni, človeku berljivi obliki. To je najpomembnejše pri XRechnungu, ki brez tega koraka ostane zid XML, na katerega nihče ne more odreagirati, velja pa tudi za hibride: kar vidite, je tisto, kar strojna plast dejansko pove, in ne tisto, kar PDF slučajno prikaže.

Tretjič, potrdite, enkrat, in račun postane osnutek stroška v knjigah stavbe, s prebranim zneskom in dobaviteljem. Od tam živi običajno življenje stroška: čaka na bančni izpisek, plačilna vrstica se poveže z njim, status pa se izračuna sam, tako kot pri vsakem strošku stavbe.

Ena datoteka noter, ena potrditev, en knjižen strošek. To je vsa ročna površina tega poteka.

Zakaj korak potrditve ni izbiren

Pošteno vprašanje: če stroj prebere vse, zakaj sploh potrjevati? Zakaj računov ne bi knjižili samodejno, takoj ko prispejo?

Ker je branje zanesljivo, odgovornosti pa ni mogoče prenesti. Račun je lahko strojno popoln in vseeno napačen: podvojen, znesek se ne ujema s pogodbo, storitev ni bila nikoli naročena, ali pa gre za čisto goljufijo. Goljufije s spremenjenimi plačilnimi podatki so resničen in vse pogostejši vzorec, zaslon za potrditev pa je natanko mesto, kjer umrejo: prebrani IBAN stoji pred človekom, ki ve, kateri račun je dvigalno podjetje vedno imelo. Potek dela, ki knjiži samodejno, izbriše edini trenutek, v katerem se uporabi upravnikova presoja, in prav to stavba dejansko plačuje.

Zato je pravilna zasnova namerna: stroj opravi vse branje, človek sprejme eno odločitev. Vse, kar je bolj samodejno, optimizira stran prav tisto, zaradi česar vse skupaj obstaja.

Načelo. Naj stroj bere, človek pa odloča. Potek dela za e-račune mora ročno delo skrčiti na natanko eno potrditev na račun, nikoli pa na nič.

Arhivirajte izvirnik, ne izrisa

Nemška pravila o hrambi dokumentacije zahtevajo, da se računi hranijo osem let, in tu velja ista logika kot pri hibridni obliki: hraniti je treba izvirno datoteko, XML ali hibridni PDF natanko takšen, kot je prispel, ne posnetka zaslona, ne človeku berljivega izrisa, ne ponovnega izvoza. Izris je udobje za danes; izvirnik je dokazilo za nadzornika v sedmem letu.

Zato mora orodje za prejemanje izvirnik shraniti nespremenljivo, ob strošku, ki je iz njega nastal, in mora biti vedno sposobno vrniti natanko tiste bajte, ki so prispeli. Če orodje shranjene račune znova ustvarja ali “pospravlja”, arhivira svojo risbo namesto dokumenta.

Kam račun potuje naprej

Tiho plačilo za prejemanje računov kot podatkov je vse, kar sledi. Potrjeni strošek se vključi v verigo transakcij stavbe, kar pomeni:

Preštejte človeške dotike na vsej tej poti: enega. Račun je bil potrjen enkrat, vsak poznejši uporabnik, lastnik, zbor, računovodja, nadzornik, pa bere zapise, izpeljane iz tega enega potrjenega dejstva.

Česa še ni in zakaj vseeno začeti

Dva dostavna kanala na trgu še dozorevata: samodejni prevzem računov, ki pridejo po e-pošti, in omrežje Peppol za izmenjavo strukturiranih računov. Danes je zanesljiva osnova nalaganje: datoteka računa, kakor koli je prišla do vas, gre v orodje, naprej pa prevzame zgoraj opisani potek.

Ta osnova je že vsa pridobitev. Cena e-računov nikoli ni bil klik na nalaganje, ampak pretipkavanje, neusklajene mape in lov na račune vsak januar. Ti se končajo tisti dan, ko namesto vas začne XML brati programska oprema. Obveznost je dobavitelje prisilila, da opravijo težjo polovico; polovica s prejemanjem je zdaj stvar odločitve.

Zamenjajte skupinski klepet v treh minutah.

Brezplačno za eno stavbo. Brez kreditne kartice. Brez 30-minutnega uvodnega klica.

Brezplačno preizkusite Kvaro