7 помилок конвертації PDF у XML KSeF

KSeF не приймає звичайний PDF-файл як структурований рахунок-фактуру. Для надсилання потрібен правильний XML-файл, що відповідає структурі FA(3), а PDF може бути лише джерелом даних або візуалізацією документа.

Найпоширеніші помилки конвертації PDF у XML KSeF виникають через неповне зчитування даних, неправильне розпізнавання NIP, дат, ставок ПДВ, контрольних сум і полів, обов'язкових у структурі FA(3).

Надійний процес конвертації має поєднувати зчитування даних із PDF, зіставлення з полями FA(3), технічну валідацію XML і перевірку змісту операції перед надсиланням до KSeF.

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

Помилки конвертації PDF у XML KSeF є практичною, а не лише технічною проблемою. PDF виглядає як рахунок-фактура, але KSeF працює зі структурованими даними у форматі XML. Якщо дані з PDF зчитано неправильно або призначено невідповідним полям FA(3), система може відхилити документ або компанія надішле рахунок-фактуру з помилковим змістом.

Згідно з офіційними матеріалами KSeF, структурований рахунок-фактура має формат XML і відповідає опублікованій логічній структурі польської електронної фактури. З 1 лютого 2026 року застосовується структура FA(3). Самого правильного вигляду документа недостатньо. XML має містити обов'язкові поля, належні типи даних і узгоджені значення.

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

Якщо ви лише вибираєте інструмент для перетворення PDF на XML, почніть із посібника про безкоштовний конвертер PDF у XML KSeF, а потім використайте цей перелік помилок як практичний список контролю.

1. Чого KSeF очікує від XML-файлу

2. PDF помилково вважають рахунком-фактурою KSeF

3. Результат конвертації не порівнюють із PDF

4. Неправильно розпізнаний контрагент

5. Неправильно зіставлені ставки ПДВ і позиції

6. Дати в неправильних полях

7. Неузгоджені валюта й суми

8. Немає валідації XML перед надсиланням

9. Як діагностувати результат конвертації

10. Як KSeFGPT допомагає зменшити кількість помилок

11. Найчастіші запитання

У таблиці показано, які проблеми найчастіше виникають під час конвертації PDF у XML KSeF і як зменшити їх ризик перед надсиланням документа.

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

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

Що потрібно перевірити: номер рахунка-фактури, дату виставлення, дату продажу, NIP продавця й покупця, адреси, коди країн, валюту, ставки ПДВ, суми нетто, ПДВ і брутто, позначення, обов'язкові для конкретного випадку, та повноту позицій рахунка-фактури.

Якщо ви не впевнені, чим XML відрізняється від попереднього перегляду рахунка-фактури, прочитайте також XML і формат FA(3) у KSeF. Це допоможе зрозуміти, чому конвертація з PDF не може обмежуватися копіюванням тексту.

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

Ознака проста: процес закінчується PDF-файлом, а компанія не має XML-файлу, що відповідає FA(3), номера KSeF і UPO, тобто офіційного підтвердження прийняття. Це не помилка самого конвертера, а помилка в проєктуванні процесу.

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

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

Така помилка часто не супроводжується червоним повідомленням валідатора. XML може бути технічно правильним, але містити бізнес-помилку, оскільки дані взято з неправильного місця рахунка-фактури.

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

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

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

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

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

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

Що перевірити насамперед: кількість позицій, ставку ПДВ для кожної позиції, суму нетто для кожної ставки, загальну суму ПДВ, знижки, аванси та позиції з дробовою кількістю.

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

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

Якісний інструмент має показувати дати в попередньому перегляді й дозволяти порівняти їх із підписами у PDF. Для іноземних рахунків додатково перевіряйте формати день-місяць-рік і місяць-день-рік.

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

В XML такі розбіжності можуть перешкодити правильній валідації або вимагати бухгалтерського пояснення. Частину помилок видно лише після порівняння сум за ставками ПДВ, а не тільки суми брутто наприкінці рахунка-фактури.

Список контролю сум: перевірте валюту, десятковий роздільник, кількість знаків після коми, суму нетто позицій, суму ПДВ за ставками, суму брутто, знижки, аванси й відповідність підсумку позиціям.

Сьомої помилки уникнути найпростіше: не надсилайте XML без попередньої валідації. Конвертація PDF у XML є лише етапом підготовки документа. Перед надсиланням файл має пройти технічну валідацію й перевірку основних бізнес-даних.

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

Мінімальний процес перед надсиланням: створіть XML, запустіть валідацію, перевірте повідомлення про помилки, порівняйте дані з PDF, виправте джерело проблеми, повторно створіть XML і лише тоді надішліть документ до KSeF.

Щоб зрозуміти різницю між валідацією XML і обробкою даних, прочитайте також Валідація та обробка XML у KSeF.

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

Варто розділяти три типи проблем: помилку зчитування з PDF, помилку зіставлення з полями FA(3) і бізнес-помилку рахунка-фактури. Кожна потребує іншої реакції. Помилку зчитування виправляють у вихідних даних або попередньому перегляді. Помилка зіставлення потребує зміни правила чи інструмента. Бізнес-помилка потребує бухгалтерського рішення.

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

KSeFGPT є приватним інструментом для роботи з рахунками-фактурами й файлами KSeF. Це не державна послуга, і вона не замінює бухгалтерських рішень, але допомагає впорядкувати процес конвертації та перевірки даних перед надсиланням.

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

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

KSeFGPT надає конвертер PDF у XML та валідатор XML. Публічні інструменти потребують адреси електронної пошти перед завантаженням результату, а безкоштовний ліміт становить 3 використання протягом 24 годин.

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

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

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

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

Чи можна надіслати PDF безпосередньо до KSeF? Ні. Польська Національна система електронних рахунків-фактур KSeF приймає структурований рахунок-фактуру у форматі XML, що відповідає логічній структурі FA(3). PDF може бути джерелом даних або візуалізацією, але не замінює XML.

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

У яких полях найчастіше виникають помилки під час конвертації PDF у XML KSeF? Найчастіше потрібно перевіряти польські податкові номери NIP продавця й покупця, дати, номер рахунка-фактури, валюту, ставки ПДВ, суми нетто, ПДВ і брутто, а також кількість позицій рахунка-фактури.

Чи достатньо валідатора XML перед надсиланням до KSeF? Валідатор допомагає виявити технічні помилки, але не замінює бухгалтерської перевірки. Файл може бути технічно правильним і водночас містити неправильного контрагента, помилкову дату або суму.

Щоб дізнатися більше, прочитайте:

Безкоштовний конвертер PDF у XML KSeF

Чи можна надіслати PDF до KSeF?

XML і формат FA(3) у KSeF

Рахунок відхилено KSeF