Бізнес-правила EN 16931: через що насправді відхиляють рахунки

XML рахунку може бути бездоганним за формою і при цьому хибним за змістом. Перевірка схеми контролює, чи кожен елемент стоїть там, де його очікує схема, і чи має він правильний тип даних; про те, чи сходяться суми, чи обґрунтоване звільнення від податку та чи взагалі можна впізнати продавця, вона не говорить нічого. Саме цю прогалину закривають бізнес-правила.

Вони — причина, з якої відхиляють більшість відхилених рахунків. Файл, що провалюється тут, бездоганно відкривається у переглядачі PDF, чисто розбирається як XML — і все одно не є дійсним рахунком за EN 16931.

Що таке бізнес-правило насправді

Кожне правило — це одне твердження про зміст рахунку, записане мовою Schematron і опубліковане поряд зі стандартом. Там, де схема каже «тут може стояти елемент», бізнес-правило каже приблизно так: сума з ПДВ має дорівнювати сумі без ПДВ плюс загальна сума податку. Якщо порахувати всі податкові категорії та типи документів, таких тверджень набирається кілька сотень.

Правила написані проти семантичної моделі, а не проти формату файлу, тому вони оперують діловими термінами — BT-112 для суми з ПДВ, BT-31 для податкового номера продавця — а не шляхами XML. Те саме правило однаково застосовне і до рахунку CII всередині файлу ZUGFeRD, і до рахунку UBL, надісланого через Peppol.

Родини правил

Префікс коду показує, з якого набору правило походить, і це перше, що треба з’ясувати, — бо не кожен набір стосується кожного файлу.

Не кожне правило стосується вашого файлу

Саме тут звіти валідатора читають неправильно найчастіше, і це коштує реального часу.

Конкретний приклад, який трапляється на кожному файлі: BR-DE-21 вимагає, щоб ідентифікатор специфікації (BT-24) був ідентифікатором XRechnung. Документ ZUGFeRD або Factur-X за визначенням оголошує там ідентифікатор ZUGFeRD, тож правило не може пройти ніколи — і його не можна рахувати як помилку. Наша панель перевірки позначає його як незастосовне до профілю та віднімає з числа спрацювань, а не лишає лякати користувача.

Профілі теж звужують набір правил. Файл MINIMUM або BASIC WL навмисно несе менше відомостей, ніж вимагає EN 16931, і його не міряють повним набором. Що входить до кожного профілю — у статті профілі Factur-X і ZUGFeRD.

Збої, які трапляються насправді

На практиці більшість відмов припадає на невелику кількість правил. Це ті, що виринають найчастіше, коли через валідатор проганяють справжні рахунки справжніх німецьких і французьких відправників.

Чому одна копійка валить рахунок

Найчастіший збій — арифметичний, і це майже ніколи не помилка в обчисленні. Це непослідовно застосоване округлення.

Якщо ціни за одиницю перемножити з повною точністю, додати й лише тоді округлити, підсумок подекуди відрізнятиметься на копійку від тих самих чисел, округлених позиційно. Бухгалтерськи обидва підходи можна захистити; збігається з тим, що переобчислює правило, тільки один. BR-CO-* байдуже, яку домовленість ви обрали, — воно вимагає лише, щоб числа всередині документа узгоджувалися між собою.

Три звички знімають майже все:

• Округлювати один раз, на визначеному кроці, і виводити кожен підсумок з округлених значень, а не з сирих.
• Не змішувати округлення на рівні одиниці й на рівні позиції в одному документі. Оберіть один спосіб і застосовуйте його всюди.
• Ніколи не підганяти підсумок вручну, щоб він зійшовся. Це лише переносить розбіжність далі — зазвичай у розбивку ПДВ.

Помилки й попередження — не те саме

Звіт змішує два рівні серйозності, і плутати їх означає марнувати зусилля в обидва боки. Фатальний висновок означає, що документ недійсний і його відхилять. Попередження позначає щось незвичне, але дозволене: рекомендоване поле лишили порожнім, значення законне, але рідко вживане, або правило з національної CIUS, яке до вашого документа не стосується.

Попередження варто прочитати один раз, бо отримувач може вимагати більше, ніж стандарт. Зводити їх до нуля не варто.

Виправляти причину, а не файл

