Як перевірити рахунок ZUGFeRD або Factur-X

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

Ця сторінка описує практичний порядок дій: який файл завантажувати, з чого складається звіт, як читати справжній звіт рядок за рядком і що робити, коли щось позначено як помилка. Що саме відбувається всередині кожної перевірки — у статті Як влаштована перевірка.

Що саме у вас у руках?

Три різні речі називають «електронним рахунком», і перевірити можна лише дві з них.

• Гібридний PDF — файл ZUGFeRD або Factur-X: цілком звичайна на вигляд сторінка PDF із вбудованим XML рахунку. Завантажуйте PDF; XML буде вилучено автоматично.
• Окремий файл XML — XRechnung або документ CII чи UBL без PDF навколо. Завантажуйте як є. Контейнера перевіряти нема, тож звіт починається з шару схеми.
• Звичайний PDF — надрукований або відсканований рахунок узагалі без структурованих даних. Тут нема чого перевіряти: це зображення рахунку. Зробити з нього справжній електронний рахунок — інша задача, про неї Перетворення PDF-рахунку.

Якщо ви не певні, що саме тримаєте, — просто завантажте. Якщо валідатор не знайде вбудованого XML, він скаже про це одразу, і ця відповідь теж корисна. Найшвидший спосіб без інструментів — подивитися на вкладення: читалка, яка показує вкладені файли, у гібридному рахунку покаже XML з назвою на кшталт factur-x.xml або zugferd-invoice.xml. Якщо там порожньо — усередині нічого нема.

Крок 1 — завантажити файл

Готувати нічого не треба. Не розпаковуйте, не витягуйте XML руками, не перейменовуйте файл. Завантажуйте документ саме таким, яким його створено або яким він надійшов: файл, який розпакували і запакували знову, — це вже не той файл, що бачить отримувач, а перевірки контейнера оцінюють саме цю «упаковку».

Три речі, які коштують часу, якщо про них не знати:

• Архів ZIP — це не рахунок. Перевіряється окремий файл усередині, а не архів. Розпакуйте й завантажте документ.
• Файл із поштової скриньки, а не з принтера. Хто перезберігає отриманий рахунок, «оптимізує» його або проганяє через PDF-інструмент, той потім перевіряє інший документ — із контейнером, який дорогою написав хтось інший.
• Розмір. На нашій публічній сторінці межа — 5 МБ на файл. Рахунок, що помітно більший, майже завжди несе всередині скани або зображення в друкарській роздільності, і це вже окреме питання.

Крок 2 — читати звіт по порядку

Результати повертаються трьома шарами, і читати їх треба згори вниз: провал на попередньому шарі робить наступні ненадійними. Якщо контейнер PDF/A-3 пошкоджений, придатного XML може не бути взагалі, і розділ про бізнес-правила тоді описує файл, який усе одно ніхто не прочитає.

1. Контейнер — чи це коректний PDF/A-3 із XML, прикріпленим так, як вимагає норма? Для окремого XML цей шар не застосовується.
2. Схема — чи XML коректно сформований і чи кожен елемент відповідає своєму XSD? Цей шар суворий до форми і цілком сліпий до змісту. Він відзначить дату в неправильному форматі, але не дату не того року.
3. Бізнес-правила — чи сходяться суми, чи узгоджена розбивка ПДВ, чи можна ідентифікувати продавця? Саме звідси походить більшість справжніх відмов, і саме тут уважне читання окупається.

Анатомія повідомлення

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

Місце — це XPath, маршрут по дереву XML. Уміти його читати не обов’язково. Досить упізнати останній елемент і подивитися код правила: родини правил і помилки, які справді трапляються, зібрані в статті Бізнес-правила EN 16931 — по розділу на кожен код.

Помилка, попередження, зауваження — що означає кожен ранг

Ранг повідомлення — не справа смаку, він записаний у самому правилі. Трапляються три рівні:

• Фатально. Файл у цьому місці непридатний — зламаний контейнер, XML, який не читається. Перевіряти далі сенсу нема.
• Помилка. Порушено обов’язкове правило. Документ недійсний, і отримувач, який перевіряє машинно, поверне його.
• Зауваження. Щось незвичне, але дозволене. Дуже часто воно походить із національної надбудови, яку до вашого документа застосовувати не обов’язково.

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

