VERI*FACTU и собственият софтуер за фактуриране: срокът през 2027 г. и обявеното отлагане за 2028 г.

Преди 1 януари 2027 г. всяко дружество в Испания, което подава декларация за корпоративен данък (Impuesto sobre Sociedades) и издава фактури от софтуер, трябва да работи със софтуер, адаптиран към Real Decreto 1007/2023. За всяка фактура се създава хеширан запис, свързан във верига с предишния, и QR код, по който клиентът може да провери фактурата в данъчната агенция. Всички останали задължени лица, предимно самонаетите, имат срок до 1 юли 2027 г. На 5 октомври 2026 г. испанското Министерство на финансите обяви, че ще отложи тези задължения до октомври 2028 г. Към 16 октомври нормативен акт за това не е обнародван, така че датите през 2027 г. остават задължителни.

Ако фактурите ви излизат от търговски софтуерен пакет, това е до голяма степен работа на доставчика ви. Ако излизат от софтуер, който някой е написал специално за вас или който е разработил собственият ви екип, работата е ваша. Вие променяте кода и вие подписвате декларацията, че той отговаря на изискванията.

Датите и двете отлагания

Това е третият набор от дати, така че известен скептицизъм е оправдан.

• Real Decreto 1007/2023 първоначално даваше на бизнеса срок до 1 юли 2025 г.
• Real Decreto 254/2025 от 1 април 2025 г. премести срока на 1 януари 2026 г. за платците на корпоративен данък и на 1 юли 2026 г. за останалите. Причината беше конкретна: техническата наредба Orden HAC/1177/2024 беше публикувана едва на 28 октомври 2024 г.
• Real Decreto-ley 15/2025 от 2 декември 2025 г. премести двете дати с година. Текстът му е в BOE, а Конгресът го потвърди още същия месец.

Съобщението на AEAT за удължаването, последно актуализирано на 13 октомври 2026 г., не оставя място за тълкуване: „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."

Може ли срокът да се премести отново? Министерството на финансите казва, че ще го премести. Неговата nota informativa от 5 октомври 2026 г. обявява, че все още неизпълнените задължения по RD 1007/2023 ще бъдат отложени „hasta octubre de 2028", за да съвпаднат със задължителното електронно фактуриране за предприятия с годишен оборот до 8 милиона евро. Това е съобщение, а не промяна в закона. Бележката посочва месец, но не и ден, не казва с какъв акт ще бъде направена промяната и не разграничава дружествата от самонаетите. Към 16 октомври 2026 г. в BOE не е публикувано нищо, а страниците на AEAT продължават да посочват датите през 2027 г. Нормативен акт в последния момент не би бил нещо необичайно: Real Decreto-ley 15/2025 беше публикуван на 3 декември 2025 г., четири седмици преди датата, която отлагаше. Бележката посочва още, че изискванията за цялост, проследимост и неизменност ще останат „en términos sustancialmente equivalentes", а обхватът и някои технически въпроси ще бъдат преразгледани по-късно, за да се сближат с електронното фактуриране и ViDA.

Коя дата се отнася за вас? Дружествата SL и SA подават Impuesto sobre Sociedades, така че дружество със собствена ERP система почти сигурно е със срок 1 януари 2027 г. Докато акт в BOE не каже друго, тази дата е задължителна, а до нея остават по-малко от дванадесет седмици. Юлската дата е за самонаетите и за останалите задължени данъкоплатци.

Октомври 2028 г. в бележката идва от друг нормативен акт, чийто срок вече тече. Orden HAC/1028/2026, обнародвана в BOE на 5 октомври 2026 г. и в сила от 6 октомври, урежда публичното решение на AEAT за електронно фактуриране и задейства сроковете по Real Decreto 238/2026, задължението за електронно фактуриране между предприятия (B2B): дванадесет месеца за предприятията с оборот над 8 милиона евро през предходната година и двадесет и четири месеца за останалите. Следователно структурираните електронни фактури между предприятия стават задължителни през октомври 2027 г. и октомври 2028 г. Собствена система, която издава фактури на други предприятия, има този проект пред себе си, каквото и да стане с VERI*FACTU. Това задължение разглеждаме в нашето ръководство за B2B електронното фактуриране в Испания.

