VERI*FACTU a własne oprogramowanie do fakturowania: czego Hiszpania wymaga od 1 stycznia 2027

Przed 1 stycznia 2027 każda firma w Hiszpanii, która rozlicza podatek dochodowy od osób prawnych (Impuesto sobre Sociedades) i wystawia faktury z oprogramowania, musi korzystać z oprogramowania dostosowanego do Real Decreto 1007/2023. Każda faktura dostaje zapis z hashem powiązany z poprzednim oraz kod QR, który klient może sprawdzić w hiszpańskiej administracji podatkowej. Pozostali objęci obowiązkiem, głównie osoby samozatrudnione, mają czas do 1 lipca 2027.

Jeśli faktury wychodzą z oprogramowania komercyjnego, to w dużej mierze zadanie producenta. Jeśli wychodzą z oprogramowania, które ktoś napisał dla Ciebie albo które napisał Twój własny zespół, zadanie należy do Ciebie. Zmieniasz kod i podpisujesz oświadczenie, że jest zgodny.

Terminy i dwa przesunięcia

To już trzeci zestaw dat, więc pewien sceptycyzm jest uzasadniony.

• Real Decreto 1007/2023 pierwotnie dawał firmom czas do 1 lipca 2025.
• Real Decreto 254/2025 z 1 kwietnia 2025 przesunął ten termin na 1 stycznia 2026 dla podatników podatku od osób prawnych i na 1 lipca 2026 dla pozostałych. Powód był konkretny: rozporządzenie techniczne, Orden HAC/1177/2024, opublikowano dopiero 28 października 2024.
• Real Decreto-ley 15/2025 z 2 grudnia 2025 przesunął obie daty o rok. Jego tekst jest w BOE, a Kongres zatwierdził go (convalidación) w tym samym miesiącu.

Komunikat AEAT o przedłużeniu terminu, zaktualizowany 26 marca 2026, nie pozostawia wątpliwości: „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.”

Czy termin może się znowu przesunąć? W październiku 2026 nic oficjalnego na to nie wskazuje. Pierwsze opóźnienie miało przyczynę techniczną, która już nie istnieje. Usługi AEAT do przesyłania zapisów działają produkcyjnie od 23 kwietnia 2025, a od 29 lipca 2025 producenci oprogramowania mogą oferować wyłącznie systemy dostosowane. Liczenie na trzecie przesunięcie to zakład, a nie plan.

Który termin dotyczy Ciebie? SL lub SA rozlicza Impuesto sobre Sociedades, więc spółka z własnym ERP niemal na pewno ma termin 1 stycznia 2027. To mniej niż trzy miesiące. Termin lipcowy dotyczy osób samozatrudnionych i pozostałych objętych podatników.

Kto jest objęty, a kto nie

FAQ AEAT o zakresie sprowadza go do czterech zaprzeczeń. Podlegasz, jeśli nie fakturujesz wyłącznie ręcznie, nie jesteś w SII (obowiązkowo ani z wyboru), nie masz siedziby podatkowej w Kraju Basków ani w Nawarze i nie masz decyzji o zwolnieniu.

Wyłączenia w praktyce:

• Podatnicy SII. Suministro Inmediato de Información jest obowiązkowe dla firm z obrotem powyżej 6 mln euro, grup VAT i firm z rejestru miesięcznych zwrotów VAT (REDEME), a inni mogą przystąpić dobrowolnie. AEAT pisze wprost: „El ámbito subjetivo de ambos proyectos es excluyente.” Jeśli przechodzisz do SII, przestajesz wysyłać zapisy VERI*FACTU i drukować kod QR.
• Kraj Basków i Nawarra. Firmy z siedzibą podatkową w tych regionach podlegają foralnym organom podatkowym i ich własnym przepisom, a nie RD 1007/2023.
• Fakturowanie wyłącznie ręczne. Papierowy rejestr faktur jest poza zakresem. Podobnie arkusz kalkulacyjny używany wyłącznie do wpisania, wydruku i przechowywania faktur; arkusz, który przy okazji prowadzi rejestry VAT, już nie.