Коли правило не проходить, повідомлення вказує на елемент у XML. Спокуса змінити саме його й перезапустити перевірку велика. Не робіть цього: у гібридному рахунку сторінка PDF і вбудований XML мають говорити одне й те саме, а XML, виправлений вручну, більше не відповідає сторінці поруч. Ця суперечність гірша за початкову помилку й помітно важче виявляється згодом.

Виправляйте дані в системі, яка створила рахунок, — номер платника ПДВ у профілі компанії, крок округлення в обліковій програмі, пропущену позицію — і формуйте документ заново. Повний порядок дій — у статті як перевірити рахунок.

Яким набором правил міряли ваш файл?

В одному прогоні перевірки сходяться три номери версій, і це різні речі:

• Версія формату. Factur-X 1.09.2 / ZUGFeRD 2.5.2, опублікована 4 серпня 2026 року й застосовна з 1 вересня 2026 року — це виправлення до версії 2.5 від червня 2026 року, яке підтягнуло узгодженість, округлення, розбивку ПДВ і правила перевірки, передусім у профілі EXTENDED.
• Версія набору правил. Артефакти Schematron версіонуються окремо — EN 16931 Schematron v1.3.16 відповідає виправленій версії 2.5.2.
• Версія валідатора. Незалежна від обох. Mustang, відкритий валідатор, на якому тримається більша частина галузі, має версію 2.26.0.

Одне уточнення, яке роблять рідко: сам семантичний стандарт переглянуто. CEN схвалив EN 16931-1:2026 у лютому 2026 року й опублікував у травні 2026-го, відкликавши редакцію 2017 року. Інструменти за цим ще не пішли — чинні набори Schematron досі кодують семантику 2017 року, а підтримки нової редакції очікують із випуском, запланованим на осінь 2026 року. Того, хто сьогодні заявляє, що перевіряє проти редакції 2026 року, варто спитати, що саме він має на увазі.

Довідник кодів: правила поодинці

Далі кожне правило розглянуто окремо: що воно перевіряє, через що падає на практиці і що саме треба змінити. У кожного запису власний якір — #BR-CO-15, наприклад, веде просто на потрібне місце: код зі свого звіту можна дописати до адреси цієї сторінки.

Усі суми в прикладах узято з одного рахунку, щоб розрахунки складалися один в одного:

Суми і округлення

Ця родина дає найбільше відмов, і майже завжди йдеться про копійку. Правила утворюють ланцюг: BT-106 → BT-109 → BT-110 → BT-112 → BT-115. Щойно рветься одна ланка, наступні правила теж по черзі повідомляють про помилку — лагодьте перше, а не всі.

BR-CO-10 — сума позицій

Сума чистих сум позицій (BT-106) = Σ чиста сума позиції (BT-131).

У прикладі BT-106 має дорівнювати рівно 747,00 + 120,50 = 867,50. Падає здебільшого тому, що сума позиції з кількості × ціни виходить більш ніж на два знаки, а програма округлює лише підсумок: 3 × 82,99 — це 248,97, а не 249,00. Округлюйте кожну позицію окремо й лише потім складайте, ніколи не навпаки.

BR-CO-13 — разом без податку

Разом без ПДВ (BT-109) = Σ чисті суми позицій (BT-131) − знижки на рівні документа (BT-107) + доплати на рівні документа (BT-108).

867,50 − 17,50 + 0,00 = 850,00. Найчастіша причина: знижку вже враховано в цінах позицій і додатково показано знижкою на рівні документа — вона віднімається двічі. Знижка належить або до позицій, або до рівня документа, але не до обох одразу.

BR-CO-14 — разом податку

Загальна сума ПДВ (BT-110) = Σ сума податку за категорією (BT-117).

За однієї ставки це тривіально. Помилки починаються, щойно ставок дві: 19 % і 7 % дають два рядки в розбивці ПДВ, і BT-110 має бути сумою обох — не сумою більшого рядка й не податком на загальний підсумок.

BR-CO-15 — разом із податком

Разом із ПДВ (BT-112) = разом без ПДВ (BT-109) + загальна сума ПДВ (BT-110).

