Будова XML у рахунку ZUGFeRD: поля та групи

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

XML написано в синтаксисі UN/CEFACT Cross Industry Invoice (CII) — одному з двох, які визнає EN 16931. Другий — UBL, поширений у мережі Peppol. За змістом вони кажуть те саме; різниця лише в написанні.

Три блоки

• ExchangedDocumentContext — за чим побудовано документ. Тут стоїть ідентифікатор профілю BT-24 (див. Профілі), і більше ніде. Одержувач читає його першим, бо саме він визначає, проти якого набору правил перевіряти.
• ExchangedDocument — ідентичність рахунку: номер BT-1, код типу BT-3, дата BT-2 і вільні тексти.
• SupplyChainTradeTransaction — усе інше, трьома групами: TradeAgreement (хто з ким і за якими посиланнями), TradeDelivery (що, коли й куди) та TradeSettlement (оплата, податок, підсумки).

Кожна позиція рахунку лежить у транзакції окремим IncludedSupplyChainTradeLineItem — і повторює той самий поділ у мініатюрі: домовленість про ціну, поставлена кількість, розрахунок за позицією.

Чому поля звуться BT і BG

Норма описує спершу зміст і лише потім написання. BT (Business Term) — це окреме поле, BG (Business Group) — група пов’язаних полів. «Назва продавця» — це BT-27 незалежно від того, написано документ у CII чи в UBL: елементи XML різні, поле одне.

На практиці це означає: якщо звіт перевірки чіпляється до BT-31, знати шлях у XML не потрібно. Потрібно знати, якого реквізиту бракує — тут це ІПН продавця. Коди правил, що посилаються на ці поля, зібрані у статті Бізнес-правила.

Що має нести кожен рахунок

Наведені поля норма вимагає без винятків. Бракує одного — перевірка повідомляє правило BR-*, і документ недійсний.

Кидається в очі те, чого в переліку немає: ІПН. Він обов’язковий не завжди — але щойно ви показуєте податок або застосовуєте зворотне нарахування, його вимагає BR-CO-09 разом із префіксом країни.

Дані продавця: бланк, розкладений на поля

На папері продавець — це те, що надруковано вгорі ліворуч. У XML це іменовані поля, і програма одержувача читає саме їх, а не ваш макет.

• BT-27 — назва продавця. Юридична назва, а не бренд із логотипа.
• BG-5 — поштова адреса з кодом країни. Без коду країни рахунок не пройде.
• BT-31 — ІПН із префіксом (DE…, FR…).
• BT-32 — податковий номер, якщо використовується замість ІПН.

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

Референс покупця і номер замовлення: поля, від яких залежить оплата

Арифметично бездоганний рахунок може повернутися з причини, що не має стосунку до сум: одержувач не може прив’язати його до підрозділу, договору чи замовлення.

• BT-10 — референс покупця. Ідентифікатор, який клієнт повідомляє заздалегідь. У німецьких державних замовників це Leitweg-ID, і національне правило BR-DE-15 робить поле обов’язковим.
• BT-13 — референс замовлення. Номер замовлення клієнта, за яким його система автоматично зводить рахунок із замовленням.

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

Дата постачання і період нарахування — різні речі

Рахунок несе щонайменше дві дати з різним змістом, і плутанина між ними — одне з найтихіших джерел проблем.

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

Позиції: кількість, одиниця, ціна

Позиція несе чотири пов’язані величини:

• BT-129 — кількість;
• BT-130 — код одиниці виміру;
• BT-146 — ціна за одиницю;
• BT-131 — сума нетто за позицією.

Одиниця — не вільний текст. «шт.», «пак.» чи «год.» не годяться: потрібен код зі списку UN/ECE Recommendation 20, щоб обидві системи розуміли під ним одне й те саме.

Знижки, надбавки та доставка