Firmy zagraniczne podlegają obowiązkowi, jeśli mają w Hiszpanii stały zakład.

Jeśli fakturujesz z pakietu komercyjnego (A3, Sage, Holded i podobne), producentem jest dostawca oprogramowania i to on musi dostarczyć wersję dostosowaną z własnym oświadczeniem. Zaktualizuj ją, sprawdź, czy oświadczenie jest dostępne, i możesz dalej nie czytać.

Ten artykuł jest dla pozostałych: dla własnego ERP, dla programu w Access, Delphi albo FileMaker napisanego piętnaście lat temu, dla modułu rozliczeniowego we własnej platformie internetowej.

Producentem jest Twoja firma

Artykuł 13.1 rozporządzenia nakłada certyfikację na tego, kto wytwarza system, w drodze declaración responsable, czyli oświadczenia producenta. FAQ AEAT o certyfikacji odpowiada wprost na przypadek oprogramowania własnego: „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.”

Co to oznacza w praktyce:

• Nie ma audytu zewnętrznego. AEAT nazywa to „auto-certificación” producenta. Nikt nie zatwierdza systemu z góry. Podpisujesz i za to odpowiadasz.
• Wykonawca, który buduje dla Ciebie rozszerzenie jako produkt, certyfikuje to rozszerzenie. Jeśli zbudowałeś je sam, certyfikujesz je Ty.
• Oświadczenie musi być widoczne w systemie, w każdej wersji, a także dostępne poza nim, niezależnie od produktu.
• Jego treść jest określona w art. 15 Orden HAC/1177/2024: między innymi nazwa, identyfikator i wersja systemu, jego komponenty, informacja, czy działa wyłącznie w trybie VERI*FACTU, nazwa, NIF i adres producenta oraz data i miejsce podpisania.

Niewygodny przypadek to program, którego autor odszedł lata temu. Ktoś i tak musi przygotować wersję dostosowaną i ją podpisać. Ustal na piśmie, kto to będzie, zanim praca się zacznie.

Dostosowanie certyfikowanego produktu komercyjnego wymaga osobnego oświadczenia tylko wtedy, gdy zmiana dotyka sposobu realizacji wymagań rozporządzenia. Modyfikacja wprowadzona poza kontrolą producenta, która może je zmienić, nie jest zgodna z przepisami.

Stawkę wyznacza art. 201 bis Ley General Tributaria: stała kara 150 000 euro za rok obrotowy i za każdy typ systemu za wytwarzanie systemów niespełniających wymagań oraz 50 000 euro za rok obrotowy za posiadanie systemu, który powinien być certyfikowany, a nie jest, albo który został zmieniony. Która z tych kar groziłaby za system zbudowany samodzielnie, to pytanie do doradcy podatkowego. Żadna z tych kwot nie jest mała.

Co musi robić oprogramowanie

Zapis dla każdej faktury, w chwili wystawienia

Artykuł 9.1 wymaga, by system generował registro de facturación de alta „de forma simultánea o inmediatamente anterior a la expedición de cada factura”. Anulowana faktura dostaje zapis anulowania (registro de anulación).

Artykuł 10 wymienia, co zawiera zapis: NIF i nazwę wystawcy, odbiorcę tam, gdzie jest wymagany, serię i numer, datę wystawienia i datę transakcji, typ faktury, dane korygowanej faktury, jeśli dotyczy, opis, kwotę całkowitą, reżim VAT, podstawę opodatkowania, stawki i kwoty, przyczyny zwolnienia lub niepodlegania, identyfikację systemu i jego producenta oraz znacznik czasu z dokładnością do sekundy.

W starszych systemach tu właśnie kryje się praca:

• Zestawienia VAT często są liczone w chwili wydruku i nigdzie nie zapisywane. Muszą istnieć jako dane w chwili wystawienia.
• „Wystawienie” to często tylko wydruk raportu. Musi istnieć wyraźny moment, w którym szkic staje się fakturą, i wtedy powstaje zapis.
• Koniec z ponownym użyciem numerów. Usunięcie faktury i ponowne użycie jej numeru, nawyk w wielu małych systemach, teraz się nie uda: AEAT odrzuca drugi zapis jako „Registro de facturación duplicado.” Faktury testowe wystawione na produkcji są prawdziwymi fakturami i trzeba je anulować.
• Nikt nie edytuje zapisów. FAQ AEAT mówi, że bezpośrednie zmiany w bazie wystawionych zapisów nie mogą być dozwoloną operacją. Jeśli dziś pracownicy poprawiają faktury SQL-em, to się kończy. Poprawki idą przez faktury korygujące.

Łańcuch hashy

Każdy zapis zawiera serię, numer i datę poprzedniego zapisu oraz część jego hasha (huella). Algorytm to SHA-256, a dokładne pola i sposób ich łączenia opisuje dokumentacja techniczna AEAT, razem z projektami zapisów, schematami XSD, WSDL oraz katalogiem walidacji i błędów.

Przed wygenerowaniem nowego zapisu system musi sprawdzić, czy ostatni jest poprawnie powiązany i czy jego znacznik czasu nie jest późniejszy od bieżącego czasu o więcej niż minutę. Zapisy generuje się w kolejności wystawiania faktur.

To ma konsekwencję architektoniczną. Każda instalacja potrzebuje jednego, serializowanego miejsca, w którym powstają zapisy. Dwa serwery WWW dopisujące do tego samego łańcucha bez koordynacji go zepsują. AEAT akceptuje układy mieszane, na przykład terminale POS, które otrzymują zapis z centralnego zaplecza, ale sam łańcuch żyje w jednym miejscu.

Każdy system identyfikują NIF podatnika, dwuznakowy identyfikator systemu i numer instalacji, który nigdy nie może się powtórzyć, nawet gdy to samo oprogramowanie zostanie ponownie zainstalowane na tej samej maszynie.

Kod QR na fakturze

Każda faktura ma kod QR zgodny z ISO/IEC 18004, o wymiarach od 30x30 do 40x40 mm, z poziomem korekcji błędów M. Koduje adres URL zawierający NIF wystawcy, serię i numer, datę wystawienia i kwotę całkowitą, który klient może sprawdzić w AEAT. W trybie VERI*FACTU faktura zawiera też napis „VERI*FACTU” albo „Factura verificable en la sede electrónica de la AEAT”.

Dla starszego oprogramowania oznacza to przeróbkę szablonu faktury (raportu w Access, układu w FileMaker, generatora PDF) i dodanie biblioteki QR do stosu, który nigdy takiej nie miał.

Dwa tryby: VERI*FACTU albo nie

Tryb VERI*FACTU. System automatycznie wysyła każdy zapis do AEAT w chwili jego wygenerowania. W zamian zapisy wymagają hasha, ale nie podpisu elektronicznego, AEAT je przechowuje, a system działający wyłącznie w tym trybie nie potrzebuje dziennika zdarzeń. Potrzebny jest klient SOAP do opublikowanych usług AEAT, kwalifikowany certyfikat elektroniczny i kolejka na wypadek utraty połączenia. FAQ AEAT dla programistów traktuje awarię jako incydent: zapisy czekają w kolejce i są ponawiane, a fakturowanie trwa dalej.

Tryb inny niż VERI*FACTU. Zapisy zostają u Ciebie, a każdy musi być podpisany (XAdES Enveloped, ETSI EN 319 132) certyfikatem kwalifikowanym. System musi też prowadzić podpisany dziennik zdarzeń obejmujący uruchomienie i zatrzymanie w tym trybie, kontrole anomalii i ich wyniki, przywracanie kopii zapasowych i eksporty, ze zdarzeniem podsumowującym co najmniej co sześć godzin pracy, i musi przekazać zapisy na żądanie AEAT.

