Задължителната E-Rechnung в Германия: издаване на структурирани фактури от собствените ви системи до 1 януари 2027 г.

От 1 януари 2027 г. германско предприятие с оборот над 800 000 € през 2026 г. вече не може да изпраща хартиена или PDF фактура на друго германско предприятие. Фактурата трябва да е структурирана електронна фактура: файл с данни, изграден по европейския стандарт EN 16931. От 1 януари 2028 г. прагът отпада и правилото важи за всяко предприятие, с изключение на няколко тесни случая.

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

Какво казва законът

Определението е в § 14 UStG (германския Закон за ДДС): фактура, „die in einem strukturierten elektronischen Format ausgestellt, übermittelt und empfangen wird und eine elektronische Verarbeitung ermöglicht“ (която се издава, предава и получава в структуриран електронен формат и позволява електронна обработка). Форматът трябва да съответства на европейския стандарт по Директива 2014/55/ЕС (на практика EN 16931) или да е договорен между страните, при условие че изискуемите данни могат да се извлекат правилно и пълно във вид, съвместим с този стандарт. PDF не отговаря на условията, колкото и подреден да изглежда.

Задължението обхваща доставките към друго предприятие, когато и двете страни са установени в Германия. Преходният режим е в § 27 Abs. 38 UStG:

• За доставки през 2025 и 2026 г. още може да се фактурира на хартия или в друг електронен формат, ако клиентът е съгласен, стига фактурата да е изпратена до 31 декември 2026 г.
• За доставки през 2027 г. същото облекчение важи до 31 декември 2027 г., но само ако общият оборот на издателя за предходната календарна година не е надвишавал 800 000 €.
• EDI, който не отговаря на стандарта, може да продължи за доставки през 2027 г. със съгласието на клиента, независимо от размера ви.

Три подробности са по-важни, отколкото изглеждат.

Прагът се измерва по оборота от миналата година. Положението ви през 2027 г. зависи от цифрата ви за 2026 г., която никой няма да знае точно, докато книгите не бъдат приключени. Ако сте близо до 800 000 €, изграждайте така, сякаш сте над прага.

Облекчението свършва с дата на изпращане. Буквално прочетено, първото преходно правило престава да покрива хартия и PDF на 31 декември 2026 г., дори за работа, извършена през 2026 г. Ако сте над прага и фактурирате със закъснение, фактурата, която изпращате в първата седмица на януари за работата през декември, вече трябва да е структурирана. Потвърдете това с данъчния си консултант, но не планирайте старт в средата на януари.

Някои фактури остават извън обхвата: фактурите към потребители, трансграничните фактури, фактурите за малки суми до 250 € бруто, билетите, които се зачитат за фактури, фактурите от Kleinunternehmer (малки предприемачи) и доставките, освободени по § 4 Nr. 8 до 29 UStG.

Не ни е известен законопроект, който да измества тези дати. Планирайте така, сякаш остават в сила.

Получаването важи от 2025 г. Издаването е новата част.

От 1 януари 2025 г. всяко германско предприятие трябва да може да получава електронни фактури. Въпросите и отговорите за електронното фактуриране на Федералното министерство на финансите са категорични какво е нужно за това: „Für den Empfang einer elektronischen Rechnung genügt bereits ein E-Mail-Postfach.“ Стига пощенска кутия.

Обърнете внимание на един ред в самия § 14: там, където се прилага задължението за електронна фактура, съгласието на получателя не е необходимо. Германски бизнес клиент не може да откаже структурираната ви фактура.

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

Кой ще получи това с обновяване

Казано направо: ако сте малка фирма и фактурирате от DATEV, lexoffice, sevDesk или подобен пакет, доставчикът ви осигурява формата. Проверете основните си данни (ДДС номер, адреси на клиенти, банкови данни), включете функцията и изпратете тестова фактура. Не ви трябва проект и не ви трябва софтуерна фирма.

Почти същото важи за популярна ERP система, която е останала близо до стандарта: доставчикът или партньорът ви осигурява изхода, а работата е конфигуриране и тестване.

Останалата част от статията е за компании, чиито фактури идват от код, който притежават, или от код, който никой вече не поддържа:

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

Форматите: EN 16931, XRechnung и ZUGFeRD

