Vokietijos E-Rechnung prievolė: struktūrizuotų sąskaitų faktūrų išrašymas iš savų sistemų iki 2027 m. sausio 1 d.

Nuo 2027 m. sausio 1 d. Vokietijos įmonė, kurios 2026 m. apyvarta viršijo 800 000 €, nebegalės siųsti popierinės ar PDF sąskaitos faktūros kitai Vokietijos įmonei. Sąskaita turės būti struktūrizuota e. sąskaita faktūra: duomenų failas, sudarytas pagal Europos standartą EN 16931. Nuo 2028 m. sausio 1 d. riba išnyksta ir taisyklė taikoma visoms įmonėms, išskyrus kelias siauras išimtis.

Mažai įmonei tai ateina kaip programinės įrangos atnaujinimas. Įmonei, kurios sąskaitas faktūras išrašo jos pačios atsiskaitymų sistema, šakos programinis paketas ar per penkiolika metų pritaikyta ERP, tai programinės įrangos projektas, o laiko liko apie trylika savaičių. Šis straipsnis skirtas antrajai grupei.

Ką sako įstatymas

Apibrėžtis pateikta UStG 14 straipsnyje: tai sąskaita faktūra, „die in einem strukturierten elektronischen Format ausgestellt, übermittelt und empfangen wird und eine elektronische Verarbeitung ermöglicht“ (išrašyta, perduota ir gauta struktūrizuotu elektroniniu formatu, leidžiančiu ją apdoroti elektroniniu būdu). Formatas turi atitikti Europos standartą pagal Direktyvą 2014/55/ES (praktiškai EN 16931) arba būti suderėtas tarp šalių, jei reikalingus duomenis galima teisingai ir išsamiai išgauti į su tuo standartu suderinamą formą. PDF netinka, kad ir kaip tvarkingai atrodytų.

Prievolė taikoma tiekimui kitai įmonei, kai abi šalys įsisteigusios Vokietijoje. Pereinamasis laikotarpis nustatytas UStG 27 straipsnio 38 dalyje:

• 2025 ir 2026 m. atliktam tiekimui sąskaitas faktūras vis dar galima išrašyti popieriuje arba, pirkėjui sutikus, kitu elektroniniu formatu, jei sąskaita išsiunčiama iki 2026 m. gruodžio 31 d.
• 2027 m. atliktam tiekimui ta pati išlyga galioja iki 2027 m. gruodžio 31 d., bet tik tuo atveju, jei išrašytojo bendra apyvarta ankstesniais kalendoriniais metais neviršijo 800 000 €.
• EDI, neatitinkantis standarto, pirkėjui sutikus gali būti naudojamas ir 2027 m. atliktam tiekimui, nepriklausomai nuo jūsų dydžio.

Trys detalės svarbesnės, nei atrodo.

Riba matuojama pagal praėjusių metų apyvartą. Jūsų padėtis 2027 m. priklauso nuo 2026 m. skaičiaus, kurio tiksliai niekas nežinos, kol nebus uždarytos knygos. Jei esate bent kiek arti 800 000 €, kurkite taip, lyg būtumėte virš ribos.

Išlyga baigiasi pagal siuntimo datą. Pažodžiui skaitant, pirmoji pereinamoji taisyklė nustoja taikytis popieriui ir PDF 2026 m. gruodžio 31 d., net už 2026 m. atliktus darbus. Jei esate virš ribos ir sąskaitas išrašote po darbų, sąskaita, kurią sausio pirmąją savaitę siunčiate už gruodžio darbus, jau turi būti struktūrizuota. Pasitikslinkite su savo mokesčių konsultantu, bet neplanuokite paleidimo sausio viduryje.

Kai kurioms sąskaitoms faktūroms tai netaikoma: sąskaitoms vartotojams, tarpvalstybinėms sąskaitoms, mažos vertės sąskaitoms iki 250 € su mokesčiais, bilietams, kurie laikomi sąskaitomis faktūromis, smulkiųjų verslininkų (Kleinunternehmer) sąskaitoms ir tiekimui, atleistam pagal UStG 4 straipsnio punktus nuo 8 iki 29.

Mums nežinomas joks įstatymo projektas, kuris šias datas nukeltų. Planuokite taip, lyg jos galios.

Gauti privaloma nuo 2025 m. Išrašymas yra naujoji dalis.

Nuo 2025 m. sausio 1 d. kiekviena Vokietijos įmonė privalo gebėti gauti e. sąskaitas faktūras. Federalinės finansų ministerijos DUK apie e. sąskaitas faktūras tiesiai sako, ko tam reikia: „Für den Empfang einer elektronischen Rechnung genügt bereits ein E-Mail-Postfach.“ Užtenka el. pašto dėžutės.