850,00 + 161,50 = 1011,50. Це код, який трапляється найчастіше, і за ним майже ніколи не стоїть помилка в арифметиці — стоїть округлення: програма всередині рахує 849,995, пише в XML 850,00, а податок бере з неокругленого значення. Копійка різниці — і рахунок недійсний. Те, що записано в XML, має бути й основою самого рахунку.

BR-CO-16 — сума до сплати

До сплати (BT-115) = разом із ПДВ (BT-112) − уже сплачено (BT-113) + сума округлення (BT-114).

1011,50 − 200,00 = 811,50. Типова помилка в рахунках з авансом: аванс стоїть у вільному тексті умов оплати замість BT-113, і сума до сплати тоді не сходиться ні з чим. Те, що отримувач має переказати, живе в полі, а не в реченні.

BR-CO-17 — податок за категорією

Сума податку за категорією (BT-117) = база (BT-116) × ставка (BT-119) / 100, округлено до двох знаків.

850,00 × 19 / 100 = 161,50. Округлення — частина правила: звичайне округлення до двох знаків, а не відкидання. Хто зріже 161,495 до 161,49, не пройде.

BR-DEC-* — не більше двох знаків після коми

Наприклад, BR-DEC-12 для суми без ПДВ (BT-109), BR-DEC-14 для суми з ПДВ (BT-112), BR-DEC-19 для бази оподаткування (BT-116).

Понад двадцять правил цієї родини кажуть те саме, кожне про своє грошове поле: більш ніж два знаки після коми неприпустимі. Достатньо одного 850.0000 з вивантаження бази. Не плутати з полями кількості й ціни, де більше знаків дозволено, — саме тому це зачіпає переважно підсумкові поля.

ПДВ за категоріями

Кожна позиція має код категорії ПДВ, і в кожного такого коду — власна родина правил. Тож родина, яку ви бачите у звіті, вже каже, якою категорією позначено: S звичайна ставка, Z нульова, E звільнено, AE зворотне нарахування, K постачання в межах ЄС, G експорт, O поза сферою оподаткування.

BR-S-01 — категорії немає в розбивці

Якщо рахунок містить позицію, знижку чи доплату з категорією «Standard rated», у розбивці ПДВ має бути щонайменше один рядок із тією самою категорією.

Позиція каже «19 %», а розбивка ПДВ у шапці рахунку такої категорії не знає. Регулярно виникає, коли позицію додали пізніше, а розбивку не перерахували. Те саме правило є в кожній родині: BR-Z-01, BR-E-01, BR-AE-01 і далі.

BR-S-02 — немає податкового номера за звичайної ставки

Рахунок із позицією категорії «Standard rated» має містити ПДВ-номер продавця (BT-31), його податковий номер (BT-32) та/або номер податкового представника (BT-63).

Хто нараховує податок, має сказати, за яким номером. Часто трапляється в малих підприємців, які помилково беруть звичайну ставку замість категорії E — тоді рахунок хибний не лише формально, а й податково.

BR-S-08 — база за кожною ставкою

Для кожної ставки: база (BT-116) = Σ чисті суми позицій із цією ставкою + доплати − знижки з цією ставкою.

Класичний випадок із двома ставками: знижку на рівні документа повністю віднесли до рядка 19 %, хоча її треба було розподілити пропорційно між 19 % і 7 %. Знижка на рівні документа сама має категорію — її треба проставити, а за змішаних ставок ще й розподілити.

BR-S-09 — податок за кожною ставкою

Сума податку рядка розбивки (BT-117) має дорівнювати базі (BT-116), помноженій на ставку (BT-119).

Майже те саме, що BR-CO-17, але про окремий рядок. Бачите обидва — помилка саме в цьому рядку.

BR-Z-01 і BR-Z-08 — нульова ставка

Рівно один рядок «Zero rated», і його база має дорівнювати сумі позицій із нульовою ставкою.

Нульова ставка означає: оподатковується за 0 %. Не плутати зі звільненням (E) і не плутати з «поза сферою» (O). Саме ця плутанина — головна причина, з якої ця родина взагалі з'являється у звіті.

BR-E-10 — звільнення без підстави

Рядок «Exempt from VAT» має містити підставу звільнення — кодом (BT-121) або текстом (BT-120).

Виставляти рахунок без податку можна, але треба написати, чому. Порожнє поле не годиться, і риска теж. Для тих, хто звільнений за національними правилами, тут має стояти відповідна згадка.