EN 16931 е европейският стандарт. Той определя семантичния модел на фактурата (полетата, какво означават, кои са задължителни и бизнес правилата между тях) и го свързва с два XML синтаксиса, UBL 2.1 и UN/CEFACT CII.

XRechnung е германската спецификация върху EN 16931, поддържана от KoSIT: чист XML в който и да е от двата синтаксиса, изискван от публичните органи и еднакво валиден между предприятия. Според страницата на KoSIT за XRechnung версия 3.0 е в сила от 1 февруари 2024 г. и остава в сила поне до 31 юли 2027 г. Предварителна версия на 4.0 беше публикувана през септември 2026 г., а окончателното издание се очаква през пролетта на 2027 г. Ще стартирате с 3.0 и ще надградите през първата си година.

ZUGFeRD е хибрид: файл PDF/A-3 с вграден в него CII XML. Хората четат PDF, машините четат XML. Във Франция същият формат се нарича Factur-X и технически двата са идентични. FeRD публикува версия 2.5.2 на 4 август 2026 г. ZUGFeRD има профили (MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED), а въпросите и отговорите на министерството приемат ZUGFeRD от версия 2.0.1 „mit Ausnahme der Profile MINIMUM und BASIC-WL“ (с изключение на профилите MINIMUM и BASIC-WL).

При хибридната фактура важи XML. Въпросите и отговорите наричат структурираната част „führender Teil“, водещата част. Ако PDF и XML се разминават, грешен е PDF.

За повечето германски B2B издатели разумният избор по подразбиране е ZUGFeRD в профил EN 16931, за да могат клиентите, които още четат фактурите с очи, да продължат така, плюс XRechnung за публичните органи и за всеки, който го поиска. И двете трябва да идват от един вътрешен обект на фактурата, а не от два отделни пътя в кода.

Какво трябва да се промени в системата ви

Фактурата става данни, а не оформление

Много по-стари системи изграждат фактурата в момента на печат: текст, слепен в шаблон, суми, събрани вътре в отчета, бележка за ДДС като твърдо зададен абзац. Нищо от това не оцелява при EN 16931. Трябва ви съхраняван обект на фактурата, който пази всяко поле, а XML и PDF се генерират от него.

Полетата, които обикновено липсват или са грешни:

• Данни за страните. Структурирани адреси с кодове на държави по ISO и ДДС номер или данъчен номер. Адресните блокове в свободен текст трябва да се разделят.
• Дата на доставката или период на услугата, пазени като данни, а не като изречение в заглавната част.
• Мерни единици. Всяко количество се нуждае от код по Препоръка 20 на UN/ECE (H87 за брой, KGM за килограм, DAY за ден). „Stk.“ и „pauschal“ трябва да се съпоставят.
• ДДС. Всеки ред носи категория и ставка на ДДС. Фактурата носи по една разбивка на ДДС за всяка комбинация от категория и ставка, а сумите трябва да се събират точно до втория знак след десетичната запетая. Системите, които закръглят ДДС на ниво ред, се провалят тук.
• Текстове за освобождаване и обратно начисляване. Изречението в долната част на PDF става код на категорията ДДС плюс основание за освобождаване.
• Плащане. Начин на плащане, IBAN и условия в структуриран вид.
• Препратки. Номерът на поръчката или референцията на купувача, по които отделът за задължения на клиента ви съпоставя. Ако никога не сте я пазили, започнете да я събирате още сега.

Редовете само с текст („доставка според уговореното“) са често препятствие. В структурираната фактура редът е ред за таксуване, така че този текст е за бележка.

Корекции, кредитни известия и самофактуриране

Въпросите и отговорите са изрични: там, където се прилага задължението за електронна фактура, корекцията също трябва да е електронна фактура, с вида фактура за корекция. В EN 16931 тя препраща към предходната фактура по номер и дата на издаване, така че системата ви трябва да пази тази връзка като данни.

Внимавайте с терминологията. В германското право за ДДС „Gutschrift“ е фактура, издадена от получателя, тоест от клиента по предварителна уговорка (§ 14 Abs. 2 UStG). Това, което англоговорящите наричат credit note (намаление на цената или анулиране), е корекция. Много системи използват един вид документ и за двете. Разделете ги, преди да ги съпоставите, а ако самофактурирате доставчици, третирайте тези документи като фактури, които издава вашата система.

