Vācijas E-Rechnung prasība: strukturētu rēķinu izrakstīšana no pašu sistēmām līdz 2027. gada 1. janvārim

No 2027. gada 1. janvāra Vācijas uzņēmums, kura apgrozījums 2026. gadā pārsniedza 800 000 €, vairs nevar sūtīt papīra vai PDF rēķinu citam Vācijas uzņēmumam. Rēķinam jābūt strukturētam e-rēķinam: datu failam, kas veidots atbilstoši Eiropas standartam EN 16931. No 2028. gada 1. janvāra slieksnis izzūd, un noteikums attiecas uz visiem uzņēmumiem, izņemot dažus šaurus izņēmumus.

Nelielam uzņēmumam tas pienāk kā programmatūras atjauninājums. Uzņēmumam, kura rēķinus veido pašu norēķinu sistēma, nozares pakotne vai piecpadsmit gadu laikā pielāgota ERP sistēma, tas ir programmatūras projekts, un atlikušas aptuveni trīspadsmit nedēļas. Šis raksts ir otrajai grupai.

Ko nosaka likums

Definīcija ir § 14 UStG: rēķins, „die in einem strukturierten elektronischen Format ausgestellt, übermittelt und empfangen wird und eine elektronische Verarbeitung ermöglicht“. Formātam jāatbilst Eiropas standartam saskaņā ar Direktīvu 2014/55/ES (praksē EN 16931), vai arī tas var būt pušu saskaņots, ja vien nepieciešamos datus var pareizi un pilnībā izgūt formā, kas ir saderīga ar šo standartu. PDF neatbilst, lai cik kārtīgs tas izskatītos.

Pienākums attiecas uz piegādēm citam uzņēmumam, ja abas puses veic uzņēmējdarbību Vācijā. Pārejas noteikumi ir § 27 Abs. 38 UStG:

• Par 2025. un 2026. gadā veiktām piegādēm rēķinu joprojām drīkst izrakstīt uz papīra vai citā elektroniskā formātā, ja klients piekrīt, ar nosacījumu, ka rēķins tiek nosūtīts līdz 2026. gada 31. decembrim.
• Par 2027. gadā veiktām piegādēm tāds pats atvieglojums ir spēkā līdz 2027. gada 31. decembrim, bet tikai tad, ja izrakstītāja kopējais apgrozījums iepriekšējā kalendārajā gadā nepārsniedza 800 000 €.
• EDI, kas neatbilst standartam, par 2027. gadā veiktām piegādēm drīkst turpināt izmantot ar klienta piekrišanu neatkarīgi no jūsu lieluma.

Trīs detaļas ir svarīgākas, nekā šķiet.

Slieksni mēra pēc iepriekšējā gada apgrozījuma. Jūsu stāvoklis 2027. gadā ir atkarīgs no 2026. gada skaitļa, ko neviens precīzi nezinās, kamēr nav slēgti grāmatvedības gada pārskati. Ja esat kaut cik tuvu 800 000 €, būvējiet tā, it kā būtu virs tā.

Atvieglojums beidzas pēc nosūtīšanas datuma. Burtiski lasot, pirmais pārejas noteikums pārstāj attiekties uz papīru un PDF 2026. gada 31. decembrī, arī par 2026. gadā paveiktu darbu. Ja esat virs sliekšņa un izrakstāt rēķinus pēc fakta, rēķinam, ko janvāra pirmajā nedēļā sūtāt par decembra darbu, jau jābūt strukturētam. Pārliecinieties par to pie sava nodokļu konsultanta, taču neplānojiet ieviešanu janvāra vidū.

Daži rēķini paliek ārpus darbības jomas: rēķini patērētājiem, pārrobežu rēķini, mazas summas rēķini līdz 250 € bruto, biļetes, kas tiek uzskatītas par rēķiniem, Kleinunternehmer rēķini un piegādes, kas atbrīvotas saskaņā ar § 4 Nr. 8 līdz 29 UStG.

Mums nav zināms neviens likumprojekts, kas šos datumus pārceltu. Plānojiet tā, it kā tie paliks spēkā.

Saņemšana ir obligāta kopš 2025. gada. Izrakstīšana ir jaunā daļa.

Kopš 2025. gada 1. janvāra katram Vācijas uzņēmumam jāspēj saņemt e-rēķinus. Federālās finanšu ministrijas BUJ par e-rēķiniem ir tieši par to, kas tam vajadzīgs: „Für den Empfang einer elektronischen Rechnung genügt bereits ein E-Mail-Postfach.“ Pietiek ar e-pasta kastīti.