Atkreipkite dėmesį į vieną paties 14 straipsnio eilutę: kai taikoma e. sąskaitos faktūros prievolė, gavėjo sutikimo nereikia. Vokietijos verslo klientas negali atsisakyti jūsų struktūrizuotos sąskaitos faktūros.

Išrašymas yra kita problema. Gaunant įrankis skaito kažkieno kito failą. Išrašant jūsų sistema yra autorė: jei duomenys klaidingi jau šaltinyje, niekas vėliau grandinėje jų nepataisys, o sąskaita, neperėjusi jūsų kliento patikros, lieka neapmokėta.

Kas tai gaus su atnaujinimu

Paprastai tariant: jei esate maža įmonė ir sąskaitas išrašote DATEV, lexoffice, sevDesk ar panašiu paketu, formatą pateiks jūsų tiekėjas. Patikrinkite pagrindinius duomenis (PVM mokėtojo kodą, klientų adresus, banko rekvizitus), įjunkite funkciją ir išsiųskite bandomąją sąskaitą. Jums nereikia nei projekto, nei programinės įrangos įmonės.

Beveik tas pat taikoma populiariai ERP, kuri tebėra artima standartinei: išvestį pateikia tiekėjas ar jūsų partneris, o darbas yra konfigūravimas ir testavimas.

Likusi straipsnio dalis skirta įmonėms, kurių sąskaitas faktūras generuoja joms priklausantis kodas arba kodas, kurio niekas nebeprižiūri:

• prenumeratos platformų, prekyviečių ir komunalinių paslaugų atsiskaitymų varikliai, programiškai išrašantys didelius sąskaitų kiekius;
• didmeninės prekybos, statybos, logistikos ar lauko paslaugų šakos programinė įranga, kurios tiekėjas mažas, lėtas arba jau išnykęs;
• ERP, kurių sąskaitų išvestis prieš daug metų perrašyta kaip individualios spausdinimo programos, ataskaitų šablonai ar mėnesio pabaigos laiškų suliejimas.

Formatai: EN 16931, XRechnung ir ZUGFeRD

EN 16931 yra Europos standartas. Jis apibrėžia sąskaitos faktūros semantinį modelį (laukus, ką jie reiškia, kurie privalomi ir verslo taisykles tarp jų) ir susieja jį su dviem XML sintaksėmis: UBL 2.1 ir UN/CEFACT CII.

XRechnung yra Vokietijos specifikacija, paremta EN 16931, kurią prižiūri KoSIT: grynas XML bet kuria iš dviejų sintaksių, privalomas viešosioms institucijoms ir lygiai taip pat galiojantis tarp įmonių. Pagal KoSIT XRechnung puslapį, 3.0 versija galioja nuo 2024 m. vasario 1 d. ir galios mažiausiai iki 2027 m. liepos 31 d. Preliminari 4.0 versija paskelbta 2026 m. rugsėjį, galutinės laukiama 2027 m. pavasarį. Paleisite su 3.0 ir atnaujinsite per pirmuosius metus.

ZUGFeRD yra hibridas: PDF/A-3 failas su įterptu CII XML. Žmonės skaito PDF, mašinos skaito XML. Prancūzijoje tas pats formatas vadinamas Factur-X, techniškai jie identiški. FeRD 2026 m. rugpjūčio 4 d. paskelbė 2.5.2 versiją. ZUGFeRD turi profilius (MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED), o ministerijos DUK priima ZUGFeRD nuo 2.0.1 versijos „mit Ausnahme der Profile MINIMUM und BASIC-WL“ (išskyrus profilius MINIMUM ir BASIC-WL).

Hibridinėje sąskaitoje faktūroje lemia XML. DUK struktūrizuotą dalį vadina „führender Teil“, pagrindine dalimi. Jei jūsų PDF ir XML nesutampa, klysta PDF.

Daugumai Vokietijos B2B sąskaitų išrašytojų protingiausias numatytasis pasirinkimas yra ZUGFeRD su EN 16931 profiliu, kad klientai, kurie vis dar skaito sąskaitas akimis, galėtų tęsti kaip anksčiau, ir XRechnung viešosioms institucijoms bei visiems, kas jo paprašo. Abu turėtų būti generuojami iš vieno vidinio sąskaitos objekto, o ne dviem atskirais kodo keliais.

Ką reikia pakeisti jūsų sistemoje

Sąskaita faktūra tampa duomenimis, o ne maketu

Daug senesnių sistemų sąskaitą sudaro spausdinimo metu: tekstas sujungiamas į šabloną, sumos skaičiuojamos ataskaitoje, PVM pastaba yra įrašyta kode pastraipa. Niekas iš to neišgyvena EN 16931. Jums reikia saugomo sąskaitos objekto su visais laukais, iš kurio generuojami ir XML, ir PDF.

