VERI*FACTU и сопствен софтвер за фактурирање: што бара Шпанија до 1 јануари 2027

Пред 1 јануари 2027 секоја компанија во Шпанија што поднесува данок на добивка (Impuesto sobre Sociedades) и фактурира од софтвер мора да користи софтвер прилагоден на Real Decreto 1007/2023. Секоја фактура добива запис со хеш, врзан во синџир со претходниот, и QR-код што купувачот може да го провери кај даночната управа. Сите други опфатени, главно самовработените, имаат рок до 1 јули 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, ажурирана на 26 март 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.“

Може ли повторно да се помести? Заклучно со октомври 2026 ништо официјално не укажува на тоа. Првото одложување имаше техничка причина што повеќе не постои. Услугите на AEAT за поднесување се во продукција од 23 април 2025, а од 29 јули 2025 добавувачите на софтвер смеат да нудат само прилагодени системи. Да се планира врз трето одложување е облог, а не план.

Кој датум е ваш? SL или SA поднесува Impuesto sobre Sociedades, па компанија што користи сопствен ERP речиси сигурно е на датумот 1 јануари 2027. Тоа е за помалку од три месеци. Јулскиот датум е за самовработените и за другите опфатени даночни обврзници.

Кој е опфатен, а кој не

Најчестите прашања за опсегот на 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.
• Чисто рачно фактурирање. Хартиена книга со фактури е надвор од опсегот. Исто така и табела во Excel што служи само за пишување, печатење и чување фактури; табела што ги прави и вашите книги за ДДВ не е.

Странските компании се опфатени кога имаат постојана деловна единица во Шпанија.

Ако фактурирате од комерцијален пакет (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 на даночниот обврзник, ID на системот од два знака и број на инсталација што никогаш не смее да се повтори, дури ни кога истиот софтвер повторно се инсталира на истата машина.

QR-кодот на фактурата

Секоја фактура носи QR-код според ISO/IEC 18004, со големина од 30x30 до 40x40 мм и ниво на корекција на грешки 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 јануари 2027

Од почетокот на октомври, обврзникот на данок на добивка има околу тринаесет недели. Ова е редоследот што функционира.

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“ не е датум за почеток на примена. Почнете две недели порано, за првите проблеми да излезат додека уште има време.

За датумот 1 јули 2027 важи истиот план, со повеќе простор. Почнете во јануари, не во мај.

Две алтернативи на повторната изработка вреди искрено да се одмерат. AEAT прифаќа мешани архитектури, па вашиот ERP може да продолжи да ги подготвува податоците за фактурите, додека посебна компонента, купена или изградена, ги генерира записите, QR-кодот и поднесувањето, под услов изјавите да опфаќаат како деловите се вклопуваат. А ако старата програма издава неколку фактури месечно, бесплатната апликација на AEAT за фактурирање за мали компании, или стандарден пакет, може да чини помалку од нејзиното прилагодување.

Каде да побарате помош

Менуваме код за фактурирање што компаниите веќе го користат, вклучително и постари технолошки стекови: генерирање записи, синџирот на хешови, QR-кодот на вашите шаблони и клиентот за поднесување до AEAT, со тестови што остануваат по нас. Нашата услуга за интеграција на е-фактурирање ја покрива изработката, а одржувањето наследени системи е местото каде што почнува кога не останал никој што знае како работи старата програма.

Ако имате рок 1 јануари 2027 и сопствен систем, пишете ни на office@c9group.dev. Ние сме инженери, а не даночни советници: прашањата за опсегот и одговорноста му припаѓаат на вашиот советник, а ние градиме според одговорот што ќе го даде.