VERI*FACTU un pielāgota rēķinu programmatūra: 2027. gada termiņš un izziņotā pārcelšana uz 2028. gadu

Līdz 2027. gada 1. janvārim katram uzņēmumam Spānijā, kas iesniedz uzņēmumu ienākuma nodokļa (Impuesto sobre Sociedades) deklarāciju un izraksta rēķinus ar programmatūru, jāizmanto programmatūra, kas pielāgota Real Decreto 1007/2023. Katram rēķinam tiek izveidots ieraksts ar jaucējvērtību, kas piesaistīts iepriekšējam ierakstam, un QR kods, ko klients var pārbaudīt nodokļu administrācijā. Visiem pārējiem, uz kuriem tas attiecas (galvenokārt pašnodarbinātajiem), termiņš ir 2027. gada 1. jūlijs. 2026. gada 5. oktobrī Finanšu ministrija paziņoja, ka šos pienākumus pārcels uz 2028. gada oktobri. Uz 16. oktobri neviens tiesību akts, kas to paredzētu, nav publicēts, tāpēc 2027. gada termiņi joprojām ir saistoši.

Ja jūsu rēķini nāk no komerciālas programmatūras pakotnes, tas lielākoties ir jūsu piegādātāja darbs. Ja tie nāk no programmatūras, ko kāds uzrakstījis jums vai ko uzrakstījusi jūsu pašu komanda, tas ir jūsu darbs. Jūs maināt kodu, un jūs parakstāt deklarāciju, ka tas atbilst prasībām.

Termiņi un divas pārcelšanas

Šis ir jau trešais termiņu komplekts, tāpēc zināma skepse ir pamatota.

• Real Decreto 1007/2023 sākotnēji uzņēmumiem deva laiku līdz 2025. gada 1. jūlijam.
• Real Decreto 254/2025 (2025. gada 1. aprīlis) to pārcēla uz 2026. gada 1. janvāri uzņēmumu ienākuma nodokļa maksātājiem un uz 2026. gada 1. jūliju pārējiem. Iemesls bija konkrēts: tehniskais rīkojums Orden HAC/1177/2024 tika publicēts tikai 2024. gada 28. oktobrī.
• Real Decreto-ley 15/2025 (2025. gada 2. decembris) abus termiņus pārcēla par gadu. Tā teksts ir BOE, un Kongress to apstiprināja tajā pašā mēnesī.

AEAT paziņojums par termiņa pagarinājumu, pēdējo reizi atjaunināts 2026. gada 13. oktobrī, ir nepārprotams: „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.“

Vai termiņš var mainīties vēlreiz? Finanšu ministrija saka, ka mainīsies. Tās 2026. gada 5. oktobra nota informativa paziņo, ka vēl neizpildītie RD 1007/2023 pienākumi tiks atlikti „hasta octubre de 2028“, lai tie sakristu ar obligātajiem e-rēķiniem uzņēmumiem, kuru gada apgrozījums nepārsniedz 8 miljonus eiro. Tas ir paziņojums, nevis likuma grozījums. Paziņojumā minēts mēnesis, bet ne diena, nav teikts, ar kādu tiesību aktu izmaiņas tiks ieviestas, un nav nošķirti uzņēmumi un pašnodarbinātie. Uz 2026. gada 16. oktobri BOE nekas nav parādījies, un AEAT lapās joprojām norādīti 2027. gada termiņi. Novēlots tiesību akts nebūtu nekas neparasts: Real Decreto-ley 15/2025 tika publicēts 2025. gada 3. decembrī, četras nedēļas pirms termiņa, ko tas pārcēla. Paziņojumā arī teikts, ka prasības attiecībā uz integritāti, izsekojamību un nemainīgumu paliks „en términos sustancialmente equivalentes“ un ka piemērošanas joma un daži tehniski jautājumi vēlāk tiks pārskatīti, lai tos saskaņotu ar e-rēķiniem un ViDA.

Kurš termiņš ir jūsu? SL vai SA iesniedz Impuesto sobre Sociedades deklarāciju, tāpēc uzņēmums ar savu ERP sistēmu gandrīz noteikti ir pakļauts 2027. gada 1. janvāra termiņam. Kamēr BOE publicēts tiesību akts nenosaka citādi, šis termiņš ir saistošs, un līdz tam atlikušas mazāk nekā divpadsmit nedēļas. Jūlija termiņš ir pašnodarbinātajiem un pārējiem attiecīgajiem nodokļu maksātājiem.

