Відкрийте гібридний рахунок у будь-якому переглядачі PDF — і побачите звичайний документ: шапку, позиції, підсумок. Про дійсність файлу цей вигляд не говорить нічого. Для бухгалтерської програми одержувача важить XML, захований усередині, і те, як саме його прикріплено до PDF.
Це найчастіша несподіванка для тих, хто стикається з форматом уперше. PDF, який роздрукували у файл, а потім «прикріпили» до нього XML у редакторі, на екрані не відрізнити від справжнього рахунку ZUGFeRD — і він не проходить перевірку одразу. Саме цю різницю й ловить валідація: між «виглядає правильно» і «є правильним».
Шар 1 — чи це справді PDF/A-3?
Гібридний рахунок — не просто PDF із вкладенням. Це має бути дійсний файл PDF/A-3 — архівний різновид PDF, розрахований на десятиліття читабельності, — а XML рахунку має бути вбудований цілком певним чином.
На цьому шарі перевіряють, зокрема:
- Відповідність PDF/A-3 — структурні вимоги самого архівного формату.
- Вбудовані шрифти. PDF/A забороняє покладатися на шрифти, встановлені на машині читача: усе потрібне для відображення має лежати у файлі.
- Кольорові профілі, оголошені явно, а не припущені.
- Метадані XMP — машиночитний блок, що описує файл, разом із зазначенням стандарту та профілю, якому він заявляє відповідність.
- Тип зв’язку вкладення. Вбудований XML має нести правильний зв’язок (
AFRelationship) і очікуване ім’я файлу, щоб програма впізнала в ньому дані рахунку, а не довільне вкладення.
Інструменти в цій галузі зазвичай використовують для цього шару veraPDF — відкритий валідатор PDF/A. Файл, що не пройшов тут, не є дійсним електронним рахунком, хоч яким би добрим був його XML.
Шар 2 — чи XML коректний за схемою?
Вбудовані дані використовують синтаксис Cross Industry Invoice (CII) від UN/CEFACT — модель даних, описану в нашій статті про структуру XML.
Цей шар розбирає XML і звіряє його зі схемою (XSD): кожен елемент там, де схема його очікує, правильні типи даних, обов’язкові елементи присутні, значення у правильному форматі. Дата, записана як 31.12.2026 там, де схема чекає 20261231, не пройде саме тут.
Перевірка за схемою сувора до форми і цілком сліпа до змісту. Рахунок може бездоганно відповідати схемі й водночас показувати суму ПДВ, яка не збігається з його ж позиціями. Для цього існує третій шар.
Шар 3 — бізнес-правила
Найсуворіший і найцікавіший шар перевіряє бізнес-правила Schematron: кілька сотень змістових тверджень, визначених поряд зі стандартом EN 16931, які перевіряють, чи внутрішньо узгоджений і повний зміст рахунку.
Це ті правила, що ловлять проблеми, через які рахунки справді відхиляють:
- розбивка ПДВ, яка не сходиться із заявленою сумою документа;
- категорія ПДВ, що вимагає підстави звільнення там, де її не вказано;
- відсутнє посилання покупця в рахунку до державної установи;
- валюта, вказана в одному місці й неявно інша в іншому.
Правила згруповані в родини, і префікс каже, звідки правило походить:
| Префікс | Походження | Що перевіряє |
|---|---|---|
BR-* | EN 16931, ядро | наявність і кількість обов’язкових відомостей |
BR-CO-* | EN 16931, ядро | узгодженість і арифметику між пов’язаними полями |
BR-CL-* | EN 16931, кодові списки | значення має походити з дозволеного кодового списку |
BR-S-*, BR-Z-*, BR-E-*, BR-AE-*, BR-G-*, BR-O-*, BR-IC-* | EN 16931 | правила за категорією ПДВ — звичайна ставка, нульова, звільнення, зворотне нарахування, експорт, поза сферою, внутрішньосоюзні |
BR-DE-* | XRechnung (німецька CIUS) | додаткові німецькі вимоги |
PEPPOL-EN16931-R* | Peppol BIS Billing | додаткові правила для надсилання мережею Peppol |
Що саме перевіряють родини ядра — у статті про бізнес-правила EN 16931.
Не кожне правило стосується кожного файлу
Саме тут звіти перевірки читають неправильно найчастіше. Набір правил залежить від того, чим файл себе оголошує.
Файл ZUGFeRD у профілі EN 16931 перевіряють за правилами ядра EN 16931. Родина BR-DE-* належить до XRechnung — німецької національної адаптації (CIUS) стандарту. Ці правила діють тоді, коли документ є XRechnung, а не для будь-якого рахунку. Тому цілком дійсний рахунок ZUGFeRD може показувати зауваження BR-DE-*, які до нього просто не стосуються, і сприймати їх як помилки означає «лагодити» файли, що ніколи не були зламані.
Те саме з профілями: файл у профілі MINIMUM або BASIC WL свідомо несе менше відомостей, ніж вимагає EN 16931, тож його й не міряють повним набором правил. Що містить кожен профіль — у статті про профілі ZUGFeRD і Factur-X.
Як читати повідомлення валідатора
Повідомлення зазвичай несе три корисні частини:
- Код правила — наприклад
BR-CO-15. Це найшвидший спосіб дізнатися, що саме перевірялося, і саме його шукають, коли застрягли. - Рівень — жорстка помилка, що робить документ недійсним, або попередження про щось сумнівне, але дозволене.
- Місце, зазвичай як XPath у XML, що вказує на елемент, який не пройшов.
Місце каже де, код каже чому. Виправляйте причину в тій системі, що створила рахунок, а не правте XML руками: рахунок із підправленим вручну XML більше не відповідає сторінці PDF поруч, і ця розбіжність гірша за початкову помилку.
Чого перевірка не показує
Валідація — це перевірка відповідності, а не аудит, і про її межі варто говорити точно:
- Вона не підтверджує правильність. Файл може пройти кожне правило й усе одно показувати не ту ціну, не того клієнта чи не ту дату. Перевіряється внутрішня узгодженість, а не істинність.
- Вона не гарантує прийняття. Одержувач може висунути власні вимоги — номер замовлення, певне посилання, конкретний профіль.
- Вона не замінює податкової консультації. Чи відповідає рахунок податковому праву конкретної країни — питання, відмінне від відповідності EN 16931.
Три номери версій, і вони не про одне й те саме
В одному прогоні перевірки зустрічаються три різні версії, і плутати їх — значить наживати зайві суперечки:
- Версія формату. Чинна — ZUGFeRD 2.5.2 / Factur-X 1.09.2, опублікована 4 серпня 2026 року й застосовна з 1 вересня 2026 року. Це corrigendum до версії 2.5 від червня 2026: виправлено узгодженість, округлення, розбивку ПДВ і правила перевірки — переважно у профілі EXTENDED — та оновлено артефакти XSD і Schematron. Версії 3.0 не існує; див. версії ZUGFeRD.
- Версія валідатора. Mustang, відкритий валідатор, на який спирається більша частина галузі, розвивається у власній лінійці 2.x — наразі 2.26.0, випущена 25 серпня 2026 року. Її номер не має нічого спільного з версією формату. Див. проєкт Mustang.
- Версія набору правил. Артефакти Schematron версіонуються ще окремо — EN 16931 Schematron v1.3.16 відповідає виправленому випуску 2.5.2.
І ще одне варто сказати прямо: сам семантичний стандарт переглянули. CEN схвалив EN 16931-1:2026 у лютому 2026 року й опублікував у травні 2026-го, відкликавши редакцію 2017 року. На практиці інструменти ще не наздогнали — ZUGFeRD 2.5.2 і чинні набори Schematron досі побудовані на семантиці 2017 року, а підтримки нової редакції очікують із випуском ZUGFeRD восени 2026-го. Того, хто сьогодні стверджує, що перевіряє за редакцією 2026 року, варто перепитати, що саме він має на увазі.
Що відбувається після натискання «Перевірити»
Перевірка — це не погляд у таблицю, а прохід крізь описані вище шари, тому вона триває секунди, а не мілісекунди. На практиці це означає:
- Два етапи один за одним. Спершу контейнер (чи це справді PDF/A-3 із вкладенням), потім XML проти схеми та бізнес-правил. Вердикт складається з обох: дійсний PDF/A з хибним XML не є дійсним електронним рахунком.
- Чесний поступ замість кола, що крутиться. Видно, який саме етап іде, — на великому файлі це різниця між «працює» і «зависло».
- Перевірки йдуть через чергу. Важкий файл не блокує решту кабінету, а кілька перевірок поспіль не заважають одна одній.
- Результат лишається, файл — ні. Звіт потім лежить у «Документах», а завантажений файл невдовзі видаляється з сервера — див. зберігання: архів ведете ви самі.
Перевірка отриманого рахунку
З 1 січня 2025 року кожне підприємство в Німеччині зобов’язане вміти приймати структуровані рахунки; виставляти їх обов’язково з 1 січня 2027 року для компаній з оборотом понад 800 000 євро за попередній рік і з 1 січня 2028 року для решти. Отримати файл просто — корисна частина в тому, щоб зрозуміти, чи те, що прийшло, у порядку.
Чотири речі варто перевірити у вхідному рахунку:
- Чи XML відповідає сторінці? У гібридному файлі в облік іде саме вбудоване, і воно може відрізнятися від того, що показує PDF. Де вони розходяться, це треба з’ясувати до того, як документ потрапить у книги.
- Чи проходить він перевірку? Усі три шари, включно з контейнером.
- Чи правдоподібні податкові відомості? Ідентифікатор ПДВ, категорія і ставка — або вказана підстава там, де податок не нараховано.
- Чи це не дублікат? Структуровані дані роблять повтори помітно легшими для виявлення, ніж будь-коли дозволяв сканований папір.
Перевірка перед надсиланням
Найдешевший момент знайти проблему — раніше за клієнта. Відхилений рахунок коштує платіжного циклу, прогін перевірки — кількох секунд. Як це робити зі своїми документами, описано в статті як перевірити рахунок.