Що таке ZUGFeRD? Німецький гібридний формат рахунків

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

Назва розшифровується як Zentraler User Guide des Forums elektronische Rechnung Deutschland. Об’єднання FeRD засноване 31 березня 2010 року в Берліні й працює під егідою AWV — німецької спілки з питань господарського адміністрування; до нього входять міністерства федерації та земель разом із великими галузевими спілками. Перша редакція, ZUGFeRD 1.0, вийшла 25 червня 2014 року — за роки до європейської норми, на яку формат спирається сьогодні.

Що насправді лежить усередині файлу

Файл ZUGFeRD складається з трьох частин, укладених в один конверт.

• Конверт: PDF/A-3. Це єдиний різновид стандарту архівного зберігання PDF/A, який дозволяє вбудувати в PDF довільний файл і позначити його як рівноцінну складову. Саме тому PDF/A-3, а не будь-який PDF: у звичайному PDF вкладення — це додаток, тут воно є частиною документа.
• Видима сторінка. Цілком звичайний PDF — ваш макет, ваш логотип, ваші шрифти. Вона має читатися без того, щоб одержувач щось встановлював.
• Вкладений XML. Зазвичай має ім’я factur-x.xml і написаний у синтаксисі UN/CEFACT Cross Industry Invoice (CII). Які поля в ньому бувають і як вони називаються — у статті Структура XML.

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

Чому гібрид, а не просто XML?

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

Чистий XML обслуговує лише першу сторону. Без інструментів він нечитабельний, і вже цього досить, щоб невеликі компанії відкладали перехід. Чистий PDF обслуговує лише другу: механічно з нього нічого не взяти, хіба що розпізнати символи й угадати поля — з усіма помилками, які при цьому виникають (див. Конвертація PDF-рахунку).

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

Яка версія чинна

ZUGFeRD випускається разом із французьким форматом-побратимом Factur-X; номери версій ідуть паралельно.

2.5.2 — це виправлення до 2.5: усунуто суперечності у правилах перевірки, округленні та розбивці ПДВ, передусім у профілі EXTENDED; оновлено XSD і Schematron. Наступного випуску очікують восени 2026 року.

Профілі — і ті з них, що не рахуються за електронний рахунок

«ZUGFeRD 2.x» ще не каже, скільки даних у файлі. Це вирішує профіль. Лінійка 2.x визначає п’ять: MINIMUM, BASIC WL, BASIC, EN 16931 (раніше COMFORT) та EXTENDED.

І тут ховається найдорожча пастка всієї теми: MINIMUM і BASIC WL не рахуються за електронний рахунок для цілей німецького ПДВ. Міністерство фінансів Німеччини зафіксувало це ще в роз’ясненні від 15 жовтня 2024 року й підтвердило у 2025-му. MINIMUM несе лише скорочені дані шапки, BASIC WL узагалі не містить позицій рахунку — «WL» означає without lines. Жоден із них не містить обов’язкових реквізитів, тож файл у цих профілях юридично є «іншим рахунком», а не структурованим документом.

Підступність у тому, що файл MINIMUM технічно бездоганний: він проходить перевірку, він відкривається, він виглядає як електронний рахунок. Просто він не зараховується. Для звичайного випадку беріть EN 16931; BASIC вистачає для простих рахунків без особливостей; EXTENDED потрібен лише для ситуацій, яких норма не описує.

ZUGFeRD і Factur-X: один формат, дві назви

Їх часто описують як конкурентні формати. Від ZUGFeRD 2.1 / Factur-X 1.0 це вже неправда: вони спираються на одну основу — EN 16931 у синтаксисі CII — і використовують ту саму схему й ті самі правила перевірки. Файл, створений у профілі EN 16931, обидві сторони приймають як дійсний.

Різняться походження, назви частини профілів і національні доповнення: профіль XRECHNUNG з боку ZUGFeRD, вимоги французької реформи з боку Factur-X. Для німецько-французького рахунку в профілі EN 16931 переналаштовувати нічого не треба.

ZUGFeRD чи XRechnung?

XRechnung — не гібридний формат, а чистий XML: німецька національна редакція (CIUS) норми EN 16931, обов’язкова для багатьох державних замовників. ZUGFeRD від 2.0.1 і XRechnung — обидва дозволені формати для німецького B2B-обов’язку; вибір залежить від одержувача.

