Створення першого рахунку ZUGFeRD або Factur-X

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

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

Чи вже зобов’язані?

Питання варте того, щоб поставити його перед тим, як витрачати час: відповідь визначає порядок дій, а не те, чи варто братися.

• Приймати треба вже давно. У Німеччині приймання структурованих рахунків обов’язкове для кожного підприємства з 1 січня 2025 року. Програми для цього не потрібно, а от адреса, на яку файли надходять, і місце, де вони зберігаються, — потрібні.
• Виставляти — з 1 січня 2027 року, якщо оборот попереднього року перевищив 800 000 євро, і з 1 січня 2028 року для решти операцій B2B.
• Винятки — рахунки до 250 євро з ПДВ і продажі споживачам; малі підприємці (§ 19) звільнені від обов’язку виставляти назавжди, але приймати мусять і вони.
• Рахунки відомствам здебільшого вже сьогодні йдуть лише електронно, і зазвичай це XRechnung із Leitweg-ID.

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

Що треба зібрати заздалегідь

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

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

Крок 1 — обрати профіль

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

• BASIC вистачає для простих рахунків без знижкових сходинок, без окремої адреси доставки, без іноземної валюти.
• EXTENDED потрібен лише тоді, коли отримувач вимагає поле, якого норма не знає, — і тоді він зможе його назвати.

Крок 2 — один раз налаштувати реквізити

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

Скористайтеся нагодою і перевірте три речі, які на папері часто неточні:

• Код країни в адресі. Слова «Німеччина» замало, потрібен код. Без нього рахунок не пройде.
• Префікс країни в ПДВ-номері. DE123456789, а не 123456789. BR-CO-09 на цьому наполягає.
• IBAN як поле. Якщо він стоїть лише в підвалі вашого шаблона, для програми його не існує — BR-DE-1 тоді скаржиться на відсутні платіжні реквізити, хоч номер видно на сторінці.

Крок 3 — заповнити рахунок

У E-Rechnung Pro ви спершу обираєте один із чотирьох шаблонів — рахунок за послуги, рахунок продажу й замовлення, партнерський розрахунок або розрахунок виплати. Шаблон визначає лише вигляд видимої сторінки; структуровані дані за ним — у всіх випадках ті самі поля норми.

Далі вносите:

1. Сторони. Ваші дані — з налаштувань, дані клієнта — з договору. Назву переносьте точно, а не скорочення з адресної книги.
2. Позиції. На кожну: опис, кількість, ціна, ставка ПДВ. Чого бракує тут, бракуватиме потім і в XML.
3. Знижки й надбавки окремими полями, а не всередині ціни. Доставка й пакування — так само. Приховані суми — найчастіша причина того, що перевірка підсумків в отримувача не сходиться.
4. Податкову категорію для кожної позиції. Основна ставка, знижена, звільнення, зворотне нарахування — і для двох останніх потрібна підстава, інакше перевірка спрацює.
5. Умови оплати з конкретною датою, а не «сплатити протягом 14 днів».

Приклад рахунку з розрахунком

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

До цього — знижка за лояльність 100,00 € на рівні документа (категорія 19 %) і надбавка за доставку 20,00 € (категорія 7 %). Звідси й підсумкові поля — і саме цей ланцюжок перевіряє потім будь-який валідатор:

З цієї таблиці видно три речі, і саме вони пояснюють більшість повідомлень про помилки в перші тижні:

• Знижка й надбавка належать податковій категорії. Знижка за лояльність зменшує базу 19 %, доставка збільшує базу 7 %. Знижка без категорії вмикає BR-S-08 — і зазвичай одразу ще одне правило слідом.
• Податок рахується за категорією, а не від кінцевої суми. 2 620,00 × 19 % дало б 497,80 € — і це було б хибно. Дві ставки дають два рядки в розбивці, а BT-110 — їхня сума.
• Кожне число ланцюжка — окреме поле. Отримувач їх не перераховує, він їх читає і звіряє зі своїми записами. Тому правильним має бути кожне, а не лише підсумок.

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

Крок 4 — створити файл

Після натискання «Створити» одна за одною відбуваються три речі:

1. З ваших даних постає XML у форматі CII за моделлю EN 16931 в обраному профілі.
2. Читабельна сторінка рендериться і записується як PDF/A-3 — архівний формат, без якого гібридний рахунок неможливий.
3. XML вкладається в цей PDF як вкладення і оголошується в метаданих, щоб отримувач знайшов його, не розбираючи файл.

На виході — один файл. Не PDF і поруч XML: це було б інше, і чимало отримувачів не визнали б його електронним рахунком.

Крок 5 — перевірити перед надсиланням

Це той крок, який пропускають першого разу і потім уже ніколи. Перевірка триває секунди; відхилений рахунок коштує платіжного циклу.

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

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

Крок 6 — надіслати

Норма нічого не каже про те, як рахунок потрапляє до отримувача. Звичних шляхів три:

• Електронна пошта. У німецькому B2B цілком допустима і найпростіша. Надсилайте PDF/A-3 вкладенням, а не посиланням на завантаження: XML подорожує всередині файлу.
• Peppol. Якщо отримувач очікує доставки мережею, вона йде через access point; як влаштована мережа — у статті Peppol.
• Клієнтський портал. Великі компанії й відомства часто наполягають на власній формі завантаження; у Франції шлях додатково проходить через уповноважену платформу (див. Factur-X).

E-Rechnung Pro створює і перевіряє документ; надсилаєте його ви, тим каналом, яким користується ваш клієнт. Першого разу запитайте, якого він очікує: це швидше, ніж з’ясовувати після того, як рахунок десь заліг.

Окремі випадки: малий підприємець, зворотне нарахування, закордон

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

• Малий підприємець за § 19 UStG. Категорія E (звільнено), ставка 0 % і текстова підстава звільнення — без неї спрацює BR-E-10. Виставляти малі підприємці не зобов’язані, приймати — так.
• Зворотне нарахування. Категорія AE, ставка 0 %, застереження про перехід обов’язку на отримувача, і ПДВ-номер покупця тут не бонус, а умова.
• Постачання всередині ЄС. Категорія K, обидва ПДВ-номери і дата постачання чи послуги: без дати BR-IC-11 дасть зауваження.

Один рахунок може нести кілька категорій одночасно — кожна дає власний рядок у розбивці ПДВ. Яка категорія коли діє і яка підстава очікується — докладно в статті ПДВ в електронному рахунку.

Як правильно нумерувати рахунки

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

• Послідовно й без пропусків. Пропуск треба вміти пояснити під час перевірки.
• Свій префікс на кожну юридичну особу, якщо їх кілька: у кожної власний ряд і власні дані продавця.
• Жодних символів, на яких спотикаються системи. Скісні риски й пробіли обробляють по-різному; літери, цифри й дефіс безпечні.

Як не надіслати рахунок двічі під час переходу

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

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

Після надсилання: зберігання

Надсиланням рахунок не завершується. Зберігати треба структуровану частину, без змін і придатною для машинного читання, — не роздруківку і не знімок екрана. За § 14b UStG строк становить вісім років; наприкінці 2024 року його скоротили з десяти, і в такому вигляді він діє з 1 січня 2025 року.

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

Типові помилки першого рахунку

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

Чи потрібні знання XML?

Ні. Потрібні повні дані. Читати те, що повідомляє звіт перевірки, варто вміти — для цього досить коду правила й пояснення до нього.

Чи можна зберегти нинішній макет?

Видима сторінка — ваша. У гібридному рахунку її не замінюють, а доповнюють структурованими даними: клієнт бачить те саме, що й раніше.

Чи має перший рахунок піти клієнтові?

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

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

Ні, від обов’язку виставляти малі підприємці звільнені назавжди. Приймати й зберігати структуровані рахунки все одно треба. Якщо виставляєте добровільно, потрібна категорія E з підставою звільнення.

Що таке Leitweg-ID і чи потрібен він мені?

Це адреса доставки німецьких відомств, вона стоїть у референсі покупця BT-10. Власний вам не потрібен — потрібен отримувача, і лише тоді, коли ви виставляєте рахунок відомству. Якщо його там немає, спрацює BR-DE-15.

А як щодо кредит-нот?

Кредит-нота — окремий тип документа, а не рахунок із від’ємними сумами. Код типу змінюється з 380 на 381, суми лишаються додатними, а виправлений рахунок згадується як посилання — подробиці у статті Будова XML.

Скільки часу треба зберігати файл?

Вісім років за § 14b UStG, і зберігати треба структуровану частину — без змін і з можливістю простежити. Гібридний файл виконує це сам собою, бо обидві частини лежать в одному документі.

А якщо мій клієнт не вміє обробити файл?

Тоді він відкриє його як звичайний PDF і прочитає як раніше. У цьому й перевага гібридного формату: він працює навіть з отримувачем, який ще нічого не змінював.

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

Не перезаписом. Ви виставляєте кредит-ноту або виправлений рахунок із власним номером, який посилається на початковий документ.

Коротко

• Робота — у даних, а не в техніці. Пройдіть перелік вище, перш ніж починати.
• Профіль: EN 16931, доки ніхто не вимагає іншого. Ніколи MINIMUM і BASIC WL.
• Реквізити один раз, рахунки часто. Код країни, префікс ПДВ-номера й IBAN окремим полем — одразу правильно.
• Знижки, доставку й знижку за дострокову оплату показувати — кожну з податковою категорією, а не всередині ціни.
• Ланцюжок підсумків має сходитися за кожною категорією, а не лише в кінці.
• Перевіряти перед надсиланням — і виправляти причину, а не XML.
• Надсилати один файл, вкладенням, каналом клієнта — і зберігати вісім років без змін.

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