ПДВ — та частина електронного рахунку, на якій завалюється більшість файлів, і майже ніколи не через хибну суму. Завалюються тому, що «0 %» у структурованій частині нічого не пояснює: норма хоче знати яка категорія, яка ставка і, якщо податку немає, чому саме.
Це орієнтир, а не податкова консультація. Чи підпадає операція під зворотне нарахування, чи є вона звільненою, чи взагалі не є об’єктом ПДВ — вирішує конкретний випадок. Тут ідеться про наступне питання: як те, що встановив ваш бухгалтер, правильно показати у файлі?
Три поля, а не одне
У рахунку за EN 16931 ПДВ живе у трьох місцях, і їх постійно плутають:
| Дані | У позиції | У зведенні (BG-23) |
|---|---|---|
| Код категорії | BT-151 | BT-118 |
| Ставка у відсотках | BT-152 | BT-119 |
| Підстава звільнення | — | BT-120 (текст) або BT-121 (код) |
Код категорії — це не ставка. Нульова ставка може означати: звільнено, зворотне нарахування, постачання в межах ЄС, експорт або взагалі не об’єкт ПДВ — п’ять різних ситуацій із п’ятьма різними кодами й різними обов’язковими полями. Тому написати «без податку» в тексті рахунку й поставити ставку 0 недостатньо.
Крім того, кожна комбінація коду і ставки утворює власну групу BG-23. Кілька ставок в одному рахунку — не виняток, і профіль EXTENDED для цього не потрібен: це вміє вже EN 16931.
Коди категорій одним поглядом
Усього норма знає дев’ять кодів. Сім із них вище; ще є L і M — канарський IGIC та IPSI у Сеуті й Мелільї, поза Іспанією майже не трапляються.
Спершу про плутанину, яка тягнеться багатьма посібниками: код постачання в межах ЄС — K. Правила до нього звуться BR-IC-*. «IC» — це не код категорії, а назва сімейства правил; хто впише «IC» у поле, отримає файл, який не пройде перевірку за списком кодів.
Зворотне нарахування: код AE
За зворотного нарахування податок сплачує отримувач, а не постачальник (у Німеччині § 13b UStG, у праві ЄС — статті 194 і далі директиви про ПДВ). У XML це означає:
- Код категорії AE в позиції і рівно одна група AE у зведенні (BR-AE-01).
- Ставка 0 (BR-AE-05) і сума податку 0 (BR-AE-09).
- Підстава звільнення: або код
VATEX-EU-AEв BT-121, або текст «Reverse charge» в BT-120 (BR-AE-10). - Обидві сторони ідентифіковані: номер ПДВ або податковий номер продавця і номер ПДВ покупця (BR-AE-02). Саме ця умова найчастіше й не виконується.
На видимій сторінці залишається обов’язковий напис — у Німеччині «Steuerschuldnerschaft des Leistungsempfängers» за § 14a (5) UStG; допускаються й формулювання інших офіційних мов, як-от «Reverse charge». Окремої суми податку при цьому не показують.
Дорога пастка: хто попри зворотне нарахування все ж покаже ПДВ, той цей податок і винен — у Німеччині за § 14c (1) UStG, — тоді як отримувач не зможе врахувати його як податковий кредит. Одне неправильно заповнене поле коштує грошей обом сторонам.
Постачання в межах ЄС: код K
Постачання товарів між підприємствами різних держав ЄС звільнене від ПДВ за умов статті 138 директиви про ПДВ. Код для цього — K, ставка й сума податку нульові, а підстава звільнення обов’язкова: VATEX-EU-IC або відповідний текст (BR-IC-10).
Два поля, які в інших випадках необов’язкові, тут стають обов’язковими, і жодне з них не стосується сум — обидва стосуються постачання:
- Дата фактичного постачання (BT-72) або період (BG-14) не може бути порожньою (BR-IC-11).
- Країна постачання (BT-80) не може бути порожньою (BR-IC-12).
- Плюс номер ПДВ продавця і номер ПДВ покупця (BR-IC-02).
Саме тому такі рахунки відхиляють частіше за інші: хто вважає дані про постачання дрібницею, отримує файл, у якому все зійшлося до копійки, — і його однаково не приймуть. Де ці поля лежать у дереві, описано в структурі XML.
З податкового боку є ще те, чого не перевірить жоден валідатор: після «quick fixes» від 1 січня 2020 року чинний номер ПДВ покупця і вчасно подана зведена звітність — матеріальні умови звільнення, а не формальності. Бракує чогось одного — звільнення немає, навіть якщо товар доведено перетнув кордон. У Німеччині звіт подають до 25-го числа наступного місяця.
Звільнено (E) — і малий підприємець
E і Z плутають постійно. Z — це нульова ставка на товари, і вона не має права нести підставу звільнення (BR-Z-10). E — справжнє звільнення, і підстава для нього обов’язкова (BR-E-10). Хто закодує звільнену операцію як Z, отримає формально дійсний файл із хибним змістом: валідатор промовчить, податкова — ні.
Для малих підприємців за § 19 UStG нормою є саме E. Їхні обороти з 1 січня 2025 року прямо звільнені від податку (раніше податок просто «не стягувався»), з новими порогами: 25 000 € за попередній рік і 100 000 € у поточному, після перевищення яких режим змінюється негайно. У файлі це має вигляд:
- Код категорії E, ставка 0, сума податку 0.
- Як підстава — текст у BT-120 із посиланням на § 19 UStG. Коду VATEX для цього випадку не передбачено.
- Якщо номера ПДВ немає, підійде податковий номер: BR-E-02 приймає BT-31, BT-32 або BT-63.
Це посилання — не ввічливість, а обов’язковий реквізит за § 34a UStDV. Та сама норма звільняє малих підприємців від обов’язку виставляти структуровані рахунки взагалі: папір і звичайний PDF залишаються допустимими. Приймати електронні рахунки вони мусять усе одно — це стосується всіх із 1 січня 2025 року, див. терміни по країнах.
З 2025 року з’явився і транскордонний варіант: через особливу процедуру за § 19a UStG федеральне податкове відомство Німеччини видає ідентифікаційний номер малого підприємця із суфіксом «EX», з яким звільненням можна користуватися в інших державах ЄС — за обороту в межах Союзу не більше 100 000 €.
Перевірити номер ПДВ до того, як рахунок пішов
Формально норма перевіряє лише префікс: BR-CO-09 вимагає двох літер за ISO 3166-1 alpha-2. Якщо заглянути в самі правила, дозволений список ширший, ніж очікуєш, — окрім GR, там є EL для Греції та XI для Північної Ірландії. А от чи номер існує, на цьому етапі не перевіряє ніхто.
Для цього є два шляхи, і вони не рівноцінні:
- VIES, запит до Єврокомісії, відповідає на одне: чинний номер чи ні.
- Кваліфікований запит до федерального податкового відомства Німеччини (BZSt) за § 18e UStG додатково звіряє назву з організаційно-правовою формою, місто, поштовий індекс і вулицю з даними реєстру. Відповідь буває лише «збігається» або «не збігається», і перед нею обов’язково має пройти простий запит.
Різниця стає відчутною, коли хтось вимагає доказ: німецький роз’яснювальний акт з ПДВ у розділі 18e.1 (2) називає тим, що треба зберігати, саме результат BZSt — роздруківкою, файлом або записом, перенесеним у систему. Для знімка екрана з VIES такого припису немає. Хто перевіряє номери масово, користується інтерфейсом BZSt, а не формою на сайті.
На практиці це означає: перевіряти при заведенні клієнта, фіксувати дату й повторювати для давніх контрагентів — номери стають недійсними, і ніхто про це не попереджає.
Що найчастіше йде не так
| Помилка | Що повідомляє перевірка |
|---|---|
| Ставка 0 з E, AE, K, G чи O, але підстави звільнення немає | BR-E-10, BR-AE-10, BR-IC-10, BR-G-10, BR-O-10 |
| Підставу звільнення вписано до S або Z | BR-S-10, BR-Z-10 |
| Поставлено AE, але немає номера ПДВ покупця | BR-AE-02 |
| K без дати постачання і без країни постачання | BR-IC-11, BR-IC-12 |
| «Не об’єкт ПДВ» разом з іншими групами в одному рахунку | BR-O-11 — BR-O-14 |
| Сума податку в групі не округлена до двох знаків | BR-CO-17, BR-S-09 |
Округлення — окрема історія: чому одна копійка різниці зупиняє цілий рахунок, описано в бізнес-правилах.
Одна помилка не описана жодним правилом і все одно найнебезпечніша: на видимій сторінці показано ПДВ, а XML каже «зворотне нарахування». Лист німецького мінфіну від 15 жовтня 2025 року прямо каже, що в гібридних форматах вирішальною є структурована частина, а розбіжність ставить під загрозу податковий кредит. Перевірка тут мовчить, бо кожна частина окремо бездоганна.
Що тут уміє E-Rechnung Pro
Перевіряти: усе перелічене. Валідатор працює зі Schematron самої норми, тобто й із сімействами BR-AE-*, BR-IC-*, BR-E-*, BR-G-* та BR-O-*. Для вхідного рахунку зі зворотним нарахуванням чи постачанням у межах ЄС це найкоротший шлях до питання, чи чисто закодував постачальник.
Створювати: нульова ставка і звільнення. Якщо ставка ПДВ у рахунку — 0 %, форма питає, який це випадок: нульова ставка (Z), малий підприємець за § 19 UStG (E), зворотне нарахування (AE) чи внутрішньосоюзне постачання (K), — і ставить відповідний код категорії. Підставу звільнення для BT-120 пропонуємо мовою рахунка, її можна замінити своєю; для AE і K додається ще й відповідний код BT-121, а для режиму малого підприємця такого коду не передбачено. Те, чого випадок вимагає додатково, форма перевіряє до відправлення: для AE — ПДВ-номери обох сторін, для K ще й дату та країну постачання. На видимій стороні звільнення теж стоїть — напис за § 14a абз. 5 UStG або посилання на § 19 UStG друкується разом із ним.
Кілька випадків в одному рахунку: так. У нормі податкова група — це пара «код категорії + ставка»: 19 % і 7 % дають дві групи, S 19 % і AE 0 % — теж. Тому у формі кожна позиція несе власний випадок, і в одному рахунку можуть стояти поруч оподатковувані та звільнені рядки. Кожна група отримує в XML власну розбивку з власною базою, а кожне звільнення — власну підставу. На видимій стороні тоді з’являється колонка ПДВ у таблиці позицій і по рядку на групу в блоці підсумків: видима частина й XML кажуть те саме.
Часті питання
Чи досить написати «reverse charge» у тексті рахунку?
Ні. Для структурованої частини важить код AE з нульовою ставкою і підставою звільнення. Видимий напис при цьому теж залишається обов’язковим — обидва разом, а не одне замість іншого.
Яка різниця між Z і E?
Z — нульова ставка, підстави мати не може. E — звільнення, підстава обов’язкова. Для § 19 UStG і звільнень за § 4 UStG правильним є E.
Чи потрібен код VATEX для підстави звільнення?
Не обов’язково, вистачить тексту в BT-120. Для очевидних випадків є свої коди — VATEX-EU-AE, VATEX-EU-IC, VATEX-EU-G, VATEX-EU-O. Для режиму малого підприємця коду не передбачено.
Чи мусить малий підприємець із 2027 року виставляти електронні рахунки?
Ні, § 34a UStDV його звільняє; папір і PDF залишаються допустимими. А от приймати й зберігати структуровані рахунки він зобов’язаний із 1 січня 2025 року.
Мій рахунок у межах ЄС не проходить, хоча суми правильні. Чому?
Майже завжди через BR-IC-11 або BR-IC-12: бракує дати постачання чи періоду або країни постачання. Обидва поля обов’язкові лише за коду K, тому в інших випадках вони нікому не впадають в око.
Чи може рахунок містити кілька ставок?
Так. Кожна комбінація коду категорії та ставки утворює свою групу BG-23. EN 16931 робить це без розширень, профіль EXTENDED для цього не потрібен.
Чи досить запиту до VIES як доказу?
Щоб дізнатися, чи номер чинний, — так. Але в Німеччині доказом, який належить зберігати, роз’яснювальний акт називає результат кваліфікованого запиту до BZSt.
Коротко
- Категорія, ставка й підстава — три окремі дані; «0 %» саме по собі не пояснює нічого.
- AE вимагає обох номерів ПДВ і підстави; хибно показаний податок коштує справжніх грошей.
- K вимагає ще й дати чи періоду постачання та країни постачання — саме на цьому такі рахунки й падають.
- E замість Z для справжніх звільнень, із посиланням на § 19 UStG у BT-120.
- Номер ПДВ перевіряти заздалегідь, у Німеччині — кваліфікованим запитом до BZSt; його чинність з 2020 року є матеріальною умовою звільнення.
- Видима сторінка й XML мають казати те саме — за розбіжності вирішує XML.
Не впевнені, чи чисто закодований вхідний рахунок зі зворотним нарахуванням або постачанням у межах ЄС? Завантажте файл — ці сімейства правил працюють разом з усіма іншими.