Справжній звіт, рядок за рядком

Найшвидше вчитися читати на порахованому прикладі. Рахунок: три позиції, дві ставки ПДВ, знижка на рівні документа.

Поки що все правильно. Помилка — у розбивці ПДВ: програма відняла знижку від суми без ПДВ, але не від бази 19-відсоткової ставки. Тому у файлі стоїть:

Звіт тоді виглядає так:

• Контейнер: пройдено. Коректний PDF/A-3, XML прикріплено з потрібним типом зв’язку, метадані XMP на місці.
• Схема: пройдено. Кожен елемент на своєму місці, кожне число в правильному форматі.
• Бізнес-правила: дві помилки, одне зауваження.

Помилка 1 — BR-S-08: для кожної ставки база оподаткування має дорівнювати сумі позицій цієї ставки за вирахуванням пов’язаних із нею знижок. 1 140,00 + 240,00 − 67,00 = 1 313,00, а у файлі 1 380,00. Місце: рядок 19 % у розбивці ПДВ.

Помилка 2 — BR-CO-15: сума з ПДВ має дорівнювати сумі без ПДВ плюс загальний ПДВ. 1 400,00 + 268,29 = 1 668,29, а у файлі 1 655,56. Місце: підсумок у шапці документа.

Зауваження — BR-DE-21: ідентифікатор у BT-24 не той, що в XRechnung. Так і має бути, це рахунок ZUGFeRD.

І ось чому звіт читають, а не «відпрацьовують» згори вниз: дві помилки, одна причина. Знижку провели без податкової категорії. Хто візьме другий висновок окремо і впише в підсумок 1 668,29 руками, той не зробить файл правильним, а лише перенесе суперечність: на видимій сторінці буде 1 655,56, а в даних 1 668,29 — і вирішальна саме структурована частина.

Ремонт — один клік у програмі: знижці призначається податкова категорія «основна ставка 19 %». Після цього програма перераховує 1 313,00 → 249,47 → 255,56 → 1 655,56, і друга помилка зникає разом із першою.

Зауваження, які трапляються постійно

За наведеними повідомленнями стоїть більша частина відмов на практиці. Кожен рядок веде до докладного розділу про цей код.

Крок 3 — усувати причину, а не файл

Кожен висновок називає код правила і вказує на місце в XML. Місце каже «де», код каже «чому». Далі виправляйте самі дані в тій системі, що створила рахунок: відсутній ПДВ-номер у профілі компанії, крок округлення в програмі, позицію, яку ніхто не завів. І створюйте документ звідти заново.

Правити XML напряму спокусливо і майже завжди хибно — з трьох причин:

• Сторінка й дані розходяться. У гібридному файлі видима сторінка і вбудовані дані мають казати те саме. Підправлений руками XML уже не відповідає сторінці поруч.
• Помилка повернеться. Причина сидить у реквізитах або в налаштуванні. Хто лагодить файл, лагодить окремий випадок і виставляє наступний рахунок із тим самим дефектом.
• Файл ламається. Якщо змінити XML усередині гібридного PDF, контейнер більше не сходиться: вкладення — частина файлу, а не документ, покладений поруч.

Крок 4 — перевірити ще раз і надіслати

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

Як часто перевіряти — залежить від того, наскільки свіжий перехід:

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

Перелік перевірок перед надсиланням

Пройти один раз для перших документів і ще раз — коли щось змінюється у виставленні рахунків. Більшість пунктів закриває валідатор; решта потребує людського погляду.

• Файл відкривається в будь-якій читалці як звичайний PDF, і сторінка читабельна.
• Профіль відповідає тому, що вимагав отримувач, — дехто задає його прямо.
• Суми позицій дають суму без ПДВ, а без ПДВ плюс податок дають суму з ПДВ.
• ПДВ-номери продавця й покупця є і мають префікс країни.
• Дата рахунку й дата оплати заповнені.
• Одиниці виміру — стандартні коди, а не вільний текст на кшталт «шт.» чи «години».
• Кожна податкова категорія, яка потребує підстави — звільнення, зворотне нарахування, експорт, — її має.
• Числа на видимій сторінці збігаються з числами в XML.
• Звіт не показує фатальних висновків на жодному шарі.
• Якщо вимагали номер замовлення чи референс — він у документі. Державні замовники Німеччини вимагають Leitweg-ID; без нього рахунок повернеться.