Окончателна фактура може да изброява предишни частични плащания в приложение, при условие че структурираната част препраща към него; въпросите и отговорите потвърждават, че това продължава и след 2027 г.

Валидиране, преди нещо да излезе

KoSIT публикува валидатор с отворен код, който проверява XML спрямо схеми и правила на Schematron, с публична конфигурация за XRechnung. Работи от командния ред, като HTTP демон или като библиотека. Поставете го в пътя на изпращане: всяка фактура се валидира, преди да излезе, а грешката попада в опашка, която има конкретен отговорник, с указание кое поле кое правило е нарушило.

При ZUGFeRD валидирайте вградения XML спрямо правилата на вашия профил, проверявайте контейнера PDF/A-3 отделно и потвърждавайте, че PDF показва същите суми като XML.

Предаване

Законът, казват въпросите и отговорите, „sieht keinen bestimmten Weg vor“: не предписва канал. Имейл с прикачен файл е напълно приемлив. Също и API, портал за изтегляне, споделено хранилище в рамките на група или (собственият пример на министерството) USB памет. За вътрешните B2B доставки в Германия Peppol не е задължителен.

Инженерната работа е за всеки клиент поотделно: адрес за фактури, предпочитан формат и запис какво къде е изпратено. Повторният опит след неуспешно изпращане носи същия документ със същия номер на фактурата. Два номера за една доставка е данъчен проблем, а не софтуерен.

Архивиране

Поне структурираната част трябва да се пази „unversehrt in seiner ursprünglichen Form“, непокътната в първоначалния си вид, а § 14b UStG определя срок на съхранение от осем години от края на годината на издаване. Пазете точните байтове, които сте изпратили, с хеш. Не планирайте да генерирате фактурите наново от базата данни по-късно: дотогава и данните, и кодът ще са се променили. Същото важи и за получените електронни фактури.

План за периода октомври-декември 2026 г.

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

Седмици 1 и 2: инвентаризация и решения. Избройте всяко място, където се създава фактура, включително ръчните кредитни известия, окончателните фактури по проекти и електронната таблица за един голям клиент. Сравнете оборота за 2026 г. с прага. Изберете формата по подразбиране и решете дали изграждате генератора сами, или изпращате данните за фактурите към API на доставчик на електронно фактуриране.

Седмици 2 до 4: анализ на липсите в данните. Съпоставете три месеца реални фактури поле по поле с EN 16931. Отбележете какво липсва, какво трябва да стане код и какво се изчислява по различен начин. Тук се вижда истинският размер на проекта.

Седмици 4 до 9: разработка. Обектът на фактурата, съпоставянето, генерирането на XML и PDF/A-3, валидаторът в пътя на изпращане, опашката за грешки и архивът. Успоредно с това някой почиства основните данни и събира адресите за фактури от клиентите.

Седмици 9 до 11: повторно пускане и пилот. Прекарайте фактурите от последните три месеца през новия генератор и валидирайте всяка от тях. После направете пилот с няколко клиенти, които са готови, и ги попитайте дали системите им четат файловете.

Седмици 11 до 13: замразяване и наръчник. Замразете промените през декември. Запишете кой отговаря за опашката за грешки, как се издава корекция и какво става, когато клиент отхвърли фактура. Януарските фактури за работата през декември вече са в обхвата.

Януари 2027 г. Стартирайте и следете опашката всеки ден през първото приключване на месеца и първата декларация по ДДС.

През 2027 г. Планирайте надграждането до XRechnung 4.0, преди 3.0 да престане да е валидна, и прехвърлете дружествата от групата под прага преди 1 януари 2028 г.

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

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

Ние изграждаме връзката между системата, която създава фактурите ви, и формата, който законът изисква: промени в модела на данните, съпоставяне, валидиране, предаване и архив, в собствения ви код и заедно с вашия екип. Нашата услуга за интеграция на електронно фактуриране описва как протичат тези проекти; ако задължението ви завари по средата на смяна на ERP системата, вижте модернизация на ERP. По-широкият календар е в нашето ръководство за цифровото съответствие в ЕС за 2026 г.

Ние сме инженери, а не данъчни консултанти: въпросите за обхвата са за вашия Steuerberater (данъчен консултант), а ние изграждаме според неговия отговор. Кажете ни какво създава фактурите ви днес и приблизително колко излизат всеки месец: пишете ни на office@c9group.dev.