ПДВ в електронному рахунку: категорії та зворотне нарахування

Ставка 0 % в XML не пояснює нічого. Норма хоче категорію, ставку і підставу — три окремі поля.

ПДВ — та частина електронного рахунку, на якій завалюється більшість файлів, і майже ніколи не через хибну суму. Завалюються тому, що «0 %» у структурованій частині нічого не пояснює: норма хоче знати яка категорія, яка ставка і, якщо податку немає, чому саме.

Це орієнтир, а не податкова консультація. Чи підпадає операція під зворотне нарахування, чи є вона звільненою, чи взагалі не є об’єктом ПДВ — вирішує конкретний випадок. Тут ідеться про наступне питання: як те, що встановив ваш бухгалтер, правильно показати у файлі?

Три поля, а не одне

У рахунку за EN 16931 ПДВ живе у трьох місцях, і їх постійно плутають:

ДаніУ позиціїУ зведенні (BG-23)
Код категоріїBT-151BT-118
Ставка у відсоткахBT-152BT-119
Підстава звільнення—BT-120 (текст) або BT-121 (код)

Код категорії — це не ставка. Нульова ставка може означати: звільнено, зворотне нарахування, постачання в межах ЄС, експорт або взагалі не об’єкт ПДВ — п’ять різних ситуацій із п’ятьма різними кодами й різними обов’язковими полями. Тому написати «без податку» в тексті рахунку й поставити ставку 0 недостатньо.

Крім того, кожна комбінація коду і ставки утворює власну групу BG-23. Кілька ставок в одному рахунку — не виняток, і профіль EXTENDED для цього не потрібен: це вміє вже EN 16931.

Коди категорій одним поглядом

Сім кодів категорій один під одним — S, Z, E, AE, K, G, O — і те, чого кожен із них додатково вимагає в XML
Код вирішує, які ще поля стають обов’язковими. Саме тому відхиляють файли, у яких з арифметикою все гаразд.

Усього норма знає дев’ять кодів. Сім із них вище; ще є 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 або ZBR-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.

Не впевнені, чи чисто закодований вхідний рахунок зі зворотним нарахуванням або постачанням у межах ЄС? Завантажте файл — ці сімейства правил працюють разом з усіма іншими.