Paziņojumā minētais 2028. gada oktobris izriet no cita regulējuma, kura atpakaļskaitīšana jau notiek. Orden HAC/1028/2026, kas publicēts BOE 2026. gada 5. oktobrī un ir spēkā kopš 6. oktobra, regulē AEAT publisko e-rēķinu risinājumu un sāk skaitīt Real Decreto 238/2026, B2B e-rēķinu pienākuma, termiņus: divpadsmit mēneši uzņēmumiem, kuru apgrozījums iepriekšējā gadā pārsniedza 8 miljonus eiro, divdesmit četri mēneši pārējiem. Tātad strukturēti e-rēķini starp uzņēmumiem kļūst obligāti 2027. gada oktobrī un 2028. gada oktobrī. Pielāgotai sistēmai, kas izraksta rēķinus citiem uzņēmumiem, šis projekts priekšā jebkurā gadījumā, lai kas notiktu ar VERI*FACTU. Šo pienākumu aplūkojam mūsu ceļvedī par B2B e-rēķiniem Spānijā.

Uz ko tas attiecas un uz ko ne

AEAT biežāk uzdotie jautājumi par piemērošanas jomu to sašaurina līdz četriem noliegumiem. Jūs esat aptverts, ja rēķinus neizrakstāt tikai ar roku, neesat SII sistēmā (obligāti vai pēc izvēles), jūsu nodokļu rezidences vieta nav Basku Zemē vai Navarrā un jums nav atbrīvojuma lēmuma.

Izņēmumi praksē:

• SII iesniedzēji. Suministro Inmediato de Información ir obligāta uzņēmumiem ar apgrozījumu virs 6 miljoniem eiro, PVN grupām un uzņēmumiem, kas iekļauti ikmēneša PVN atmaksas reģistrā (REDEME), un citi tai var pievienoties brīvprātīgi. AEAT to saka tieši: „El ámbito subjetivo de ambos proyectos es excluyente.“ Ja pārejat uz SII, jūs vairs nesūtāt VERI*FACTU ierakstus un vairs nedrukājat QR kodu.
• Basku Zeme un Navarra. Uzņēmumi, kuru nodokļu rezidences vieta ir tur, ir pakļauti forālajām nodokļu iestādēm un to pašu noteikumiem, nevis RD 1007/2023.
• Tikai manuāla rēķinu izrakstīšana. Papīra rēķinu grāmatiņa nav aptverta. Tāpat izklājlapa, ko izmanto tikai rēķinu ierakstīšanai, drukāšanai un glabāšanai; izklājlapa, kas veido arī jūsu PVN grāmatas, ir aptverta.

Ārvalstu uzņēmumi ir aptverti, ja tiem Spānijā ir pastāvīgā pārstāvniecība.

Ja rēķinus izrakstāt ar komerciālu pakotni (A3, Sage, Holded un līdzīgām), piegādātājs ir ražotājs, un tam jāpiegādā pielāgota versija ar savu deklarāciju. Atjauniniet to, pārbaudiet, vai deklarācija ir, un tālāk varat nelasīt.

Šis raksts ir pārējiem: pielāgotai ERP sistēmai, Access, Delphi vai FileMaker programmai, kas uzrakstīta pirms piecpadsmit gadiem, vai rēķinu modulim jūsu pašu tīmekļa platformā.

Ražotājs ir jūsu uzņēmums

Noteikumu 13.1 pants sertifikāciju uzliek tam, kas sistēmu ražo, ar declaración responsable starpniecību. AEAT biežāk uzdotie jautājumi par sertifikāciju uz pašu izstrādātas sistēmas gadījumu atbild tieši: „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.“

Ko tas nozīmē praksē:

• Ārēja audita nav. AEAT to sauc par ražotāja „auto-certificación“. Neviens jūsu sistēmu iepriekš neapstiprina. Jūs parakstāt, un jūs par to atbildat.
• Darbuzņēmējs, kas jums izstrādā paplašinājumu kā produktu, sertificē šo paplašinājumu. Ja to izstrādājāt paši, sertificējat jūs.
• Deklarācijai jābūt redzamai sistēmā katrā versijā un pieejamai arī ārpus tās, neatkarīgi no produkta.
• Tās saturs ir noteikts Orden HAC/1177/2024 15. pantā: cita starpā sistēmas nosaukums, identifikators un versija, tās komponenti, vai tā darbojas tikai VERI*FACTU režīmā, ražotāja nosaukums, NIF un adrese, kā arī parakstīšanas datums un vieta.

Neērtais gadījums ir programma, kuras autors aizgāja pirms gadiem. Kādam tik un tā jāizveido pielāgotā versija un par to jāparakstās. Izlemiet, kas tas būs, rakstiski, pirms darbs sākas.

Sertificēta komerciāla produkta pielāgošanai atsevišķa deklarācija vajadzīga tikai tad, ja izmaiņas skar to, kā tiek īstenotas noteikumu prasības. Modifikācija, kas veikta ārpus ražotāja kontroles un var tās ietekmēt, prasībām neatbilst.

Likmes nosaka Vispārīgā nodokļu likuma 201 bis pants: fiksēts sods 150 000 eiro par katru finanšu gadu un katru sistēmas veidu par prasībām neatbilstošu sistēmu ražošanu un 50 000 eiro par katru finanšu gadu par tādas sistēmas turēšanu, kurai jābūt sertificētai, bet nav, vai kura ir mainīta. Kurš no tiem varētu tikt piemērots pašu izstrādātai sistēmai, ir jautājums jūsu nodokļu konsultantam. Neviena no summām nav maza.

Kas jādara programmatūrai

Ieraksts par katru rēķinu izrakstīšanas brīdī

9.1 pants prasa, lai sistēma ģenerētu registro de facturación de alta „de forma simultánea o inmediatamente anterior a la expedición de cada factura“. Anulētam rēķinam tiek izveidots anulēšanas ieraksts (registro de anulación).

10. pantā uzskaitīts, ko ieraksts satur: izrakstītāja NIF un nosaukumu, saņēmēju, ja tas jānorāda, sēriju un numuru, izrakstīšanas un darījuma datumus, rēķina veidu, informāciju par jebkuru rēķinu, ko tas koriģē, aprakstu, kopsummu, PVN režīmu, apliekamo vērtību, likmes un summas, atbrīvojuma vai neaplikšanas iemeslus, sistēmas un tās ražotāja identitāti un laika zīmogu ar precizitāti līdz sekundei.

Vecākās sistēmās darbs slēpjas tieši šeit:

• PVN sadalījumu bieži aprēķina drukāšanas brīdī un nekur nesaglabā. Izrakstīšanas brīdī tam jāpastāv kā datiem.
• „Izrakstīšana“ bieži ir tikai atskaites izdrukāšana. Jābūt skaidram brīdim, kad melnraksts kļūst par rēķinu, un tieši tad tiek izveidots ieraksts.
• Numuru atkārtota izmantošana ir beigusies. Rēķina dzēšana un tā numura atkārtota izmantošana, kas ir ierasta prakse daudzās mazās sistēmās, vairs neiziet: AEAT otro ierakstu noraida kā „Registro de facturación duplicado.“ Testa rēķini, kas izrakstīti ražošanas vidē, ir īsti rēķini, un tie jāanulē.
• Neviens ierakstus nelabo. AEAT biežāk uzdotajos jautājumos teikts, ka tiešas izmaiņas izrakstīto ierakstu datubāzē nedrīkst būt atļauta darbība. Ja darbinieki šodien labo rēķinus ar SQL, tam jābeidzas. Labojumi notiek ar koriģējošiem rēķiniem.

Jaucējvērtību ķēde

Katrā ierakstā ir iepriekšējā ieraksta sērija, numurs un datums un daļa no tā jaucējvērtības (huella). Algoritms ir SHA-256, un precīzi lauki un to savienošanas kārtība ir AEAT tehniskajā dokumentācijā kopā ar ierakstu struktūrām, XSD shēmām, WSDL un validācijas un kļūdu katalogu.

