VERI*FACTU in lastna programska oprema za izdajanje računov: kaj Španija zahteva do 1. januarja 2027

Pred 1. januarjem 2027 mora vsako podjetje v Španiji, ki oddaja obračun davka od dohodkov pravnih oseb (Impuesto sobre Sociedades) in račune izdaja s programsko opremo, uporabljati programsko opremo, prilagojeno odloku Real Decreto 1007/2023. Vsak račun dobi zapis z zgoščeno vrednostjo, ki je verižno povezan s prejšnjim, in kodo QR, s katero ga kupec lahko preveri pri davčni upravi. Vsi drugi zavezanci, večinoma samozaposleni, imajo čas do 1. julija 2027.

Če vaši računi nastajajo v komercialnem paketu, je to večinoma naloga vašega ponudnika. Če nastajajo v programski opremi, ki jo je nekdo napisal za vas ali jo je napisala vaša ekipa, je naloga vaša. Vi spremenite kodo in vi podpišete izjavo, da je skladna.

Datumi in dve preložitvi

To je že tretji niz datumov, zato je nekaj skepse upravičene.

• Real Decreto 1007/2023 je podjetjem prvotno dal čas do 1. julija 2025.
• Real Decreto 254/2025 z dne 1. aprila 2025 je rok prestavil na 1. januar 2026 za zavezance za davek od dohodkov pravnih oseb in na 1. julij 2026 za druge. Razlog je bil konkreten: tehnična odredba, Orden HAC/1177/2024, je bila objavljena šele 28. oktobra 2024.
• Real Decreto-ley 15/2025 z dne 2. decembra 2025 je oba datuma premaknil za leto dni. Njegovo besedilo je v BOE, kongres pa ga je potrdil še isti mesec.

Obvestilo AEAT o podaljšanju, posodobljeno 26. marca 2026, je nedvoumno: „las entidades que presenten el Impuesto sobre Sociedades deberán tener adaptados sus SIF antes del 1 de enero de 2027. El resto de obligados tributarios, antes del 1 de julio de 2027.“ Subjekti, ki oddajajo obračun davka od dohodkov pravnih oseb, morajo torej svoje sisteme za izdajanje računov (SIF) prilagoditi pred 1. januarjem 2027, vsi drugi zavezanci pa pred 1. julijem 2027.

Se lahko rok spet premakne? Oktobra 2026 nič uradnega tega ne nakazuje. Prva preložitev je imela tehničen vzrok, ki ne obstaja več. Storitve AEAT za oddajo zapisov so v produkciji od 23. aprila 2025, od 29. julija 2025 pa ponudniki programske opreme smejo ponujati le prilagojene sisteme. Računati na tretjo preložitev je stava, ne načrt.

Kateri datum je vaš? Družba SL ali SA oddaja Impuesto sobre Sociedades, zato je podjetje z lastnim ERP skoraj zagotovo vezano na datum 1. januar 2027. Do njega so manj kot trije meseci. Julijski datum velja za samozaposlene in druge zavezance v obsegu.

Kdo je zajet in kdo ne

Pogosta vprašanja AEAT o obsegu obseg skrčijo na štiri nikalne pogoje. Zajeti ste, če računov ne izdajate izključno ročno, niste v sistemu SII (obvezno ali po lastni izbiri), nimate davčnega sedeža v Baskiji ali Navarri in nimate odločbe o izvzetju.

Izjeme v praksi:

• Zavezanci v SII. Suministro Inmediato de Información je obvezen za podjetja s prometom nad 6 milijonov evrov, skupine za DDV in podjetja v registru za mesečno vračilo DDV (REDEME), drugi pa se lahko vključijo prostovoljno. AEAT pove naravnost: „El ámbito subjetivo de ambos proyectos es excluyente.“ Projekta se po krogu zavezancev torej izključujeta. Če preidete v SII, nehate pošiljati zapise VERI*FACTU in nehate tiskati kodo QR.
• Baskija in Navarra. Podjetja z davčnim sedežem tam so podrejena foralnim davčnim organom in njihovim lastnim pravilom, ne RD 1007/2023.
• Povsem ročno izdajanje računov. Papirnata knjiga računov ni zajeta. Prav tako ne preglednica, ki se uporablja samo za tipkanje, tiskanje in hrambo računov; preglednica, ki ustvarja tudi vaše knjige DDV, pa je zajeta.