Кой е задължен и кой не е

Въпросите и отговорите на AEAT относно обхвата го свеждат до четири отрицания. Задължени сте, ако не издавате фактури изцяло на ръка, не сте в SII (задължително или по избор), данъчният ви адрес не е в Страната на баските или Навара и нямате решение за освобождаване.

Изключенията на практика:

• Подаващите в SII. Suministro Inmediato de Información е задължителна за дружества с оборот над 6 милиона евро, групи по ДДС и предприятия в регистъра за месечно възстановяване на ДДС (REDEME), а останалите могат да се включат доброволно. AEAT го казва направо: „El ámbito subjetivo de ambos proyectos es excluyente." Ако преминете към SII, спирате да изпращате записи по VERI*FACTU и спирате да печатате QR кода.
• Страната на баските и Навара. Предприятията с данъчен адрес там се подчиняват на форалните данъчни органи и на собствените им правила, а не на RD 1007/2023.
• Изцяло ръчното фактуриране. Хартиен кочан с фактури не попада в обхвата. Не попада и електронна таблица, която служи само за въвеждане, печат и съхранение на фактури; таблица, от която се получават и дневниците ви по ДДС, попада.

Чуждестранните дружества са задължени, когато имат място на стопанска дейност в Испания.

Ако издавате фактури от търговски пакет (A3, Sage, Holded и подобни), производител е доставчикът и той трябва да пусне адаптирана версия със собствена декларация. Обновете я, проверете дали декларацията е налице и можете да спрете да четете дотук.

Тази статия е за останалите: собствена ERP система, програма на Access, Delphi или FileMaker, писана преди петнадесет години, или модул за фактуриране в собствената ви уеб платформа.

Производителят е вашето дружество

Член 13.1 от наредбата възлага сертифицирането на производителя на системата чрез declaración responsable (декларация под собствена отговорност). Въпросите и отговорите на AEAT за сертифицирането отговарят пряко за случая със собствена разработка: „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."

Какво означава това на практика:

• Няма външен одит. AEAT го нарича „auto-certificación" на производителя. Никой не одобрява системата ви предварително. Вие подписвате и вие отговаряте.
• Изпълнител, който разработва разширение за вас като продукт, сертифицира това разширение. Ако сте го разработили сами, сертифицирате го вие.
• Декларацията трябва да е видима в самата система, във всяка версия, и да е достъпна и извън нея, независимо от продукта.
• Съдържанието ѝ е определено в член 15 от Orden HAC/1177/2024: наред с другото наименованието, идентификаторът и версията на системата, нейните компоненти, дали работи само в режим VERI*FACTU, наименованието, NIF и адресът на производителя, както и датата и мястото на подписване.

Трудният случай е програмата, чийто автор е напуснал преди години. Някой все пак трябва да изготви адаптираната версия и да се подпише под нея. Решете кой ще е той, писмено, преди да започне работата.

Персонализирането на сертифициран търговски продукт изисква отделна декларация само ако промяната засяга начина, по който са изпълнени изискванията на наредбата. Промяна, направена извън контрола на производителя, която може да ги наруши, не отговаря на изискванията.

Залогът се определя от член 201 bis от Общия данъчен закон: фиксирана глоба от 150 000 € за всяка финансова година и за всеки вид система за производството на системи, които не отговарят на изискванията, и 50 000 € за всяка финансова година за притежаването на система, която е трябвало да бъде сертифицирана и не е, или която е била променена. Коя от двете би се приложила за собствено разработена система, е въпрос към данъчния ви консултант. Нито една от сумите не е малка.

Какво трябва да прави софтуерът

Запис за всяка фактура в момента на издаването ѝ

Член 9.1 изисква системата да създава registro de facturación de alta „de forma simultánea o inmediatamente anterior a la expedición de cada factura". За анулирана фактура се създава запис за анулиране (registro de anulación).