Laukai, kurių dažniausiai trūksta arba kurie klaidingi:

• Šalių duomenys. Struktūrizuoti adresai su ISO šalių kodais ir PVM mokėtojo kodas arba mokesčių numeris. Laisvo teksto adresų blokus reikia išskaidyti.
• Tiekimo data arba paslaugų laikotarpis, saugomi kaip duomenys, o ne kaip sakinys antraštėje.
• Matavimo vienetai. Kiekvienam kiekiui reikia kodo iš JT EEK rekomendacijos Nr. 20 (H87 vienetui, KGM kilogramui, DAY dienai). „Stk.“ ir „pauschal“ reikia susieti su kodais.
• PVM. Kiekvienoje eilutėje yra PVM kategorija ir tarifas. Sąskaitoje pateikiamas vienas PVM išskaidymas kiekvienam kategorijos ir tarifo deriniui, o sumos turi tiksliai sutapti dviejų skaitmenų po kablelio tikslumu. Sistemos, kurios PVM apvalina kiekvienoje eilutėje, čia suklumpa.
• Atleidimo ir atvirkštinio apmokestinimo formuluotės. Sakinys PDF apačioje tampa PVM kategorijos kodu ir atleidimo priežastimi.
• Mokėjimas. Mokėjimo būdas, IBAN ir sąlygos struktūrizuota forma.
• Nuorodos. Užsakymo numeris arba pirkėjo nuoroda, pagal kurią jūsų kliento mokėtinų sumų komanda sutikrina sąskaitas. Jei jos niekada nesaugojote, pradėkite ją rinkti dabar.

Vien tekstinės eilutės („pristatymas, kaip sutarta“) yra dažna kliūtis. Struktūrizuotoje sąskaitoje faktūroje eilutė yra apmokestinama eilutė, todėl toks tekstas turi būti pastaboje.

Pataisymai, kreditiniai dokumentai ir savarankiškas sąskaitų išrašymas

DUK sako aiškiai: kai taikoma e. sąskaitos faktūros prievolė, pataisymas taip pat turi būti e. sąskaita faktūra, naudojant pataisymo sąskaitos tipą. EN 16931 jis nurodo ankstesnę sąskaitą pagal numerį ir išrašymo datą, todėl jūsų sistema turi tą ryšį saugoti kaip duomenis.

Atkreipkite dėmesį į terminiją. Vokietijos PVM teisėje „Gutschrift“ yra sąskaita faktūra, kurią iš anksto susitarus išrašo pats pirkėjas (UStG 14 straipsnio 2 dalis). Tai, ką angliškai kalbantis žmogus vadina kreditine sąskaita (kainos sumažinimas ar atšaukimas), yra pataisymas. Daug sistemų abiem atvejams naudoja vieną dokumento tipą. Atskirkite juos prieš susiedami, o jei sąskaitas tiekėjams išrašote patys, tuos dokumentus laikykite jūsų sistemos išrašomomis sąskaitomis faktūromis.

Galutinėje sąskaitoje faktūroje ankstesni daliniai mokėjimai gali būti išvardyti priede, jei struktūrizuota dalis į jį nurodo; DUK patvirtina, kad taip bus ir po 2027 m.

Patikra prieš išsiunčiant

KoSIT skelbia atvirojo kodo tikrintuvą, kuris tikrina XML pagal schemas ir Schematron taisykles, su viešai prieinama XRechnung konfigūracija. Jis veikia iš komandinės eilutės, kaip HTTP tarnyba arba kaip biblioteka. Įtraukite jį į siuntimo kelią: kiekviena sąskaita patikrinama prieš išsiunčiant, o klaida patenka į eilę, už kurią atsakingas konkretus žmogus, nurodant, kuris laukas pažeidė kurią taisyklę.

ZUGFeRD atveju patikrinkite įterptą XML pagal savo profilio taisykles, atskirai patikrinkite PDF/A-3 konteinerį ir įsitikinkite, kad PDF rodo tas pačias sumas kaip XML.

Perdavimas

Įstatymas, kaip sakoma DUK, „sieht keinen bestimmten Weg vor“: jis nenustato jokio kanalo. El. laiškas su prisegtu failu tinka. Tinka ir API, atsisiuntimo portalas, bendra saugykla įmonių grupėje ar (pačios ministerijos pavyzdys) USB atmintinė. Peppol vidaus B2B atsiskaitymams Vokietijoje nėra privalomas.