Tuja podjetja so zajeta, kadar imajo v Španiji stalno poslovno enoto.

Če račune izdajate v komercialnem paketu (A3, Sage, Holded in podobni), je proizvajalec ponudnik, ki mora dobaviti prilagojeno različico s svojo izjavo. Posodobite jo, preverite, ali je izjava na voljo, in lahko nehate brati.

Ta članek je za vse druge: lastni ERP, program v Accessu, Delphiju ali FileMakerju, napisan pred petnajstimi leti, ali modul za obračun znotraj vaše lastne spletne platforme.

Vaše podjetje je proizvajalec

Člen 13.1 uredbe certificiranje nalaga tistemu, ki sistem proizvede, in sicer z izjavo declaración responsable. Pogosta vprašanja AEAT o certificiranju na primer lastnega razvoja odgovarjajo neposredno: „Cada sistema en operación debe disponer de una Certificación emitida mediante declaración responsable de su productor (artículo 13.1 RRSIF). Si el software hubiera sido desarrollado por la propia empresa, será esta la que deba certificarlo.“ Vsak sistem v uporabi mora torej imeti certifikat, izdan z izjavo proizvajalca, in če je programsko opremo razvilo podjetje samo, jo mora certificirati podjetje.

Kaj to pomeni v praksi:

• Zunanje revizije ni. AEAT to imenuje „auto-certificación“ proizvajalca. Nihče vašega sistema vnaprej ne odobri. Podpišete in odgovarjate zanj.
• Izvajalec, ki za vas kot izdelek zgradi razširitev, certificira to razširitev. Če ste jo zgradili sami, jo certificirate vi.
• Izjava mora biti vidna v sistemu, v vsaki različici, in dosegljiva tudi zunaj njega, neodvisno od izdelka.
• Njena vsebina je določena v členu 15 odredbe Orden HAC/1177/2024: med drugim ime, identifikator in različica sistema, njegove komponente, ali deluje samo v načinu VERI*FACTU, ime, NIF in naslov proizvajalca ter datum in kraj podpisa.

Neroden primer je program, katerega avtor je odšel pred leti. Nekdo mora vseeno izdelati prilagojeno različico in jo podpisati. Pisno določite, kdo je to, preden se delo začne.

Prilagoditev certificiranega komercialnega izdelka zahteva ločeno izjavo le, če sprememba posega v način, kako so izvedene zahteve uredbe. Sprememba, narejena zunaj nadzora proizvajalca, ki jih lahko spremeni, ni skladna.

Kaj je na kocki, določa člen 201 bis splošnega davčnega zakona: fiksna globa 150.000 € na poslovno leto in na vrsto sistema za proizvodnjo sistemov, ki zahtev ne izpolnjujejo, in 50.000 € na poslovno leto za posedovanje sistema, ki bi moral biti certificiran, pa ni, ali je bil spremenjen. Katera od teh glob bi doletela sistem lastne izdelave, je vprašanje za vašega davčnega svetovalca. Nobena ni majhna.

Kaj mora programska oprema delati

Zapis za vsak račun, v trenutku izdaje

Člen 9.1 zahteva, da sistem ustvari registro de facturación de alta „de forma simultánea o inmediatamente anterior a la expedición de cada factura“, torej hkrati z izdajo vsakega računa ali tik pred njo. Za razveljavljen račun se ustvari zapis o preklicu (registro de anulación).

Člen 10 našteva, kaj zapis vsebuje: NIF in ime izdajatelja, prejemnika, kadar je zahtevan, serijo in številko, datum izdaje in datum transakcije, vrsto računa, podatke o morebitnem računu, ki ga popravlja, opis, skupni znesek, režim DDV, davčno osnovo, stopnje in zneske, razloge za oprostitev ali neobdavčljivost, identiteto sistema in njegovega proizvajalca ter časovni žig na sekundo natančno.

