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

У вас роками накопичувалися рахунки у звичайному PDF, і раптом клієнт просить структурований електронний рахунок. Природне запитання — чи не можна просто перетворити те, що вже є. Чесна відповідь складається з двох половин: технічна частина нескладна, а та, що вирішує, чи можна довіряти результату, — ні.

Різниця важлива, бо слово «перетворити» ховає один крок. Звичайний PDF не містить жодних структурованих даних. На вигляд він може не відрізнятися від справжнього файлу ZUGFeRD, але всередині немає XML, який могла б прочитати програма. Тож перетворення означає дві окремі речі: здобути дані рахунку й побудувати коректний файл із цими даними всередині.

Крок 1 — звідки беруться дані

Шляхів два, і вони не однаково надійні.

Із системи, що створила рахунок

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

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

Зчитати дані з PDF

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

• У PDF є текстовий шар. У більшості файлів, створених програмою, він є. Текст читається напряму, і вся робота — у розмітці: яке число є сумою без податку, яке податком, які рядки належать таблиці.
• PDF — це скан. Сфотографований чи відсканований рахунок є лише зображенням; символи спершу треба розпізнати (OCR), і тільки потім тлумачити. Кожна помилка розпізнавання далі стає хибним числом.

Крок 2 — побудувати файл

Коли дані підтверджені, їх треба вбудувати в контейнер PDF/A-3. Саме тут провалюється більшість саморобних спроб, бо прикріпити XML до PDF у редакторі — не те саме.

Коректний гібридний файл вимагає:

• Дійсного контейнера PDF/A-3 — архівного різновиду PDF, із вбудованими шрифтами й оголошеними кольоровими профілями.
• XML, прикріпленого з правильним зв’язком (AFRelationship) і під очікуваним іменем файлу, щоб програма одержувача впізнала в ньому дані рахунку, а не довільне вкладення.
• Метаданих XMP, які оголошують стандарт і профіль, яким файл заявляє відповідність.
• Профілю, що відповідає наявним даним. Заявити профіль EN 16931 і не вказати полів, яких він вимагає, означає отримати файл, що не пройде перевірку; див. профілі.

А що Acrobat, PDF24 чи облікові програми?

Питання виникає постійно, тож відповім прямо.

• Загальні інструменти для PDF — Acrobat, PDF24 і подібні — уміють прикріпити файл до PDF і часто вміють зробити PDF/A. Чого вони не вміють — побудувати з вашого рахунку дійсний XML CII, бо не знають, що таке рахунок. Прикріплений вручну зроблений XML дає файл, який падає вже на першому шарі перевірки.
• Бухгалтерські та облікові програми дедалі частіше створюють ZUGFeRD напряму, і якщо ваші рахунки народжуються там, це найкращий шлях: дані ніколи не полишають структурованої форми. Чого такі системи зазвичай не пропонують — перетворення довільного чужого PDF, який створили не вони.
• Спеціалізовані конвертери посередині: читають PDF, пропонують дані й будують гібридний файл. Їхнє слабке місце завжди крок читання — тому екран підтвердження важливіший за швидкість.

Чи треба взагалі перетворювати архів?

Здебільшого ні — і це економить чимало марної роботи.

У Німеччині приймати структуровані рахунки обов’язково з 1 січня 2025 року; виставляти їх обов’язково з 1 січня 2027 року для компаній з оборотом понад 800 000 євро за попередній рік і з 1 січня 2028 року для решти. Рахунки на суму до 250 євро з податком і продажі споживачам є винятком, а малі підприємці за правилом Kleinunternehmer звільнені від обов’язку виставляти назавжди.

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

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

Результат завжди перевіряйте

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

Дві помилки після перетворення трапляються особливо часто:

• Підсумки, що не сходяться — різниця округлення між сумою позицій і підсумком документа, повідомляється кодами BR-CO-*.
• Категорія ПДВ без потрібного обґрунтування — наприклад звільнений рахунок або зворотне нарахування без вказаної підстави.

Обидві походять із кроку витягування даних, а не з формату файлу — саме для цього й існує екран підтвердження. Що саме перевіряють ці коди — у статті про бізнес-правила.

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

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

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

Крок за кроком