Pirms jauna ieraksta ģenerēšanas sistēmai jāpārbauda, vai pēdējais ieraksts ir pareizi piesaistīts ķēdei un vai tā laika zīmogs nav vairāk nekā vienu minūti vēlāks par pašreizējo laiku. Ieraksti tiek ģenerēti tādā secībā, kādā tiek izrakstīti rēķini.

Tam ir arhitektūras sekas. Katrai instalācijai vajadzīgs viens secīgs punkts, kurā tiek veidoti ieraksti. Divi tīmekļa serveri, kas bez koordinācijas pievieno ierakstus vienai ķēdei, to sabojās. AEAT pieņem jauktas konfigurācijas, piemēram, kases termināļus, kas saņem ierakstu no centrālās biroja sistēmas, bet pati ķēde atrodas vienā vietā.

Katru sistēmu identificē nodokļu maksātāja NIF, divu rakstzīmju sistēmas ID un instalācijas numurs, kas nedrīkst atkārtoties pat tad, ja tā pati programmatūra tiek pārinstalēta tajā pašā datorā.

QR kods rēķinā

Katrā rēķinā ir QR kods atbilstoši ISO/IEC 18004, no 30x30 līdz 40x40 mm, ar kļūdu labošanas līmeni M. Tajā ir kodēts URL ar izrakstītāja NIF, sēriju un numuru, izrakstīšanas datumu un kopsummu, ko klients var pārbaudīt AEAT. VERI*FACTU režīmā rēķinā norāda arī „VERI*FACTU“ vai „Factura verificable en la sede electrónica de la AEAT“.

Mantotai programmatūrai tas nozīmē rēķina veidnes pārstrādi (Access atskaite, FileMaker izkārtojums, PDF ģenerators) un QR bibliotēkas pievienošanu tehnoloģijām, kurās tādas nekad nav bijis.

Divi režīmi: VERI*FACTU vai ne

VERI*FACTU režīms. Sistēma katru ierakstu automātiski nosūta AEAT, tiklīdz tas izveidots. Pretī ierakstiem vajadzīga jaucējvērtība, bet ne elektroniskais paraksts, AEAT tos glabā, un sistēmai, kas darbojas tikai šajā režīmā, nav vajadzīgs notikumu žurnāls. Jums vajadzīgs SOAP klients AEAT publicētajiem pakalpojumiem, kvalificēts elektroniskais sertifikāts un rinda gadījumiem, kad savienojums pārtrūkst. AEAT izstrādātāju biežāk uzdotajos jautājumos pārtraukums tiek uzskatīts par incidentu: ieraksti gaida rindā, tos sūta atkārtoti, un rēķinu izrakstīšana turpinās.

Režīms bez VERI*FACTU. Ieraksti paliek pie jums, un katrs jāparaksta (XAdES Enveloped, ETSI EN 319 132) ar kvalificētu sertifikātu. Sistēmai jāuztur arī parakstīts notikumu žurnāls, kas aptver darba sākšanu un beigšanu šajā režīmā, anomāliju pārbaudes un to rezultātus, rezerves kopiju atjaunošanu un eksportu, ar kopsavilkuma notikumu vismaz reizi sešās darbības stundās, un tai jānodod ieraksti, kad AEAT tos pieprasa.

Individuāli izstrādātai sistēmai režīms tikai ar VERI*FACTU parasti ir mazāks darbs. Nav parakstīšanas infrastruktūras, nav notikumu žurnāla, nav anomāliju rīku. Sistēmai, kas piedāvā abus režīmus, tas viss jāīsteno.

Plāns, kamēr termiņš ir neskaidrs

Plānojiet pēc likumā noteiktā termiņa, nevis izziņotā. No oktobra vidus uzņēmumu ienākuma nodokļa maksātājam ir aptuveni vienpadsmit nedēļas, kas turpmāk aprakstītajam ir maz. 1. līdz 6. solis ir tas pats darbs neatkarīgi no tā, kurš termiņš beigās būs spēkā, jo ministrija saka, ka galvenās prasības paliks būtībā līdzvērtīgas. Pārcelšana mainītu 7. soli.