Pri starejših sistemih se delo skriva tu:

• Razčlenitve DDV se pogosto izračunajo ob tiskanju in se nikoli ne shranijo. V trenutku izdaje morajo obstajati kot podatek.
• „Izdaja“ je pogosto samo tiskanje poročila. Obstajati mora izrecna točka, v kateri osnutek postane račun, in takrat nastane zapis.
• Ponovne uporabe številk je konec. Brisanje računa in ponovna uporaba njegove številke, navada v marsikaterem majhnem sistemu, zdaj ne gre več: AEAT drugi zapis zavrne kot „Registro de facturación duplicado.“ Testni računi, izdani v produkciji, so pravi računi in jih je treba preklicati.
• Nihče ne ureja zapisov. Pogosta vprašanja AEAT navajajo, da neposredne spremembe baze izdanih zapisov ne smejo biti dovoljena operacija. Če zaposleni danes popravljajo račune z ukazi SQL, se to konča. Popravki gredo prek popravljalnih računov.

Veriga zgoščenih vrednosti

Vsak zapis nosi serijo, številko in datum prejšnjega zapisa ter del njegove zgoščene vrednosti (huella). Algoritem je SHA-256, natančna polja in način združevanja pa so v tehnični dokumentaciji AEAT, skupaj z zasnovami zapisov, shemami XSD, WSDL ter katalogom preverjanj in napak.

Preden ustvari nov zapis, mora sistem preveriti, ali je zadnji pravilno vključen v verigo in ali njegov časovni žig ni za več kot eno minuto poznejši od trenutnega časa. Zapisi nastajajo v vrstnem redu izdaje računov.

To ima arhitekturno posledico. Vsaka namestitev potrebuje eno samo, serializirano točko, v kateri nastajajo zapisi. Dva spletna strežnika, ki brez usklajevanja dodajata v isto verigo, jo bosta pretrgala. AEAT sprejema mešane postavitve, na primer blagajniške terminale, ki zapis prejmejo iz osrednjega zalednega sistema, sama veriga pa živi na enem mestu.

Vsak sistem je označen z NIF zavezanca, dvoznakovnim ID sistema in številko namestitve, ki se nikoli ne sme ponoviti, tudi ko se ista programska oprema znova namesti na isti računalnik.

Koda QR na računu

Vsak račun nosi kodo QR po ISO/IEC 18004, velikosti od 30x30 do 40x40 mm, s stopnjo popravljanja napak M. Kodira URL, ki vsebuje NIF izdajatelja, serijo in številko, datum izdaje in skupni znesek, kar lahko kupec preveri pri AEAT. V načinu VERI*FACTU je na računu tudi navedba „VERI*FACTU“ ali „Factura verificable en la sede electrónica de la AEAT“.

Za starejšo programsko opremo to pomeni predelavo predloge računa (poročila v Accessu, postavitve v FileMakerju, generatorja PDF) in dodajanje knjižnice za QR v sklad, ki je ni nikoli imel.

Dva načina: VERI*FACTU ali ne

Način VERI*FACTU. Sistem vsak zapis samodejno pošlje AEAT, ko nastane. V zameno zapisi potrebujejo zgoščeno vrednost, elektronskega podpisa pa ne, AEAT jih hrani, sistem, ki deluje samo v tem načinu, pa ne potrebuje dnevnika dogodkov. Potrebujete odjemalca SOAP za objavljene storitve AEAT, kvalificirano elektronsko potrdilo in vrsto za primere, ko povezava odpove. Pogosta vprašanja AEAT za razvijalce izpad obravnavajo kot incident: zapisi čakajo v vrsti in se pošiljajo znova, izdajanje računov pa teče naprej.

Način brez VERI*FACTU. Zapisi ostanejo pri vas in vsak mora biti podpisan (XAdES Enveloped, ETSI EN 319 132) s kvalificiranim potrdilom. Sistem mora voditi tudi podpisan dnevnik dogodkov, ki zajema zagon in zaustavitev v tem načinu, preverjanja nepravilnosti in njihove ugotovitve, obnovitve varnostnih kopij in izvoze, z zbirnim dogodkom vsaj vsakih šest ur delovanja, zapise pa mora predati, ko jih AEAT zahteva.