Член 10 изброява какво съдържа записът: NIF и наименование на издателя, получателя, когато се изисква, серия и номер, дата на издаване и дата на операцията, вид на фактурата, данни за фактурата, която се коригира, ако има такава, описание, обща сума, режим по ДДС, данъчна основа, ставки и суми, основания за освобождаване или необлагане, идентификация на системата и на производителя ѝ, както и времеви печат с точност до секундата.

В по-старите системи именно тук се крие работата:

• Разбивката по ДДС често се изчислява при печат и никъде не се съхранява. Тя трябва да съществува като данни в момента на издаването.
• „Издаването" често е просто печат на справка. Трябва да има изрична точка, в която черновата става фактура, и записът се създава точно тогава.
• Повторното използване на номера приключва. Изтриването на фактура и повторното използване на номера ѝ, навик в много малки системи, вече не минава: AEAT отхвърля втория запис като „Registro de facturación duplicado." Тестови фактури, издадени в продукционна среда, са истински фактури и трябва да бъдат анулирани.
• Никой не редактира записи. Според въпросите и отговорите на AEAT преките промени в базата данни с издадени записи не трябва да са допустима операция. Ако днес служителите поправят фактури с SQL, това спира. Корекциите минават през коригиращи фактури.

Хеш веригата

Всеки запис съдържа серията, номера и датата на предходния запис и част от неговия хеш (huella). Алгоритъмът е SHA-256, а точните полета и редът на конкатенация са в техническата документация на AEAT, заедно със структурите на записите, XSD схемите, WSDL и каталога с валидации и грешки.

Преди да създаде нов запис, системата трябва да провери, че последният е правилно свързан във веригата и че времевият му печат не е с повече от една минута след текущото време. Записите се създават в реда, в който се издават фактурите.

Това има последствия за архитектурата. Всяка инсталация се нуждае от една-единствена, сериализирана точка, в която се създават записите. Два уеб сървъра, които добавят към една и съща верига без координация, ще я счупят. AEAT допуска смесени конфигурации, например POS терминали, които получават записа от централен бек офис, но самата верига живее на едно място.

Всяка система се идентифицира с NIF на данъкоплатеца, двузнаков идентификатор на системата и номер на инсталацията, който никога не може да се повтаря, дори когато същият софтуер се инсталира отново на същата машина.

QR кодът върху фактурата

Всяка фактура носи QR код по ISO/IEC 18004 с размер между 30x30 и 40x40 mm и ниво на корекция на грешки M. Той кодира URL адрес с NIF на издателя, серията и номера, датата на издаване и общата сума, по който клиентът може да провери фактурата в AEAT. В режим VERI*FACTU върху фактурата се изписва и „VERI*FACTU" или „Factura verificable en la sede electrónica de la AEAT".

За наследения софтуер това означава преработка на шаблона на фактурата (справка в Access, оформление във FileMaker, генератор на PDF) и добавяне на библиотека за QR кодове към технологичен стек, който никога не е имал такава.

Два режима: VERI*FACTU или не

Режим VERI*FACTU. Системата изпраща всеки запис до AEAT автоматично, в момента на създаването му. В замяна записите се нуждаят от хеш, но не и от електронен подпис, AEAT ги съхранява, а система, която работи само в този режим, не се нуждае от дневник на събитията. Нужни са ви SOAP клиент към публикуваните услуги на AEAT, квалифициран електронен сертификат и опашка за случаите, когато връзката прекъсне. Въпросите и отговорите на AEAT за разработчици третират прекъсването като инцидент: записите чакат в опашката и се изпращат повторно, а фактурирането продължава.

Режим извън VERI*FACTU. Записите остават при вас и всеки трябва да е подписан (XAdES Enveloped, ETSI EN 319 132) с квалифициран сертификат. Системата трябва да води и подписан дневник на събитията, който обхваща стартирането и спирането в този режим, проверките за аномалии и резултатите от тях, възстановяванията от резервни копия и експортите, с обобщаващо събитие поне на всеки шест часа работа, и трябва да предоставя записите при поискване от AEAT.

