Валідація е-рахунків: як безкоштовно перевірити XRechnung і ZUGFeRD
Чи справді е-рахунок відповідає стандарту, з'ясовується лише при валідації за EN 16931. Як безкоштовно перевіряти рахунки й виправляти типові помилки.
Чому «виглядає нормально» недостатньо
Е-рахунок юридично надійний лише якщо його структурований набір даних відповідає європейському стандарту EN 16931 — а цього не видно за виглядом PDF. Документ ZUGFeRD може виглядати візуально бездоганно й усе ж містити помилковий або неповний XML. Системи одержувачів перевіряють автоматично: якщо рахунок не проходить валідацію, він відхиляється, а оплата затримується.
Що перевіряє валідація
- Валідація схеми: чи технічно коректний XML і чи відповідає він синтаксису (UBL або UN/CEFACT CII)?
- Бізнес-правила EN 16931: чи присутні всі обов'язкові поля (business terms) і чи несуперечливі вони — наприклад, номер рахунка, податкові ставки та підсумки?
- Національні правила: до XRechnung застосовуються додаткові німецькі вимоги (CIUS XRechnung), наприклад обов'язковий Leitweg-ID для рахунків органам влади
- Арифметична перевірка: чи правильно складаються підсумки за позиціями, суми податку та валова сума?
Безкоштовні інструменти валідації
Для швидкої практичної перевірки добре підходить безкоштовний онлайн-валідатор від taxlayer: завантажте файл XRechnung або ZUGFeRD, і ви отримаєте зрозумілий аналіз порушень стандарту та правил. Технічно досвідчені команди можуть додатково використовувати еталонні інструменти від KoSIT (валідатор зі сценаріями XRechnung), хоча їхні звіти потребують певного звикання. Важливо: валідувати не один раз, а після кожного оновлення ПЗ та кожної зміни формату.
Найчастіші помилки валідації та їх причини
- Відсутність обов'язкових відомостей: посилання покупця, умови оплати або контактні дані не ведуться в системі виставлення рахунків
- Хибні податкові категорії: звільнені від податку операції без відповідного коду причини звільнення
- Розбіжності округлення: суми за позиціями та підсумки розходяться на центи, бо вища система округлює інакше
- Застарілі профілі: ZUGFeRD 1.0 або профіль BASIC-WL не відповідають вимогам EN 16931
- Недійсні ідентифікатори: помилкові ІПН з ПДВ, IBAN або Leitweg-ID у майстер-даних
Від звіту про помилки до чистого рахунка
Більшість помилок валідації — це помилки майстер-даних: виправлені один раз в ERP або системі виставлення рахунків, вони зникають з усіх подальших рахунків. Тому завжди виправляйте помилки в джерелі, а не в окремому документі. Якщо ваша система взагалі не формує відповідні стандарту дані, сервіси на кшталт taxlayer.de перетворюють наявні PDF-рахунки на дійсні файли ZUGFeRD або XRechnung. Який формат якому одержувачу підходить, пояснюється в порівнянні ZUGFeRD проти XRechnung.
Passendes Tool
Зробіть кожен рахунок таким, що відповідає вимогам е-рахунка.
Створити е-рахунок на taxlayer.de →Häufige Fragen
Чи недійсний рахунок, якщо валідатор показує попередження?
Ні. Валідатори розрізняють помилки (порушення обов'язкових правил — рахунок не відповідає стандарту) та попередження (зауваження про рекомендовані, але не обов'язкові відомості). Помилки необхідно виправити; попередження слід перевірити, але вони не роблять рахунок недопустимим.
Чи повинен я валідувати й вхідні е-рахунки?
Наполегливо рекомендується. Як одержувач ви несете ризик відрахування вхідного ПДВ: якщо відсутні обов'язкові відомості за § 14 абз. 4 UStG, податкова інспекція може відмовити у відрахуванні. Автоматизована перевірка вхідних одразу виявляє помилкові рахунки, тож ви можете запросити виправлення в постачальника до того, як щось буде проведено й оплачено.
У чому різниця між перевіркою схеми та перевіркою Schematron?
Перевірка схеми забезпечує синтаксичну коректність XML — правильні елементи в правильному місці. Перевірка Schematron потім застосовує змістовні бізнес-правила EN 16931 та національні вимоги, як-от правила розрахунку й залежності між полями. Відповідний стандарту е-рахунок має пройти обидва рівні перевірки.
Як перевірити, чи містить мій PDF ZUGFeRD взагалі XML?
Відкрийте файл у PDF-рідері з переглядом вкладень: XML видно як вбудований файл (зазвичай factur-x.xml або xrechnung.xml). Якщо вкладення відсутнє, це простий PDF без структурованих даних — і тим самим, з настанням установлених законом строків, більше не е-рахунок у розумінні § 14 UStG. Онлайн-валідатор також одразу це покаже.
Weiterführende Artikel
Е-рахунки 2027/2028: зворотний відлік для німецьких МСП
Перехідні періоди для обов'язкових е-рахунків спливають. Які строки діють за § 14 UStG і що вам варто зробити цього року.
Buchhaltung & LogistikОбов'язок щодо е-рахунків: ZUGFeRD чи XRechnung?
Обидва формати відповідають вимогам закону — але для різних одержувачів. Порівняння.