1. 1. nedēļa: inventarizācija. Uzskaitiet katru sistēmu, kas izraksta rēķinus: ERP, interneta veikala norēķinu moduli, abonementu skriptu, letes termināli. Pārliecinieties, ka neesat SII sistēmā un neesat pakļauts forālajiem noteikumiem.
2. 1. līdz 2. nedēļa: izlemiet, kurš paraksta un kurš režīms. Nosauciet ražotāju katrai sistēmai. Izvēlieties tikai VERI*FACTU, ja vien nav iemesla rīkoties citādi. Pārliecinieties, ka uzņēmuma kvalificētais sertifikāts eksistē un kāds par to atbild, jo AEAT izstrādātāju biežāk uzdotajos jautājumos norādīts, ka bez tā sistēma nevar darboties.
3. 2. līdz 4. nedēļa: datu nepilnību analīze. Salīdziniet to, ko jūsu sistēma glabā, ar 10. pantu un AEAT ieraksta struktūru. Šeit atklājas trūkstošie PVN sadalījumi, rēķinu veidu kodi un atsauces uz koriģētajiem rēķiniem.
4. 3. līdz 8. nedēļa: izstrāde. Ieraksta ģenerēšana izrakstīšanas brīdī, ķēde un tās pārbaudes, nemaināma glabāšana, anulēšana, QR katrā veidnē un iesniegšanas klients ar atkārtošanas rindu. Novērsiet izrakstīto ierakstu tiešu labošanu.
5. 6. līdz 10. nedēļa: testēšana. Sāciet AEAT testa vidē, pēc tam sūtiet īstus ierakstus. AEAT laiku pirms jūsu termiņa uzskata par testa periodu, kurā drīkstat pārtraukt sūtīšanu un atgriezties pie citas sistēmas. Pirms rakstāt anulēšanas un koriģēšanas plūsmas, izlasiet izstrādātāju biežāk uzdotos jautājumus: tie aptver lielāko daļu robežgadījumu.
6. 9. līdz 12. nedēļa: deklarācija un apmācība. Uzrakstiet declaración responsable, parādiet to lietotnē un ārpus tās un fiksējiet versiju. Pasakiet finanšu nodaļai, ka numurus nekad neizmanto atkārtoti un kļūdas labo ar koriģējošiem rēķiniem.
7. Decembra vidus: palaišana. Termiņš, kas skan „antes del 1 de enero“, nav palaišanas datums. Palaidiet divas nedēļas agrāk, lai pirmās problēmas parādītos, kamēr vēl ir laiks. Ja līdz tam BOE būs publicēts tiesību akts, kas pārceļ termiņu, tieši šo soli var atlikt.

2027. gada 1. jūlija termiņam piemēro to pašu plānu ar lielāku laika rezervi. Sāciet janvārī, nevis maijā.

Ir divas alternatīvas pārbūvei, kuras vērts godīgi izvērtēt. AEAT pieņem jauktas arhitektūras, tāpēc jūsu ERP var turpināt sagatavot rēķinu datus, kamēr atsevišķs komponents, nopirkts vai izstrādāts, ģenerē ierakstus, QR un iesniegšanu, ar nosacījumu, ka deklarācijas aptver to, kā daļas savienojas. Un, ja vecā programma izraksta tikai dažus rēķinus mēnesī, AEAT bezmaksas rēķinu lietotne mazajiem uzņēmumiem vai standarta pakotne var izmaksāt mazāk nekā tās pielāgošana.

Kur saņemt palīdzību

Mēs mainām rēķinu kodu, ko uzņēmumi jau izmanto, arī vecākās tehnoloģijās: ierakstu ģenerēšanu, jaucējvērtību ķēdi, QR jūsu veidnēs un AEAT iesniegšanas klientu, un atstājam aiz sevis testus. Mūsu e-rēķinu integrācijas pakalpojums aptver izstrādi, un mantoto sistēmu uzturēšana ir sākums, ja neviens vairs nezina, kā vecā programma darbojas.

Ja jums ir 2027. gada 1. janvāra termiņš un pielāgota sistēma, rakstiet uz office@c9group.dev. Mēs esam inženieri, nevis nodokļu konsultanti: jautājumi par piemērošanas jomu un atbildību ir jūsējo kompetencē, un mēs izstrādājam atbilstoši viņu atbildei.