Перевірка отриманих рахунків

Для вхідних документів питання дещо інші, бо тут ви перевіряєте не свою роботу.

• Чи відповідає XML сторінці? Про це забувають найчастіше, і це найдорожчий висновок. У гібридному файлі в облік потрапляють вбудовані дані, і вони можуть відрізнятися від того, що показує PDF. Де вони розходяться, це треба з’ясувати з постачальником, перш ніж документ піде в бухгалтерію: вирішальна структурована частина.
• Чи він взагалі дійсний? Файл постачальника, який падає вже на перевірці контейнера, ніде не прочитається як слід — і сказати про це першого дня дешевше, ніж після платіжного прогону.
• Чи правдоподібні податкові дані? ПДВ-номер, категорія і ставка — або зазначена підстава там, де податок не нараховано.
• Чи це дублікат? Структуровані дані роблять подвійні проведення куди помітнішими, ніж будь-коли дозволяв сканований папір. Пара «номер рахунку + ПДВ-номер продавця» ідентифікує документ однозначно.
• Що саме ви архівуєте? Зберігати треба структуровану частину, без змін: у Німеччині — вісім років за § 14b UStG. Архів, у якому лежить лише роздруківка, цієї вимоги не виконує; подробиці — у статті Зберігання та GoBD.

Чого чистий звіт не доводить

Перевірка — це доказ відповідності, а не аудит, і точність щодо її меж рятує від суперечок згодом.

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

Часті запитання

Чи треба спершу витягти XML із PDF?

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

У звіті є зауваження, але немає помилок. Можна надсилати?

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

Чому кожен мій рахунок ZUGFeRD повідомляє BR-DE-21?

Бо це правило перевіряє, чи ідентифікатор у BT-24 — той, що в XRechnung. У рахунку ZUGFeRD він інший, і так і має бути. Повідомлення не є дефектом вашого файлу; у нашому звіті воно вже відняте.

Чи можна перевірити рахунок, надісланий давно?

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

Звіт чистий, а отримувач усе одно відхиляє. Що робити?

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

Як перевірити окрему XRechnung?

Так само: завантажити файл XML. Контейнера немає, звіт починається з шару схеми, а німецькі правила BR-DE-* тут діють у повному обсязі, включно з Leitweg-ID для відомств.

Як дізнатися, проти якої редакції перевіряли?

Придатний звіт називає свій набір правил. Наш перевіряє проти правил Schematron EN 16931 і форматних правил ZUGFeRD та Factur-X; основа — Mustang 2.26.0 від 25 серпня 2026 року. Чинна версія формату — ZUGFeRD 2.5.2 / Factur-X 1.09.2, застосовується з 1 вересня 2026 року.

Чи зберігається мій рахунок?

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

Коротко

• Завантажувати файл як є — не розпаковувати й не перезберігати.
• Читати згори вниз: контейнер, схема, бізнес-правила. Провал угорі робить усе нижче ненадійним.
• Розділяти помилки й зауваження, перш ніж щось міняти. BR-DE-21 належить кожному рахунку ZUGFeRD.
• Кілька висновків часто мають одну причину. Спершу шукати причину, потім рахувати.
• Виправляти в системі-джерелі, ніколи в XML: інакше сторінка й дані суперечать одне одному, а вирішальні дані.
• Після кожного виправлення перевіряти знову, а в отриманих рахунках звіряти сторінку з XML.

Перевірити файл тут

Наш валідатор проходить усі три шари на тій самій відкритій основі, на якій зійшлася галузь, — проєкті Mustang — і повідомляє кожен висновок із кодом правила, ступенем і місцем. Він безкоштовний і не вимагає реєстрації: ви завантажуєте файл і отримуєте звіт. Обмеження — 5 МБ на файл і близько дванадцяти перевірок на годину з одного джерела: достатньо для щоденної роботи і достатньо вузько, щоб сторінку не забрали собі скрипти. Завантажені файли не зберігаються: документ існує як тимчасове завантаження на час перевірки і видаляється із завершенням запиту.