EN 16931 — це не файл і не формат. Це перелік того, що має нести рахунок, аби машина змогла його обробити, плюс набір правил, які перевіряють, чи все в результаті сходиться. Усе, що можна взяти в руки, — ZUGFeRD, Factur-X, XRechnung, Peppol — це втілення того самого переліку.
Написав його CEN, Європейський комітет зі стандартизації, у відповідь на директиву 2014/55/ЄС. Завдання було вузьким: державні органи по всій Європі мали приймати рахунки за одними правилами, а не кожна країна за своїми.
Що описує модель
Норма називає зміст кожного реквізиту й лишає відкритим написання. «Назва продавця» — це BT-27, «позиція рахунку» — BG-25, у будь-якому синтаксисі й у будь-якій країні. Які поля існують і де вони опиняються у файлі — у статті Будова XML.
Охоплено: ідентифікація та податкові номери продавця й покупця, номер і дати рахунку, позиції з кількістю, одиницею та ціною, знижки й надбавки, категорії та суми податку, умови оплати й підсумки — і до кожного питання, коли реквізит обов’язковий, а коли ні.
Два синтаксиси, один зміст
Модель проєктується на два синтаксиси XML, і обидва рівноцінно дійсні:
- CII (Cross Industry Invoice, від UN/CEFACT) — синтаксис, який використовують виключно ZUGFeRD і Factur-X.
- UBL (Universal Business Language, від OASIS) — поширений у мережі Peppol.
Вони описують ті самі речі різними іменами елементів. Перетворення між ними можливе на рівні зіставлення полів без втрати змісту; хто працює в обох світах, наливає ті самі дані в ту чи іншу форму.
Для більшості компаній це подробиця впровадження. Важить одне: щоб канал, яким ви надсилаєте, підтримував синтаксис, на який чекає одержувач. Його задає канал, а не якість даних.
CIUS і розширення: як країни підганяють норму
Сама по собі норма лишає багато свободи. Тому країни, галузі та мережі звужують її через CIUS — Core Invoice Usage Specification. CIUS може:
- зробити обов’язковими поля, які норма лишає на вибір;
- скоротити довідники значень;
- додати правила перевірки.
Чого вона не може — вигадати нові поля. Кому це потрібно, будує розширення, і саме цю різницю видно в ідентифікаторі профілю: #compliant# означає CIUS, #conformant# — розширення (див. Профілі).
До CIUS належать німецька XRechnung, Peppol BIS Billing 3.0 і профіль ZUGFeRD BASIC. А профіль EXTENDED — це розширення. Звідси й національні коди правил, що з’являються у звітах поряд із європейськими: BR-DE-* для Німеччини, BR-FR-* для Франції.
Як перевіряють відповідність
Відповідність не означає, що файл відкривається. Перевірка йде на двох рівнях:
- Схема (XSD) — чи коректно сформовано XML, чи кожен елемент на своєму місці, чи має кожне значення правильний тип. Цей рівень суворий до форми і сліпий до змісту.
- Бізнес-правила (Schematron) — чи сходяться підсумки, чи має кожна категорія податку допустиму для неї ставку, чи ідентифікований продавець. Саме тут виникає більшість справжніх відмов.
Для гібридних файлів перед цим іде третій рівень — контейнер PDF/A-3. Як усі три поєднуються, описано у статті Як працює перевірка; родини правил і коди, що справді трапляються, — у статті Бізнес-правила.
Перевірити файл у нас можна без реєстрації — проти схеми та бізнес-правил, за набором того профілю, який файл сам і оголошує.
Редакція 2026 року
Редакцію 2017 року писали під державні закупівлі. Для B2B і для цифрової звітності з ПДВ у межах ViDA її не вистачає, тож CEN переробив модель.
| Крок | Коли |
|---|---|
| CEN ухвалює редакцію (одностайно, 17 держав) | 13 лютого 2026 |
| Остаточний текст | 18 березня 2026 |
| Публікація як EN 16931-1:2026; редакцію 2017 відкликано | травень 2026 |
| Обов’язкова для внутрішньосоюзних B2B-операцій | 1 липня 2030 |
Додане явно цілить у податкові органи й у торгові випадки, яких бракувало 2017 року:
- банківські реквізити стають обов’язковими (IBAN окремим полем) — щоб платіжний потік за рахунком був простежуваним;
- позначка спрощення тристоронньої операції, де вона застосовна;
- послідовна нумерація коригувальних рахунків;
- більше торгівлі: кілька замовлень на один рахунок, знижки за дострокову оплату, пеня за прострочення, дані про іноземні валюти;
- більше податкових випадків: ширший перелік звільнених операцій і національні особливі режими на кшталт оподаткування маржі;
- позначка «товар/послуга» та час виставлення рахунку.
Редакція не має зворотної сумісності. Нові бізнес-терміни, змінені правила перевірки та оновлені прив’язки до CII і UBL означають, що наявне впровадження не підхопить нові документи просто так. Саме тому між публікацією та обов’язком лежать чотири роки.
Чому перевірка досі йде проти редакції 2017 року
Заперечення справедливе: якщо редакцію 2017 відкликано, чому в кожному файлі ZUGFeRD і далі стоїть urn:cen.eu:en16931:2017, і чому валідатори перевіряють проти неї?
Бо норма й формати, які її втілюють, рухаються не в один такт. ZUGFeRD 2.5.2 і Factur-X 1.09.2 — редакції, чинні з 1 вересня 2026 року, — спираються на модель 2017 року. Файл за моделлю 2026 року сьогодні не зміг би прийняти ніхто: відповідних схем і правил у форматах іще немає. Редакція дійде до вас тоді, коли FeRD і FNFE-MPE візьмуть її у випуск; наступного випуску ZUGFeRD очікують восени 2026 року.
На практиці: перевіряйте далі проти чинного. І закладіть додаткові поля до того, як формати переключаться, — передусім банківські реквізити, які в багатьох шаблонах рахунків досі є лише рядком тексту в підвалі, а не полем.
Часті питання
EN 16931 — це формат файлу?
Ні. Це модель даних із правилами. Формати — це ZUGFeRD, Factur-X, XRechnung і Peppol BIS; вони втілюють модель.
CII кращий за UBL?
Ні, це два написання того самого змісту. Який потрібен вам — вирішує одержувач, точніше мережа, якою він приймає.
Чим CIUS відрізняється від розширення?
CIUS звужує норму — більше обов’язкових полів, коротші довідники, додаткові правила, але жодних нових полів. Розширення додає поля, яких норма не знає. В ідентифікаторі профілю це видно як #compliant# проти #conformant#.
Чи треба щось робити вже зараз через EN 16931-1:2026?
Виставляйте й перевіряйте як досі: формати ще спираються на редакцію 2017. Що можна підготувати — охайно внести до довідників ті дані, що стануть обов’язковими, насамперед IBAN.
Чи діє норма поза ЄС?
Обов’язковою її робить право ЄС. Поза ним вона використовується як модель, бо вона найпоширеніша: одержувач із третьої країни може прийняти рахунок за EN 16931, але не зобов’язаний.
Чому мій рахунок не проходить, хоча всі поля заповнені?
Бо другий рівень перевіряє не наявність, а узгодженість: підсумки, категорії податку, округлення. Найчастіші коди та їхні причини — у статті Бізнес-правила.
Що означає ViDA для норми?
ViDA — причина редакції: якщо ПДВ має декларуватися цифрово, рахунок мусить нести потрібні для цього дані в структурованому вигляді. Тому редакція 2026 року росте передусім у податкових полях.
Стисло
- EN 16931 — модель змісту, а не формат. Формати — це її втілення.
- Два синтаксиси: CII (ZUGFeRD, Factur-X) і UBL (Peppol). Рівноцінні, перетворювані один в одного.
- CIUS звужує, розширення додає — і те, й те видно в ідентифікаторі профілю.
- Перевірка йде на двох рівнях: схема і бізнес-правила. Відмовляє другий.
- EN 16931-1:2026 опублікована, зворотної сумісності не має, обов’язкова для внутрішньосоюзного B2B з 1 липня 2030 року.
- У форматах сьогодні досі редакція 2017 — нова прийде з їхніми наступними випусками.
Перевірити рахунок проти чинних правил? Завантажте його без реєстрації — або заведіть безкоштовний обліковий запис і створюйте відповідні документи одразу правильно.