Za sistem po meri je samo VERI*FACTU običajno manjša gradnja. Brez infrastrukture za podpisovanje, brez dnevnika dogodkov, brez orodij za nepravilnosti. Sistem, ki ponuja oba načina, mora izvesti vse.

Načrt, ki ga je mogoče izpeljati pred 1. januarjem 2027

Od začetka oktobra ima zavezanec za davek od dohodkov pravnih oseb približno trinajst tednov. To je vrstni red, ki deluje.

1. 1. teden: popis. Naštejte vse sisteme, ki izdajajo račune: ERP, modul za obračun spletne trgovine, skripto za naročnine, terminal na blagajni. Potrdite, da niste v SII ali pod foralnimi pravili.
2. 1. in 2. teden: odločite, kdo podpiše in kateri način. Za vsak sistem določite proizvajalca. Izberite samo VERI*FACTU, razen če imate razlog proti. Poskrbite, da kvalificirano potrdilo podjetja obstaja in da je nekdo zanj odgovoren, saj pogosta vprašanja AEAT za razvijalce navajajo, da sistem brez njega ne more delovati.
3. Od 2. do 4. tedna: analiza vrzeli v podatkih. Primerjajte, kaj vaš sistem hrani, s členom 10 in zasnovo zapisa AEAT. Tu se pokažejo manjkajoče razčlenitve DDV, kode vrst računov in sklici na popravke.
4. Od 3. do 8. tedna: gradnja. Ustvarjanje zapisa ob izdaji, veriga in njena preverjanja, nespremenljiva hramba, preklic, QR na vsaki predlogi in odjemalec za oddajo z vrsto za ponovne poskuse. Odstranite neposredno urejanje izdanih zapisov.
5. Od 6. do 10. tedna: testiranje. Začnite v testnem okolju AEAT, nato pošiljajte resnične zapise. AEAT čas pred vašim rokom obravnava kot testno obdobje, v katerem lahko pošiljanje ustavite in se vrnete na drug sistem. Preden napišete postopka za preklic in popravek, preberite pogosta vprašanja za razvijalce: zajemajo večino robnih primerov.
6. Od 9. do 12. tedna: izjava in usposabljanje. Napišite declaración responsable, jo prikažite v aplikaciji in zunaj nje ter zabeležite različico. Finančnemu oddelku povejte, da se številke nikoli ne uporabijo znova in da se napake popravljajo s popravljalnimi računi.
7. Sredi decembra: začetek. Rok, ki se glasi „antes del 1 de enero“, torej pred 1. januarjem, ni datum začetka. Začnite dva tedna prej, da se prve težave pokažejo, ko je še čas.

Za datum 1. julij 2027 velja isti načrt z več prostora. Začnite januarja, ne maja.

Vredno je pošteno pretehtati dve alternativi ponovni gradnji. AEAT sprejema mešane arhitekture, zato lahko vaš ERP še naprej pripravlja podatke o računih, ločena komponenta, kupljena ali zgrajena, pa ustvarja zapise, QR in oddajo, pod pogojem, da izjave pokrivajo, kako se deli povezujejo. In če stari program izda le peščico računov na mesec, je brezplačna aplikacija AEAT za izdajanje računov za mala podjetja ali standardni paket morda cenejša od prilagoditve.

Kje dobiti pomoč

Spreminjamo kodo za izdajanje računov, ki jo podjetja že uporabljajo, tudi na starejših skladih: ustvarjanje zapisov, verigo zgoščenih vrednosti, QR na vaših predlogah in odjemalca za oddajo AEAT, s testi, ki ostanejo za nami. Naša storitev integracije e-računov pokriva gradnjo, vzdrževanje podedovanih sistemov pa je izhodišče, kadar nihče od zaposlenih ne ve več, kako stari program deluje.

Če imate rok 1. januar 2027 in sistem po meri, pišite na office@c9group.dev. Smo inženirji, ne davčni svetovalci: vprašanja o obsegu in odgovornosti sodijo k vašim, mi pa gradimo po odgovoru, ki ga dajo.