Ievērojiet vienu rindu pašā § 14: ja piemēro e-rēķina pienākumu, saņēmēja piekrišana nav nepieciešama. Vācijas uzņēmums, kas ir jūsu klients, nevar atteikties no jūsu strukturētā rēķina.

Izrakstīšana ir cita problēma. Saņemot rīks nolasa kāda cita failu. Izrakstot autors ir jūsu sistēma: ja dati ir kļūdaini jau avotā, neviens tālāk ķēdē tos nevar izlabot, un rēķins, kas neiztur jūsu klienta validāciju, paliek neapmaksāts.

Kas to saņems atjauninājuma veidā

Vienkārši sakot: ja esat neliels uzņēmums, kas izraksta rēķinus no DATEV, lexoffice, sevDesk vai līdzīgas pakotnes, formātu nodrošina jūsu piegādātājs. Pārbaudiet pamatdatus (PVN numuru, klientu adreses, bankas rekvizītus), ieslēdziet funkciju un nosūtiet testa rēķinu. Jums nav vajadzīgs ne projekts, ne programmatūras uzņēmums.

Līdzīgi ir ar plaši izplatītu ERP, kas joprojām ir tuvu standartam: izvadi nodrošina piegādātājs vai jūsu partneris, un darbs ir konfigurēšana un testēšana.

Pārējā raksta daļa ir uzņēmumiem, kuru rēķinus veido pašiem piederošs kods vai kods, ko vairs neviens neuztur:

• norēķinu dzinēji abonēšanas platformās, tirdzniecības platformās un komunālajos pakalpojumos, kas programmatiski izraksta rēķinus lielā apjomā;
• nozares programmatūra vairumtirdzniecībai, būvniecībai, loģistikai vai lauka servisam, kur piegādātājs ir mazs, lēns vai vairs neeksistē;
• ERP sistēmas, kuru rēķinu izvade pirms gadiem tika pārrakstīta kā pielāgotas drukas programmas, atskaišu veidnes vai mēneša beigu sapludināšana.

Formāti: EN 16931, XRechnung un ZUGFeRD

EN 16931 ir Eiropas standarts. Tas definē rēķina semantisko modeli (laukus, to nozīmi, obligātos laukus un biznesa noteikumus starp tiem) un piesaista to divām XML sintaksēm: UBL 2.1 un UN/CEFACT CII.

XRechnung ir Vācijas specifikācija virs EN 16931, ko uztur KoSIT: tīrs XML jebkurā no abām sintaksēm, obligāts publiskajām iestādēm un tikpat derīgs starp uzņēmumiem. Saskaņā ar KoSIT XRechnung lapu 3.0 versija ir spēkā kopš 2024. gada 1. februāra un paliek spēkā vismaz līdz 2027. gada 31. jūlijam. 4.0 provizoriskā versija tika publicēta 2026. gada septembrī, un galīgā versija gaidāma 2027. gada pavasarī. Jūs sāksiet darbu ar 3.0 un atjaunināsiet pirmā gada laikā.

ZUGFeRD ir hibrīds: PDF/A-3 fails ar tajā iegultu CII XML. Cilvēki lasa PDF, mašīnas lasa XML. Francijā tas pats formāts saucas Factur-X, un tehniski abi ir identiski. FeRD 2026. gada 4. augustā publicēja 2.5.2 versiju. ZUGFeRD ir pieejams profilos (MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED), un ministrijas BUJ pieņem ZUGFeRD no 2.0.1 versijas „mit Ausnahme der Profile MINIMUM und BASIC-WL“.

Hibrīdrēķinā noteicošais ir XML. BUJ strukturēto daļu sauc par „führender Teil“, vadošo daļu. Ja jūsu PDF un XML nesakrīt, kļūdains ir PDF.

Lielākajai daļai Vācijas B2B rēķinu izrakstītāju saprātīgs noklusējums ir ZUGFeRD EN 16931 profilā, lai klienti, kas joprojām rēķinus lasa ar acīm, varētu turpināt to darīt, kā arī XRechnung publiskajām iestādēm un ikvienam, kas to lūdz. Abiem jārodas no viena iekšējā rēķina objekta, nevis no diviem koda ceļiem.

Kas jāmaina jūsu sistēmā

Rēķins kļūst par datiem, nevis izkārtojumu

Daudzas vecākas sistēmas rēķinu veido drukāšanas brīdī: teksts tiek salikts veidnē, kopsummas saskaitītas atskaitē, PVN piezīme ir iekodēta rindkopa. Nekas no tā EN 16931 neiztur. Jums vajadzīgs saglabāts rēķina objekts ar visiem laukiem, no kura tiek veidots gan XML, gan PDF.