Просте правило: державним замовникам зазвичай ідеться XRechnung, і там переважно вимагають ідентифікатор маршрутизації (Leitweg-ID). У B2B зручніший ZUGFeRD, бо одержувач може подивитися рахунок навіть тоді, коли його програма ще нічого з ним не робить. E-Rechnung Pro випускає ZUGFeRD і Factur-X; файли XRechnung він уміє перевіряти, але не створювати.

Чого насправді вимагає обов’язок

Для компаній, зареєстрованих у Німеччині:

• З 1 січня 2025 року ви маєте вміти приймати електронні рахунки. Без перехідного періоду й незалежно від розміру — поштової скриньки достатньо як каналу приймання.
• З 1 січня 2027 року ви маєте їх виставляти, якщо оборот попереднього року перевищив 800 000 €. З 1 січня 2028 року це стосується решти внутрішніх B2B-оборотів.
• Винятки — рахунки до 250 € брутто, проїзні документи, B2C та окремі звільнені операції. Малі підприємці за § 19 німецького закону про ПДВ безстроково звільнені від виставлення — але не від приймання.
• Зберігання: вісім років. § 14b німецького закону про ПДВ скорочено з десяти років до восьми четвертим законом про зменшення бюрократії; це стосується рахунків, строк яких не спливнув до 31 грудня 2024 року. Зберігати треба структуровану частину — незміненою і простежуваною.

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

Чи потрібно це фрилансерам і малим компаніям?

Приймати — так, із 2025 року, без винятків. Виставляти — з 2027-го або 2028-го залежно від обороту, а як малий підприємець за § 19 — узагалі ні. На практиці ж питання вирішується раніше, і вирішують його замовники. Хто постачає великим корпораціям чи державі, отримує формат як вимогу задовго до того, як спрацює закон.

Зусиль тут менше, ніж підказує репутація теми. Для рахунку на кілька позицій з однією ставкою ПДВ та IBAN не потрібен проєкт — потрібен інструмент, який одразу будує файл правильно, див. Створення першого рахунку. Чого робити не варто — братися заради простоти за профіль MINIMUM. Див. вище.

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

ZUGFeRD — це просто PDF зі штампом?

Ні. Усередині PDF лежить повний структурований набір даних за EN 16931 — ті самі поля, що містить XRechnung. Відмінність від звичайного PDF не косметична: це відмінність між зображенням рахунку і рахунком.

Чи потрібна одержувачеві особлива програма, щоб відкрити файл?

Ні. Файл відкривається в будь-якому переглядачі PDF, як і будь-який інший рахунок. Програма потрібна лише тоді, коли він хоче скористатися вбудованими даними — а в цьому й полягає сенс.

Як зрозуміти, що отриманий файл справді ZUGFeRD?

Найнадійніше — пропустити його через перевірку. Якщо вбудованого XML не знайдено, це звичайний PDF — навіть якщо відправник стверджує інше. Порядок дій описано у статті Перевірка рахунку.

Чи зараховується старий файл ZUGFeRD 1.0?

Ні. Визнається ZUGFeRD від версії 2.0.1, окрім MINIMUM і BASIC WL. Версія 1.0 створена 2014 року й ще не спирається на EN 16931.

Що буде, якщо сторінка PDF і XML розходяться?

Чинним є XML. Розбіжність — це не просто неохайність, а ризик для податкового кредиту, як зазначено в роз’ясненні від 15 жовтня 2025 року. Саме тому обидві половини мають походити з одного джерела даних, і правити їх руками постфактум не можна.

Чи замінює формат бухгалтера?

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

Чи треба конвертувати архів рахунків?

Ні. Обов’язок стосується рахунків, які ви виставляєте починаючи з відповідної дати. Старі PDF-рахунки залишаються дійсними, і зберігати їх можна як є.

Стисло

• Один файл, два читачі. PDF/A-3 з видимою сторінкою і вбудованим XML у синтаксисі CII — людина і програма отримують той самий документ.
• Чинна версія — 2.5.2 (4 серпня 2026, застосовується з 1 вересня 2026). Версії 3.0 не існує.
• MINIMUM і BASIC WL не рахуються. Технічно дійсні, але не електронні рахунки для цілей ПДВ. У разі сумніву — EN 16931.
• ZUGFeRD і Factur-X — один формат під двома назвами, від 2.1 / 1.0.
• Приймати з 2025-го, виставляти з 2027-го або 2028-го, зберігати вісім років.
• Якщо частини розходяться, чинним є XML — видима сторінка не має обіцяти більше, ніж дані.

Створювати відповідні нормі рахунки ZUGFeRD, не збираючи XML руками? Заведіть безкоштовний обліковий запис — або спершу перевірте наявний файл без реєстрації.