Федеральне міністерство фінансів Німеччини (BMF) 15 жовтня 2026 року видало третій офіційний лист щодо е-рахунків — як і листи 2024 та 2025 років, саме 15 жовтня. Він зводить докупи роз’яснення, які міністерство досі давало лише у відповідях галузевим об’єднанням, змінює Umsatzsteuer-Anwendungserlass (настанову із застосування закону про ПДВ) і дає пільговий строк до кінця року. За одинадцять тижнів до 1 січня 2027 року це той стандарт, за яким з Нового року перевірятимуть рахунки.
Станом на 16 жовтня 2026 року. Лист BMF від 15.10.2026, GZ III C 5 - S 7287-a/00019/021/017, «Запровадження обов’язкового електронного рахунку для операцій між німецькими підприємцями з 1 січня 2025 року». Подробиці нижче — за першими розборами у фаховій пресі; юридичну силу має текст листа на сайті BMF.
Що це за лист
З лютого 2026 року BMF відповідав на окремі питання листами до галузевих об’єднань — ремесла, промисловості, енергетики: про рахунки в будівництві, виправлення рахунків, обов’язок з 2027 року. Офіційно нічого з цього не публікувалося, тож покладатися на ці відповіді можна було лише частково. Новий лист зводить головне, додає нові положення і вносить їх до настанови. Він діє для операцій після 31 грудня 2024 року; перехідні правила закону до кінця 2026 і кінця 2027 року не змінюються — хто і коли мусить виставляти, описано в новині Обов’язок е-рахунків у 2027 році.
Пільговий строк до 31 грудня 2026
Е-рахунок, виставлений до 31 грудня 2026 року, який відповідає листам 2024 і 2025 років, але ще не новим вимогам від 15 жовтня 2026, податкова не оскаржуватиме — прямо зазначено, що й щодо податкового кредиту отримувача. На практиці: перейти до кінця року, з 2027-го новий стандарт діє без поблажок.
Головне
Усі обов’язкові реквізити — в XML
Реквізити за § 14 абз. 4 і § 14a UStG мають бути у структурованій частині; щодо відповідності полів податкова відсилає до таблиць KoSIT і FeRD. Опис поставки має дозволяти податкову оцінку — простого посилання на договір недостатньо, як і посилання на інформацію в неструктурованому додатку. Те, що виходить за ці межі, наприклад табелі годин, можна передати вбудованим додатком. Видима PDF-сторінка рахунку ZUGFeRD тут не рахується: значення має XML.
Виправлення — лише е-рахунком
Якщо первинний рахунок мав бути е-рахунком, ним має бути і виправлення — з типом рахунку для коригування (у списку кодів EN 16931 це 384) і однозначним посиланням на первинний рахунок. Конкретного способу — заміна, різниця чи сторно — BMF не приписує. Старий «метод червоного олівця», коли отримувач позначає помилки на папері, а виставник погоджується, тепер працює лише для звичайних (неструктурованих) рахунків. Отримувач може виправити е-рахунок і власною кредит-нотою (Gutschrift), якщо це узгоджено і вона чітко називає первинний рахунок. Де кредит-нота і коригування стоять в XML — у статті Структура XML.
Перевірка — допомога, а не умова
Валідація не є юридичною умовою чинності е-рахунку, це спосіб підтвердити дотримання формальних вимог. Державного інструмента перевірки не буде, постачальників BMF не рекомендує. Щодо типів помилок лінія 2025 року незмінна: помилка бізнес-правила важить для ПДВ лише тоді, коли зачіпає обов’язковий реквізит.
Будівництво й аванси: послаблення до середини 2030
Для будівельних робіт до 30 червня 2030 року структурована частина може містити лише суми за видами робіт, якщо читабельний додаток розписує їх за кошторисом, а XML прямо на нього посилається. Для фінальних рахунків після авансів податкова до тієї ж дати приймає, що сплачені наперед суми віднімаються одним підсумком, а подробиці — у примітці до рахунку чи вбудованому додатку.
Якщо виставник не знав, що клієнт — підприємець
Обов’язок діє лише щодо підприємців, які купують для свого бізнесу. Якщо виставник не міг цього розпізнати навіть за належної обачності, відсутність е-рахунку не оскаржуватимуть. Для довгострокових договорів достатньо перевірки на початку договору або при його зміні.
Що зробити зараз
- Переглянути описи поставок. Де в рахунку лише «згідно з договором № …», до кінця року в XML має з’явитися справжній опис.
- Визначити, як виправляти рахунки. Хто з 2027 року мусить виставляти е-рахунки, тому потрібна й програма, що створює тип 384 з посиланням на первинний рахунок.
- Зберігати звіти перевірки. Валідація — не умова, але найпростіший доказ, що формат і реквізити в порядку; докладніше — Валідація е-рахунків.
- У будівництві — передбачити додаток. Суми за видами робіт у XML, кошторис читабельно поруч, посилання в XML.
- Окремі випадки — з податковим консультантом. Лист великий, і фахова преса не в кожному пункті читає його однаково.
Часті запитання
Чи треба переробляти рахунки, виставлені у 2026 році?
Ні. Е-рахунки, виставлені до 31 грудня 2026 року відповідно до листів 2024 і 2025 років, податкова не оскаржуватиме, зокрема щодо податкового кредиту.
Чи змінює лист строки на 2027 і 2028 роки?
Ні. Перехідні правила встановлені законом (§ 27 абз. 38 UStG) і не змінюються: з 2027 року виставляти зобов’язані ті, у кого оборот за попередній рік понад 800 000 €, з 2028-го — усі.
Чи недійсний рахунок, якщо валідатор показує помилку?
Не автоматично. Валідація не є юридичною умовою. Але помилка формату позбавляє файл статусу е-рахунку, а помилка бізнес-правила важить, якщо зачіпає обов’язковий реквізит.
Чи вміє E-Rechnung Pro створювати рахунки-коригування?
Форма виставляє звичайні рахунки. Якщо завантажити в конвертер надрукований рахунок-коригування чи сторно, він перенесе тип 384 і номер первинного рахунку, наскільки той вказаний у документі.
Коротко
- Третій офіційний лист BMF щодо е-рахунків від 15 жовтня 2026 року, зі змінами до настанови із застосування закону про ПДВ.
- Пільговий строк: е-рахунки до 31 грудня 2026 року за попереднім стандартом не оскаржуватимуть.
- Усі обов’язкові реквізити — в XML, без голого посилання на договір; виправлення е-рахунку — знову е-рахунком.
- Валідація — доказ, а не умова; послаблення для будівництва й авансів до 30 червня 2030 року.
Чи відповідають ваші рахунки формату й бізнес-правилам, перевірте безкоштовно і без реєстрації — звіт називає кожне порушене правило з його кодом.
E-Rechnung Pro створює та перевіряє документи за EN 16931:2017 — версією, на якій сьогодні побудовані ZUGFeRD 2.x і Factur-X. Ми стежимо за редакцією EN 16931-1:2026 і підтримаємо її, щойно її приймуть формати.