Dla systemu tworzonego na zamówienie tryb wyłącznie VERI*FACTU to zwykle mniejszy zakres budowy. Bez infrastruktury podpisu, bez dziennika zdarzeń, bez narzędzi do wykrywania anomalii. System oferujący oba tryby musi wdrożyć wszystko.

Plan, który mieści się przed 1 stycznia 2027

Od początku października podatnik podatku od osób prawnych ma około trzynastu tygodni. Ta kolejność działa.

1. Tydzień 1: inwentaryzacja. Spisz każdy system wystawiający faktury: ERP, moduł rozliczeniowy sklepu internetowego, skrypt subskrypcyjny, terminal przy ladzie. Potwierdź, że nie jesteś w SII ani pod przepisami foralnymi.
2. Tygodnie 1 i 2: decyzja, kto podpisuje i w jakim trybie. Wskaż producenta każdego systemu. Wybierz tryb wyłącznie VERI*FACTU, chyba że masz powód, by tego nie robić. Upewnij się, że firma ma certyfikat kwalifikowany i że ktoś za niego odpowiada, bo FAQ AEAT dla programistów zaznacza, że bez niego system nie może działać.
3. Tygodnie od 2 do 4: analiza luk w danych. Porównaj to, co przechowuje Twój system, z art. 10 i projektem zapisu AEAT. Tu wychodzą brakujące zestawienia VAT, kody typów faktur i odwołania do faktur korygowanych.
4. Tygodnie od 3 do 8: budowa. Generowanie zapisu przy wystawieniu, łańcuch i jego kontrole, niezmienialne przechowywanie, anulowanie, QR na każdym szablonie oraz klient do przesyłania z kolejką ponowień. Usuń możliwość bezpośredniej edycji wystawionych zapisów.
5. Tygodnie od 6 do 10: testy. Zacznij w środowisku testowym AEAT, potem wysyłaj prawdziwe zapisy. AEAT traktuje czas przed Twoim terminem jako okres testowy, w którym możesz przerwać wysyłanie i wrócić do innego systemu. Przeczytaj FAQ dla programistów, zanim napiszesz przepływy anulowania i korekty: omawia większość przypadków brzegowych.
6. Tygodnie od 9 do 12: oświadczenie i szkolenie. Napisz declaración responsable, pokaż ją w aplikacji i poza nią, zapisz wersję. Powiedz działowi finansów, że numerów nigdy nie używa się ponownie, a błędy poprawia się fakturami korygującymi.
7. Połowa grudnia: start. Termin brzmiący „antes del 1 de enero” nie jest datą startu. Uruchom system dwa tygodnie wcześniej, żeby pierwsze problemy wyszły, gdy jest jeszcze czas.

Przy terminie 1 lipca 2027 obowiązuje ten sam plan, tylko z większym zapasem. Zacznij w styczniu, nie w maju.

Warto uczciwie rozważyć dwie alternatywy dla przebudowy. AEAT akceptuje architektury mieszane, więc ERP może dalej przygotowywać dane faktur, a osobny komponent, kupiony albo zbudowany, generuje zapisy, QR i przesyłkę, o ile oświadczenia opisują, jak te części do siebie pasują. A jeśli stary program wystawia kilka faktur miesięcznie, bezpłatna aplikacja AEAT do fakturowania dla małych firm albo standardowy pakiet może kosztować mniej niż jego dostosowanie.

Gdzie szukać pomocy

Zmieniamy kod fakturowania, z którego firmy już korzystają, także na starszych stosach: generowanie zapisów, łańcuch hashy, QR na szablonach i klienta do przesyłania danych do AEAT, a po sobie zostawiamy testy. Budowę obejmuje nasza usługa integracji e-fakturowania, a utrzymanie systemów odziedziczonych to punkt wyjścia, gdy nikt już nie wie, jak działa stary program.

Jeśli masz termin 1 stycznia 2027 i własny system, napisz na office@c9group.dev. Jesteśmy inżynierami, a nie doradcami podatkowymi: pytania o zakres i odpowiedzialność należą do Twoich doradców, a my budujemy pod odpowiedź, którą dadzą.