BR-AE-10 — зворотне нарахування без застереження

Рядок «Reverse charge» має містити підставу, яка означає зворотне нарахування, — кодом (BT-121) або текстом (BT-120).

Згадка про перехід обов'язку сплатити податок до отримувача — не ввічливість, а обов'язковий реквізит. Її можна написати своєю мовою, але вона має бути. Якщо додатково бракує ПДВ-номера покупця, ви побачите ще BR-AE-02 або BR-AE-03.

BR-AE-08 і BR-E-08 — база за нульового податку

Навіть без податку база рядка має дорівнювати сумі відповідних позицій.

Сума податку тут 0,00 — база ні. Хто ставить нулі в обидва поля, не проходить: сума позицій іде в BT-116 без змін.

BR-IC-11 — постачання в межах ЄС без дати

За категорії «Intra-community supply» не можуть бути порожніми ні фактична дата постачання (BT-72), ні період виставлення (BG-14).

За звільненого постачання до іншої країни ЄС отримувач має знати, коли відбулося постачання, — дати рахунку замало. Достатньо одного з двох полів.

BR-O-11 — «поза сферою» ні з чим не поєднується

Рахунок, що містить рядок розбивки «Not subject to VAT», не повинен містити жодного іншого рядка розбивки.

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

Обов'язкові реквізити

Ці правила ловлять файли, у яких просто чогось бракує. Вони рідкісні, коли рахунок виходить із програми, і часті, коли XML писали руками або за шаблоном.

BR-01 — ідентифікатор специфікації

Рахунок повинен мати Specification identifier (BT-24).

Це рядок, який каже, за яким профілем зібрано файл, — наприклад urn:cen.eu:en16931:2017. Без нього валідатор не знає, проти чого перевіряти, а отримувач — що саме йому надіслали. На практиці бракує лише в написаному руками XML.

BR-02 — BR-05 — номер, дата, тип, валюта

Номер рахунку (BT-1), дата виставлення (BT-2), код типу рахунку (BT-3) і код валюти (BT-5) мають бути присутні.

Чотири окремі правила на чотири поля шапки. Тип — це код зі списку UNTDID 1001: 380 для звичайного рахунку, 381 для кредит-ноти; вільний текст у цьому місці додатково спричиняє повідомлення BR-CL-*.

BR-06 — BR-09 — продавець і покупець

Назва продавця (BT-27), назва покупця (BT-44), поштова адреса продавця (BG-5) і код країни в ній (BT-40).

BR-09 — найчастіше з цих чотирьох: вулицю й місто заповнено, код країни ні. Це має бути дволітерний код за ISO 3166-1 — DE, а не Deutschland.

BR-16 — жодної позиції

Рахунок повинен мати щонайменше одну позицію (BG-25).

Виникає, коли рахунок складається з самих підсумків, — наприклад у файлі, зробленому з PDF, у якому не розпізналася таблиця позицій. Одна збірна позиція на всю суму краща, ніж жодної.

BR-CO-09 — префікс країни в ПДВ-номері

ПДВ-номер продавця (BT-31), податкового представника (BT-63) і покупця (BT-48) мають починатися з коду країни за ISO 3166-1 alpha-2. Греція додатково може вживати EL.

123456789 перетворюється на DE123456789. Найпоширеніший випадок: номер лежить у довіднику без префікса, бо його так ведуть роками. Пробілам і крапкам там теж не місце.

BR-CO-26 — продавця неможливо розпізнати

Щоб покупець міг автоматично розпізнати постачальника, має бути присутній ідентифікатор продавця (BT-29), його реєстраційний номер (BT-30) та/або ПДВ-номер (BT-31).

Щонайменше одне з трьох, не всі. Найчастіший збудник на конвертованих чужих рахунках: у PDF стоїть національний податковий номер у форматі, який не є ПДВ-номером, тож він не потрапляє в жодне з трьох полів. Тоді краще заповнити реєстраційний номер, ніж лишити всі три порожніми.

Німецька надбудова (BR-DE-*)

Правила BR-DE-* походять не з самої EN 16931, а з XRechnung — німецької редакції. Вони вимагають реквізитів, які норма лишає необов'язковими. Важливо для читання звіту: рахунок ZUGFeRD, який і не мав бути XRechnung, виконувати їх не зобов'язаний — валідатор усе одно їх покаже, бо прикладає всі відомі йому набори правил.