Рядок «мінус 10 %» читабельний для людини і беззмістовний для програми. У норми для цього є свої місця: BG-20 для знижок на рівні документа і BG-21 для надбавок, плюс їхні відповідники на кожній позиції.

Кожна знижка й кожна надбавка несе три речі:

• суму — BT-92 для знижки, BT-99 для надбавки;
• підставу, текстом або кодом (BT-98 і BT-105), щоб одержувач провів її правильно;
• категорію та ставку податку, бо знижка зменшує базу оподаткування і має той самий режим.

Доставка, пакування та надбавки за спосіб оплати теж належать сюди, а не до ціни за одиницю. Показані так, вони проходять перевірки округлення в одержувача; сховані в ціні, вони дають розбіжності BR-CO-*, які згодом уже ніхто не пояснить.

Умови оплати

«Оплатити протягом 14 днів» — це речення. У структурованому рахунку з нього виходить:

• BT-9 — дата платежу як конкретна дата, а не опис;
• BT-20 — умови оплати текстом, включно зі знижкою за дострокову оплату;
• BG-16 — платіжна інструкція: спосіб оплати, IBAN, власник рахунку.

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

Більш ніж одна валюта

Якщо рахунок виставлено в одній валюті, а податок обліковується в іншій, норма вимагає вказати обидві явно, а не покладатися на здогад:

• BT-5 — валюта рахунку;
• BT-6 — валюта обліку податку, якщо вона інша;
• курс перерахунку на дату виставлення.

Брак цих полів — часта причина відхилення транскордонних рахунків, і причина, якої за сумами не видно.

Кредит-нота — не рахунок із мінусом

Це помилка, яку приносять бухгалтери, звиклі до простих PDF. У нормі кредит-нота — окремий тип документа, який задається полем BT-3:

• 380 — рахунок;
• 381 — кредит-нота.

Суми в ній додатні; напрям задає код типу. До цього додається посилання на виправлюваний документ — BG-3 із номером попереднього рахунку (BT-25), за чим стежить BR-55. «Рахунок із від’ємними сумами» перевірки не проходить і в одержувача не проводиться.

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

Чи треба вміти писати XML руками?

Ні. Треба вміти читати те, що повідомляє звіт перевірки, — це інше. Звіт називає код правила і поле; звідти шлях веде в систему, яка створила рахунок, а не в редактор XML.

Де у файлі шукати профіль?

В елементі GuidelineSpecifiedDocumentContextParameter першого блоку — це BT-24. Що означає яка URN, описано у статті Профілі.

Чи CII кращий за UBL?

Ні, це інше написання тієї самої моделі. ZUGFeRD і Factur-X використовують CII, Peppol переважно UBL. Якщо хтось вимагає UBL — ідеться про мережу, якою він приймає, а не про якість даних.

Чи можна додати власні поля?

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

Чому перевірка чіпляється до підсумку, хоча сторінка правильна?

Бо вона рахує поля, а не сторінку. Найчастіша причина — знижки, заховані в ціні за одиницю, замість того щоб бути показаними в BG-20. Родини правил про це — у статті Бізнес-правила.

Чи має XML збігатися з видимою сторінкою?

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

Як подивитися XML отриманого рахунку?

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

Стисло

• Три блоки, і майже все лежить у третьому — підсумки й податок аж у розрахунку.
• BT — поле, BG — група. Номер не залежить від синтаксису: BT-27 означає назву продавця і в CII, і в UBL.
• Дванадцять полів обов’язкові без винятків, а ІПН додається щойно з’являється податок.
• BT-10 і BT-13 вирішують питання оплати, а не дійсності — у німецького державного замовника BR-DE-15 робить їх обов’язком.
• Одиниці — це коди з UN/ECE Rec 20, а не вільний текст.
• Знижки належать до BG-20, а не до ціни за одиницю — інакше підсумки не сходяться.
• Кредит-нота — це код типу 381, додатні суми і посилання на початковий рахунок.

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