Inžinerinis darbas atliekamas kiekvienam klientui atskirai: sąskaitų adresas, pageidaujamas formatas ir įrašas, kas kur išsiųsta. Pakartotinis bandymas po nesėkmingo siuntimo siunčia tą patį dokumentą tuo pačiu sąskaitos numeriu. Du numeriai vienam tiekimui yra mokestinė, o ne programinė problema.

Archyvavimas

Bent jau struktūrizuotą dalį reikia saugoti „unversehrt in seiner ursprünglichen Form“, nepažeistą, pradine forma, o UStG 14b straipsnis nustato aštuonerių metų saugojimo terminą nuo išrašymo metų pabaigos. Saugokite tiksliai tuos baitus, kuriuos išsiuntėte, su maišos reikšme. Neplanuokite vėliau sąskaitų generuoti iš duomenų bazės iš naujo: iki to laiko ir duomenys, ir kodas bus pasikeitę. Tas pat taikoma ir gaunamoms e. sąskaitoms faktūroms.

Planas 2026 m. spaliui, lapkričiui ir gruodžiui

Trylikos savaičių pakanka kryptingam kūrimui, jei šaltinio duomenys yra pakankamai tvarkingi. Jų nepakanka atsiskaitymų sistemai pakeisti.

1 ir 2 savaitės: inventorizacija ir sprendimai. Surašykite kiekvieną vietą, kur sukuriama sąskaita faktūra, įskaitant rankinius kreditinius dokumentus, galutines projektų sąskaitas ir skaičiuoklę vienam dideliam klientui. Patikrinkite 2026 m. apyvartą pagal ribą. Pasirinkite numatytąjį formatą ir nuspręskite, ar generatorių kursite patys, ar sąskaitų duomenis siųsite e. sąskaitų paslaugų teikėjo API.

Nuo 2 iki 4 savaitės: duomenų spragų analizė. Susiekite trijų mėnesių tikras sąskaitas faktūras su EN 16931 lauką po lauko. Pažymėkite, ko trūksta, kas turi tapti kodu ir kas skaičiuojama kitaip. Čia ir paaiškėja tikrasis projekto dydis.

Nuo 4 iki 9 savaitės: kūrimas. Sąskaitos objektas, susiejimas, XML ir PDF/A-3 generavimas, tikrintuvas siuntimo kelyje, klaidų eilė ir archyvas. Lygiagrečiai kas nors tvarko pagrindinius duomenis ir surenka iš klientų sąskaitų adresus.

Nuo 9 iki 11 savaitės: pakartojimas ir bandomasis etapas. Paleiskite paskutinių trijų mėnesių sąskaitas per naująjį generatorių ir patikrinkite kiekvieną. Tada išbandykite su keliais norinčiais klientais ir paklauskite, ar jų sistemos perskaito failus.

Nuo 11 iki 13 savaitės: įšaldymas ir veiksmų vadovas. Gruodį įšaldykite pakeitimus. Užrašykite, kas atsakingas už klaidų eilę, kaip išrašomas pataisymas ir kas vyksta, kai klientas sąskaitą atmeta. Sausio sąskaitos už gruodžio darbus jau patenka į prievolės taikymo sritį.

2027 m. sausis. Paleiskite sistemą ir kasdien stebėkite eilę per pirmąją mėnesio pabaigą ir pirmąją PVM deklaraciją.

Per 2027 m. Suplanuokite perėjimą prie XRechnung 4.0, kol 3.0 dar galioja, ir iki 2028 m. sausio 1 d. perkelkite ir grupės įmones, kurios yra žemiau ribos.

Jei pradedate vėlai, mažinkite automatizavimą, o ne išvesties galiojimą: pirmiausia automatizuokite didžiausio kiekio sąskaitų tipus, o retus dokumentus kelias savaites siųskite per e. sąskaitų įrankį rankiniu būdu.

Kur gauti pagalbos

Kuriame jungtį tarp sistemos, kuri generuoja jūsų sąskaitas faktūras, ir įstatymo reikalaujamo formato: duomenų modelio pakeitimus, susiejimą, patikrą, perdavimą ir archyvą, jūsų kodo bazėje ir kartu su jūsų komanda. Mūsų e. sąskaitų faktūrų integracijos paslauga aprašo, kaip vyksta tokie projektai; jei prievolė sutampa su ERP keitimu, žr. ERP modernizavimą. Platesnis kalendorius pateiktas mūsų 2026 m. ES skaitmeninės atitikties vadove.

Esame inžinieriai, o ne mokesčių konsultantai: apimties klausimai priklauso jūsų mokesčių konsultantui (Steuerberater), o mes kuriame pagal jo atsakymą. Papasakokite, kas šiandien generuoja jūsų sąskaitas faktūras ir maždaug kiek jų išsiunčiama per mėnesį: rašykite office@c9group.dev.