BR-DE-1 — немає платіжних реквізитів

Рахунок повинен містити PAYMENT INSTRUCTIONS (BG-16).

Немає способу оплати — немає XRechnung. Для переказу це IBAN і код способу оплати; для прямого дебету чи готівки — відповідний код.

BR-DE-2, BR-DE-5 — BR-DE-7 — контактні дані

Групу SELLER CONTACT (BG-6) має бути передано, а в ній — контактну особу (BT-41), телефон (BT-42) і адресу електронної пошти (BT-43).

Чотири правила, один блок. Загальна адреса на кшталт rechnung@… годиться, назва відділу теж — важливо, щоб було заповнено. Якщо блоку немає взагалі, всі чотири повідомлення з'являться разом.

BR-DE-14 — немає ставки податку

Елемент VAT category rate (BT-119) має бути переданий.

EN 16931 дозволяє не зазначати ставку для окремих категорій, XRechnung — ні. Для звільнених позицій треба явно поставити 0, а не лишати порожнім.

BR-DE-15 — немає посилання покупця

Елемент Buyer reference (BT-10) має бути переданий.

У роботі з німецькими держорганами це Leitweg-ID — ідентифікатор маршрутизації, за яким портал приймання розуміє, якій установі призначено рахунок. Він є в замовленні або в договорі; вигадати його не можна, і без нього рахунок не буде доставлено. У суто приватному обігу згодиться будь-яке посилання покупця.

BR-DE-16 — податкова ідентифікація майже для всіх категорій

Якщо вжито податкові коди S, Z, E, AE, K, G, L або M, має бути переданий щонайменше один з елементів: ПДВ-номер продавця (BT-31), податковий номер (BT-32) або SELLER TAX REPRESENTATIVE PARTY (BG-11).

Німецьке посилення BR-S-02: правило діє не лише для звичайної ставки, а практично для кожної категорії.

BR-DE-17 — неприпустимий тип рахунку

Для Invoice type code (BT-3) дозволено лише 326 (частковий рахунок), 380 (рахунок), 384 (виправлений рахунок), 389 (самовиставлення) і 381 (кредит-нота).

Список UNTDID містить десятки значень, XRechnung дозволяє п'ять. Позначити проформу кодом 325 — і правило падає.

BR-DE-18 — знижка за дострокову оплату не в тому форматі

Знижка за дострокову оплату має відповідати сталому взірцю всередині Payment terms (BT-20): #SKONTO#TAGE=n#PROZENT=n.nn#.

Єдине правило, яке нав'язує синтаксис полю з вільним текстом. «2 % знижки за оплату протягом 14 днів» читається чудово й усе одно недійсне — отримувач має вміти обробити це машинно.

BR-DE-19 — неправдоподібний IBAN

Якщо способом оплати зазначено переказ SEPA (код 58), Payment account identifier (BT-84) має містити коректний IBAN.

Перевіряються довжина, код країни й контрольні цифри. На практиці найчастіше падає через пробіли: DE89 3704 0044 0532 0130 00 правильний для людини й неправильний для перевірки — у XML IBAN має бути без розділювачів. BR-DE-20 каже те саме про прямий дебет (код 59).

BR-DE-21 — повідомлення, яке бачать майже всі

Елемент Specification identifier (BT-24) має синтаксично відповідати ідентифікатору стандарту XRechnung.

Це повідомлення з'являється на кожному дійсному рахунку ZUGFeRD і Factur-X, і там воно не є помилкою. Воно просто каже: «це не XRechnung». Так і є — і саме цього ви й хочете, коли виставляєте ZUGFeRD. Відніміть це одне повідомлення, перш ніж оцінювати свій звіт; у нашому звіті ми вже робимо це за вас.

BR-DE-26 — виправлення без посилання

Якщо вжито тип рахунку 384 (виправлений рахунок), має бути присутнє щонайменше одне PRECEDING INVOICE REFERENCE (BG-3).

Виправлення, яке не каже, що саме воно виправляє, неможливо зіставити. Номер і дата початкового рахунку належать до BG-3, а не до вільного тексту.

Прочитати власний звіт

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