За система, разработена по поръчка, режимът само VERI*FACTU обикновено означава по-малко разработка. Без инфраструктура за подписване, без дневник на събитията, без инструменти за аномалии. Система, която предлага и двата режима, трябва да реализира всичко това.

План, докато датата е под въпрос

Планирайте спрямо законовата дата, а не спрямо обявената. От средата на октомври платецът на корпоративен данък разполага с около единадесет седмици, което е малко за следващото. Стъпки от 1 до 6 са една и съща работа, която и дата да се окаже приложима, тъй като министерството казва, че основните изисквания ще останат по същество равностойни. Отлагането би променило стъпка 7.

1. Седмица 1: инвентаризация. Опишете всяка система, която издава фактури: ERP системата, модула за фактуриране на онлайн магазина, скрипта за абонаменти, терминала на гишето. Потвърдете, че не сте в SII и не сте под форалните правила.
2. Седмици 1 до 2: решете кой подписва и кой режим. Определете производителя за всяка система. Изберете само VERI*FACTU, освен ако нямате причина за друго. Уверете се, че квалифицираният сертификат на дружеството съществува и че някой отговаря за него, защото въпросите и отговорите на AEAT за разработчици отбелязват, че системата не може да работи без такъв.
3. Седмици 2 до 4: анализ на липсващите данни. Сравнете какво съхранява системата ви с член 10 и със структурата на записа на AEAT. Тук излизат наяве липсващите разбивки по ДДС, кодовете на вида фактура и препратките за корекции.
4. Седмици 3 до 8: разработка. Създаване на записа при издаване, веригата и проверките ѝ, неизменно съхранение, анулиране, QR кодът във всеки шаблон и клиентът за изпращане с опашката за повторни опити. Премахнете преките редакции на издадени записи.
5. Седмици 6 до 10: тестване. Започнете в тестовата среда на AEAT, след това изпращайте реални записи. AEAT третира времето преди вашия срок като тестов период, през който можете да спрете изпращането и да се върнете към друга система. Прочетете въпросите и отговорите за разработчици, преди да пишете процесите за анулиране и корекция: там са покрити повечето гранични случаи.
6. Седмици 9 до 12: декларация и обучение. Изгответе declaración responsable, покажете я в приложението и извън него и запишете версията. Обяснете на финансовия отдел, че номерата никога не се използват повторно и грешките се поправят с коригиращи фактури.
7. Средата на декември: пускане в експлоатация. Срок, формулиран като „antes del 1 de enero", не е дата за пускане. Пуснете системата две седмици по-рано, за да излязат първите проблеми, докато още има време. Ако дотогава в BOE е обнародван акт, който премества датата, това е стъпката, която да отложите.

За датата 1 юли 2027 г. важи същият план, но с повече време. Започнете през януари, а не през май.

Две алтернативи на преработката заслужават честна преценка. AEAT допуска смесени архитектури, така че ERP системата ви може да продължи да подготвя данните за фактурите, докато отделен компонент, купен или разработен, създава записите, QR кода и изпращането, при условие че декларациите покриват начина, по който частите работят заедно. А ако старата програма издава няколко фактури на месец, безплатното приложение на AEAT за фактуриране за малки предприятия или стандартен пакет може да струва по-малко от адаптирането ѝ.

Откъде да потърсите помощ

Променяме кода за фактуриране, който дружествата вече използват, включително по-стари технологични стекове: създаването на записите, хеш веригата, QR кода във вашите шаблони и клиента за изпращане към AEAT, като оставяме след себе си и тестове. Нашата услуга за интеграция на електронно фактуриране покрива разработката, а поддръжката на наследени системи е мястото, откъдето започваме, когато вече никой не знае как работи старата програма.

Ако срокът ви е 1 януари 2027 г. и имате собствена система, пишете ни на office@c9group.dev. Ние сме инженери, а не данъчни консултанти: въпросите за обхвата и отговорността са за вашите консултанти, а ние разработваме според отговора, който те дадат.