Lauki, kas parasti trūkst vai ir kļūdaini:

• Pušu dati. Strukturētas adreses ar ISO valstu kodiem un PVN numurs vai nodokļu maksātāja numurs. Brīva teksta adrešu bloki jāsadala.
• Piegādes datums vai pakalpojuma periods, glabāts kā dati, nevis kā teikums galvenē.
• Mērvienības. Katram daudzumam vajadzīgs kods no UN/ECE Ieteikuma Nr. 20 (H87 gabalam, KGM kilogramam, DAY dienai). „Stk.“ un „pauschal“ jāpiesaista kodiem.
• PVN. Katrai rindai ir PVN kategorija un likme. Rēķinā ir viens PVN sadalījums katrai kategorijas un likmes kombinācijai, un kopsummām jāsakrīt precīzi ar divām zīmēm aiz komata. Sistēmas, kas PVN noapaļo katrā rindā, šeit neiztur.
• Atbrīvojuma un apgrieztās maksāšanas formulējumi. Teikums PDF apakšā kļūst par PVN kategorijas kodu un atbrīvojuma iemeslu.
• Maksājums. Maksājuma veids, IBAN un nosacījumi strukturētā veidā.
• Atsauces. Pasūtījuma numurs vai pircēja atsauce, pēc kuras jūsu klienta kreditoru uzskaite sasaista rēķinu. Ja to nekad neesat glabājuši, sāciet to vākt tagad.

Tikai teksta rindas („piegāde, kā norunāts“) ir bieži sastopams klupšanas akmens. Strukturētā rēķinā rinda ir apmaksājama rinda, tāpēc šis teksts pieder piezīmei.

Labojumi, kredītrēķini un pašizrakstīšana

BUJ ir nepārprotams: ja piemēro e-rēķina pienākumu, arī labojumam jābūt e-rēķinam ar labojuma rēķina veidu. EN 16931 tas atsaucas uz iepriekšējo rēķinu ar numuru un izrakstīšanas datumu, tāpēc jūsu sistēmai šī saikne jāglabā kā dati.

Uzmanieties ar terminoloģiju. Vācijas PVN tiesībās „Gutschrift“ ir pašizrakstīts rēķins, ko pēc iepriekšējas vienošanās izraksta klients (§ 14 Abs. 2 UStG). Tas, ko angliski runājošs cilvēks sauc par kredītrēķinu (cenas samazinājumu vai anulēšanu), ir labojums. Daudzas sistēmas abiem izmanto vienu dokumenta veidu. Nodaliet tos, pirms piesaistāt laukiem, un, ja izrakstāt rēķinus piegādātāju vietā, uzskatiet šos dokumentus par rēķiniem, ko izraksta jūsu sistēma.

Galīgajā rēķinā drīkst uzskaitīt iepriekšējos daļējos maksājumus pielikumā, ja strukturētā daļa uz to atsaucas; BUJ apstiprina, ka tas būs iespējams arī pēc 2027. gada.

Validācija, pirms kaut kas tiek nosūtīts

KoSIT publicē atvērtā koda validatoru, kas pārbauda XML pret shēmām un Schematron noteikumiem, ar publisku konfigurāciju XRechnung formātam. Tas darbojas no komandrindas, kā HTTP dēmons vai kā bibliotēka. Ievietojiet to nosūtīšanas ceļā: katrs rēķins tiek validēts, pirms tas tiek nosūtīts, un kļūme nonāk rindā, par kuru atbild konkrēta persona, ar norādi, kurš lauks pārkāpa kuru noteikumu.

ZUGFeRD gadījumā validējiet iegulto XML pret sava profila noteikumiem, atsevišķi pārbaudiet PDF/A-3 konteineru un pārliecinieties, ka PDF rāda tās pašas kopsummas, ko XML.

Nosūtīšana

Likums, kā teikts BUJ, „sieht keinen bestimmten Weg vor“: tas nenosaka kanālu. E-pasts ar pievienotu failu ir derīgs. Tāpat API, lejupielādes portāls, koplietota krātuve grupas ietvaros vai (paša ministrijas piemērs) USB zibatmiņa. Peppol Vācijā iekšzemes B2B darījumiem nav obligāts.

