Чи можна надіслати рахунок-фактуру у форматі PDF до KSeF? Пояснення крок за кроком

Коротка відповідь: чи можна надіслати PDF до KSeF?

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

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

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

Як KSeF працює на практиці?

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

Офіційне FAQ Міністерства фінансів Польщі описує структурований рахунок-фактуру як XML-файл, що відповідає схемі, переданий до системи та позначений унікальним номером. Саме цей номер KSeF підтверджує успішне прийняття документа. Один лише PDF такого результату не дає.

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

Чому PDF відхиляється KSeF?

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

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

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

PDF проти FA(3) XML — чим вони відрізняються у щоденній роботі?

PDF призначений для людей. Його легко читати, друкувати, надсилати електронною поштою або долучати до внутрішнього документообігу. FA(3) XML призначений для систем. Він дозволяє KSeF та інтегрованим застосункам розуміти дані без ручного переведення документа.

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

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

Для чого PDF ще корисний?

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

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

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

Що робити, якщо у вас є лише PDF?

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

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

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

Типові помилки компаній, які починають працювати з KSeF

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

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

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

Чи потрібно надсилати PDF клієнту?

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

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

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

А що з долученням PDF як вкладення?

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

Якщо у відносинах з контрагентом вам потрібно передати PDF, документ Word, JPG або інший допоміжний матеріал, ви робите це поза системою. У самому KSeF ви дотримуєтеся логіки XML і номера KSeF як основи документообігу. Так ви не змішуєте системний шар з комунікаційним.

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

Як виглядає раціональний процес у компанії?

Найбільш практична модель проста: система або інструмент генерує FA(3) XML, валідує його перед надсиланням, передає до KSeF, отримує номер KSeF і UPO, а лише після цього надає користувачу зручний для читання PDF. У такій схемі PDF не заважає — він просто перестає виконувати функцію, для якої ніколи не призначався.

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

Якщо ви хочете перейти від моделі 'маю PDF і не знаю, що далі' до моделі 'маю коректний XML і готовий документообіг у KSeF', ознайомтеся також із застосунком KSeFGPT для імпорту, експорту та AI-аналітики.

Найпоширеніші запитання

Чи можна надіслати PDF замість XML до KSeF? - Ні. До KSeF надсилається структурований рахунок-фактура у форматі XML, а не PDF.

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

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

Чи можу я виставити рахунок-фактуру лише у форматі PDF? - Для документообігу KSeF одного PDF недостатньо. Дійсний рахунок-фактура в системі повинен існувати у форматі XML і бути переданий до KSeF.

Що підтверджує, що KSeF прийняв рахунок-фактуру — PDF чи номер KSeF/UPO? - Підтвердженням є номер KSeF, присвоєний системою, а операційно — також UPO. Один лише PDF не підтверджує, що документ прийнятий KSeF.