1. З'ясуйте походження. Чи існує ще програма, яка створила цей рахунок? Якщо так — вивантажте дані звідти й пропустіть розбір зовсім. Це не гак, це скорочення.
2. Перевірте, чи є текстовий шар. Виділіть мишею суму в переглядачі PDF. Виділяється й копіюється — текст є. Якщо виділення стрибає на всю сторінку, це зображення, тобто скан, і шлях подовжується.
3. Розберіть і зіставте дані. З розпізнаних символів мають вийти поля. Саме на цьому кроці виникають помилки; розділ нижче показує, де саме.
4. Додайте те, чого бракує. Ідентифікатор маршрутизації, контакти, підстава звільнення — див. список вище. Нічого з цього не вгадується.
5. Зберіть файл. Оберіть профіль (зазвичай EN 16931), створіть XML, вкладіть його в PDF/A-3. Цей крок — чиста механіка, він рідко зривається.
6. Перевірте і лише тоді надсилайте. Контейнер, схема, бізнес-правила. Потім звірте суми у звіті з тими, що на сторінці, — перевірка нічого не каже про те, чи 850,00 було правильною сумою.

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

Приклад від початку до кінця

Теорія тут мало допомагає, тож ось увесь шлях на одному рахунку. У PDF є текстовий шар, тобто випадок хороший — не скан, розпізнавання не потрібне. Те, що видобуває зі сторінки текстовий екстрактор, виглядає приблизно так:

Людина читає це за дві секунди. Для програми це лише символи з координатами, і з них має вийти зіставлення з полями норми:

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

Якщо зіставлення правильне, решта виходить сама: 747,00 + 120,50 = 867,50, мінус 17,50 — це 850,00, плюс 19 % — 1011,50. Це ті самі ланцюги, які перераховують бізнес-правила.

Окремий випадок: рахунок — це скан

У відсканованого чи сфотографованого документа текстового шару немає — є зображення. Між зображенням і полями стоїть розпізнавання символів, і воно поводиться не як помилка, яку помічають: воно дає не порожнє поле, а хибне. З 8 виходить 3, з 1.011,50 — 1.011,5D, з O — 0.

Три речі відрізняють придатне від небезпечного:

• Роздільність. Нижче 300 dpi розпізнавання перетворюється на вгадування. Фотографія з екрана для цього непридатна.
• Рівна сторінка. Перекошені аркуші зсувають колонки одна щодо одної, і «це число належить цій колонці» ламається першим.
• Перевірка кожного числа після. Не вибірково. Підсумки, суми податку, ідентифікатори й номер рахунку звіряються зі сторінкою поодинці.

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

Типові помилки і повідомлення, які вони спричиняють

Конвертація раз по раз дає ті самі помилки, і оскільки перевірка відповідає на кожну кодом правила, за кодом видно причину.

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

Чи можна конвертувати скан?

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

Чи можна конвертувати весь архів одразу?

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

Чи збережеться вигляд рахунку?

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

А якщо в PDF бракує того, чого вимагає норма?

Тоді цього й не видобути, і це треба дописати. Найчастіше бракує посилання покупця для держустанов (BR-DE-15) і контактних даних продавця (BR-DE-2). Ні того, ні іншого на звичайному рахунку зазвичай немає повністю.

Який профіль обрати?

Зазвичай EN 16931 — це профіль, що відповідає нормі, і саме його очікують отримувачі. BASIC вистачає для простих рахунків, EXTENDED потрібен лише для випадків, яких норма не охоплює. Відмінності — у статті профілі.

Як зрозуміти, що конвертація вдалася?

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

Стисло

• Конвертувати — це здобути дані й зібрати файл. Другий крок тривіальний, перший вирішує результат.
• Із системи краще, ніж із PDF. Якщо числа десь іще лежать структурованими, беріть їх звідти.
• Текстовий шар — так, скан — лише з перевіркою. Розпізнавання дає хибні числа, а не порожні поля, — а хибне число в очі не впадає.
• Чотири пастки покривають більшість помилок: номер рахунку поруч із номером клієнта, формат дати, роздільник тисяч, знак знижки.
• Завжди перевіряйте перед надсиланням — і шукайте код правила в довіднику кодів, а не вгадуйте.
• Архів конвертувати не треба. Обов'язок стосується нових рахунків.

Чого чекати, якщо чесно

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

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