Inženiertehniskais darbs ir katram klientam atsevišķi: rēķinu adrese, vēlamais formāts un ieraksts par to, kas un kur nosūtīts. Atkārtota nosūtīšana pēc neveiksmīga mēģinājuma satur to pašu dokumentu ar to pašu rēķina numuru. Divi numuri vienai piegādei ir nodokļu problēma, nevis programmatūras problēma.

Arhivēšana

Vismaz strukturētā daļa jāglabā „unversehrt in seiner ursprünglichen Form“, neskarta sākotnējā formā, un § 14b UStG nosaka glabāšanas termiņu astoņus gadus no izrakstīšanas gada beigām. Glabājiet precīzi tos baitus, ko nosūtījāt, ar kontrolsummu. Neplānojiet vēlāk ģenerēt rēķinus no jauna no datubāzes: līdz tam laikam gan dati, gan kods būs mainījušies. Tas pats attiecas uz e-rēķiniem, ko saņemat.

Plāns no 2026. gada oktobra līdz decembrim

Trīspadsmit nedēļas pietiek mērķtiecīgai izstrādei, ja avota dati ir saprātīgā stāvoklī. Ar tām nepietiek, lai nomainītu norēķinu sistēmu.

1. un 2. nedēļa: inventarizācija un lēmumi. Uzskaitiet katru vietu, kur rodas rēķins, ieskaitot manuālus kredītrēķinus, projektu gala rēķinus un izklājlapu vienam lielam klientam. Salīdziniet 2026. gada apgrozījumu ar slieksni. Izvēlieties noklusējuma formātu un izlemiet, vai ģeneratoru veidojat paši vai sūtāt rēķinu datus e-rēķinu pakalpojumu sniedzēja API.

2. līdz 4. nedēļa: datu robu analīze. Salīdziniet trīs mēnešu reālus rēķinus ar EN 16931 lauku pa laukam. Atzīmējiet, kas trūkst, kam jākļūst par kodu un kas tiek aprēķināts citādi. Tieši šeit kļūst redzams projekta patiesais apjoms.

4. līdz 9. nedēļa: izstrāde. Rēķina objekts, lauku piesaiste, XML un PDF/A-3 veidošana, validators nosūtīšanas ceļā, kļūmju rinda un arhīvs. Paralēli kāds sakārto pamatdatus un savāc no klientiem rēķinu adreses.

9. līdz 11. nedēļa: atkārtota palaišana un izmēģinājums. Palaidiet pēdējo trīs mēnešu rēķinus caur jauno ģeneratoru un validējiet katru. Tad veiciet izmēģinājumu ar dažiem atsaucīgiem klientiem un pajautājiet, vai viņu sistēmas nolasa failus.

11. līdz 13. nedēļa: iesaldēšana un rokasgrāmata. Decembrī iesaldējiet izmaiņas. Pierakstiet, kas atbild par kļūmju rindu, kā tiek izrakstīts labojums un kas notiek, ja klients rēķinu noraida. Janvāra rēķini par decembra darbu jau ietilpst darbības jomā.

2027. gada janvāris. Ieviešana un ikdienas rindas uzraudzība līdz pirmajām mēneša beigām un pirmajai PVN deklarācijai.

Visu 2027. gadu. Ieplānojiet atjaunināšanu uz XRechnung 4.0, pirms 3.0 zaudē derīgumu, un pārvediet visus grupas uzņēmumus, kas ir zem sliekšņa, pirms 2028. gada 1. janvāra.

Ja sākat vēlu, samaziniet automatizāciju, nevis izvades derīgumu: vispirms automatizējiet lielā apjomā izrakstītos rēķinu veidus un retus dokumentus dažas nedēļas sūtiet manuāli caur e-rēķinu rīku.

Kur saņemt palīdzību

Mēs izveidojam savienojumu starp sistēmu, kas veido jūsu rēķinus, un formātu, ko prasa likums: datu modeļa izmaiņas, lauku piesaisti, validāciju, nosūtīšanu un arhīvu, jūsu koda bāzē un kopā ar jūsu komandu. Mūsu e-rēķinu integrācijas pakalpojumā aprakstīts, kā šādi projekti norit; ja prasība sakrīt ar ERP maiņu, skatiet ERP modernizāciju. Plašāks kalendārs ir mūsu 2026. gada ES digitālās atbilstības ceļvedī.

Mēs esam inženieri, nevis nodokļu konsultanti: jautājumi par darbības jomu jāuzdod jūsu Steuerberater, un mēs būvējam atbilstoši viņa atbildei. Pastāstiet, kas šodien veido jūsu rēķinus un aptuveni cik rēķinu katru mēnesi tiek nosūtīts: rakstiet uz office@c9group.dev.