PDF не збігається з XML у KSeF: що є рахунком

Коли ти виставляєш рахунок у KSeF (Krajowy System e-Faktur, польська національна система електронних рахунків), рахунком є файл XML FA(3), якому система присвоїла номер KSeF, а PDF, надісланий контрагентові поштою, лише його візуалізація: за Міністерством фінансів (МФ), вона має збігатися з XML і не може йому суперечити. У матеріалах МФ, які ми переглянули, немає відповіді, чи PDF, що відрізняється від XML, є «порожнім рахунком» (pusta faktura, тобто рахунок за операцію, якої не було), який документ має перевагу при розбіжності і які податкові наслідки вона має.

Правовий стан на 15 жовтня 2026 року.

Що є рахунком, а що візуалізацією

Закон про ПДВ визначає структурований рахунок як рахунок, «виставлений за допомогою Національної системи електронних рахунків разом із присвоєним номером, що ідентифікує цей рахунок у цій системі» (ст. 2 pkt 32a). Посібник KSeF додає, що він має формат XML. Сам номер KSeF не входить до файлу: структура FA(3) не має для нього поля, система повертає його в UPO (офіційному підтвердженні отримання). Тому номер і QR-код ти бачиш на роздруківці, але не в XML. У відповідях на питання МФ пише прямо: «З формальної точки зору документом є формат xml рахунку».

Рахунок, переданий поза системою (наприклад, PDF поштою чи роздруківка), МФ описує як рахунок, «виданий у погоджений спосіб або використаний поза KSeF». Вимог три: узгодженість із файлом XML, читабельність і відсутність суперечностей зі змістом XML. Візуалізація може мати додаткові елементи без значення для системи, наприклад логотип чи контакт служби підтримки клієнтів, і навіть бути іншою мовою, ніж XML. За МФ, вона має по суті відображати дані з KSeF, «щоб не вводити в оману щодо умов операції» того, хто її отримує.

Посібник KSeF 2.0, ч. II, пп. 1.1, 1.6.5 і 4.1

Польський покупець, чий NIP (податковий номер) вписано в поле NIP, отримує рахунок у KSeF, а датою отримання вважається день присвоєння номера KSeF (ст. 106na ust. 3 Закону про ПДВ). PDF для нього лише додаток: після присвоєння номера продавець може передати роздруківку або PDF із QR-кодом і номером KSeF, а до того лише підтвердження операції, яке, за МФ, не є податковим документом. МФ зазначає, що e-mail та інші канали для такого покупця мають «лише допоміжний і техніко-організаційний характер», а закон не вимагає надсилати йому візуалізацію. Як знайти рахунок на боці отримувача, пояснюємо в посібнику як отримати рахунок у KSeF.

Посібник KSeF 2.0, ч. II, пп. 1.6.6 і 5.1

Чого МФ не вирішило

Пані Кристина веде бухгалтерію кільканадцяти фірм. Клієнт надсилає їй PDF на 1 230,00 zł, а в KSeF під тим самим номером рахунку лежить XML на 1 320,00 zł. У матеріалах МФ, які ми переглянули, ми не знайшли відповіді на питання, що тоді виникають:

• чи розбіжний PDF є «порожнім рахунком» або другим рахунком,
• чи при суперечності вирішує XML (МФ пише, що формально документом є XML, але прямо не застосовує цього до візуалізації, яка йому суперечить),
• чи може покупець відрахувати VAT із сум, видних на PDF,
• чи загрожує штраф за невідповідну візуалізацію.

Закон про ПДВ не вживає терміна «pusta faktura». Найближчі два положення. Ст. 88 ust. 3a pkt 4 позбавляє права на відрахування з рахунків, які «підтверджують операції, що не були здійснені» (lit. a) або «містять суми, що не відповідають дійсності» (lit. b), у відповідній частині. Ст. 108 ust. 1 зобов'язує сплатити податок кожного, хто «виставить рахунок, у якому покаже суму податку», а ust. 2 застосовує те саме до податку, показаного вище за належний. Обидва положення говорять про рахунки. Чи є PDF, що суперечить XML, рахунком у їхньому розумінні, не пояснюють ні закон, ні МФ.

МФ пов'язує ст. 108 із KSeF в одному місці: тестовий рахунок, помилково надісланий на продуктивне середовище і прийнятий із номером KSeF, є «повноцінним рахунком, який насправді не документує жодної операції», і це може спричинити обов'язок сплатити податок. МФ радить тоді негайно виставити корекцію «до нуля». Те, що так само з іншими помилками в XML, це наш висновок, а не позиція МФ. Якщо розбіжність стосується сум, які ти вже провів в обліку або відрахував, порадься з податковим консультантом.

Закон про ПДВ (Dz.U. 2026 poz. 1263), ст. 88 ust. 3a pkt 4 і ст. 108 Посібник KSeF 2.0, ч. II, п. 3.2.3

Коли відповідь інша

Покупець без NIP або з-за кордону

Споживач, суб'єкт без NIP, іноземна фірма і платник з ЄС у процедурі SME (ст. 106gb ust. 4) отримують рахунок «у спосіб, погоджений із ним», наприклад як PDF; закон форми не визначає, а МФ пише про «свободу» продавця. Рахунок, переданий такому покупцеві поза KSeF, мусить мати QR-код (ст. 106gb ust. 5), а датою отримання вважається день, коли покупець фактично його отримав (ст. 106na ust. 4). Вимога узгодженості з XML поширюється і на нього, бо пункт Посібника прямо стосується рахунку, «виданого в погоджений спосіб». Подробиці в тексті про рахунок для приватної особи.

Посібник KSeF 2.0, ч. II, пп. 1.6.5, 5.1 і 5.3.1

Рахунок, виставлений офлайн

Офлайн-рахунок, ще без номера KSeF, має два QR-коди: «OFFLINE» і «CERTYFIKAT». У режимі offline24 і при недоступності KSeF покупець із NIP, доки рахунок не має номера, може отримати лише підтвердження операції, а сам рахунок отримає в KSeF. Інакше в аварійному режимі (ст. 106nf): тоді рахунок надають кожному покупцеві «у спосіб, погоджений із ним». Якщо він погодив отримання поза KSeF, то отримує рахунок із двома QR-кодами, а якщо в KSeF, продавець може додатково видати йому підтвердження операції.

Передачу покупцеві з NIP рахунку offline24 поза KSeF до його надсилання МФ називає «неправомірною дією з боку продавця». За МФ, покупець тоді має «документ, інший ніж рахунок, виставлений відповідно до ст. 106nda», але може відрахувати з нього VAT у дату фактичного отримання. Більше про офлайн-режим у посібнику збій KSeF і режим офлайн.

Посібник KSeF 2.0, ч. II, пп. 1.6.5, 1.6.6 і 1.8

Продавець ще поза KSeF

До 31 грудня 2026 року продавець може виставляти рахунки поза KSeF, якщо продаж, задокументований ними за місяць, не перевищує 10 000 zł разом із податком (ст. 145m), або коли виставляє їх за допомогою касового апарата (ст. 145n). Тоді рахунок (паперовий, електронний, наприклад PDF, або роздруківка з каси) є звичайним рахунком, а не візуалізацією, і немає жодного XML, з яким його треба порівнювати.

Закон про ПДВ (Dz.U. 2026 poz. 1263), ст. 145m і 145n

Як виправити розбіжність

Рахунок із номером KSeF не можна редагувати, анулювати чи видалити, а коригувальні ноти (noty korygujące) не діють з 1 лютого 2026 року. Якщо помилка в XML, продавець виставляє коригувальний рахунок, у якому суми вказують як різницю щодо первинного рахунку. Новий PDF із виправленими сумами його не замінить. Якщо помилилися з покупцем, потрібні корекція «до нуля» і новий рахунок. Як це зробити крок за кроком, пишемо в тексті про коригувальний рахунок у KSeF.

Покупець не відхилить помилковий рахунок у KSeF, бо система не має такої опції, а спори вирішують поза нею. Якщо помилкова сума чи інша позиція, продавець зобов'язаний виставити коригувальний рахунок (ст. 106j ust. 1), тож покупець може його вимагати. KSeF також не перевіряє обчислень, тож XML із хибною сумою VAT отримує номер так само, як правильний.

Посібник KSeF 2.0, ч. II, пп. 1.6.1–1.6.4, 2.13 і 6.3

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

Як перевірити, чи PDF збігається з KSeF

QR-код на рахунку (KOD I) містить адресу сервісу, дату виставлення (P_1), NIP продавця і хеш SHA-256 файлу XML. Сум у ньому немає. Після сканування ти бачиш основні дані рахунку з KSeF, зокрема інформацію, чи документ у KSeF збігається з тим, для якого згенеровано код, або повідомлення, що такого рахунку в системі немає. На другому кроці вводиш номер рахунку (P_2), податковий ідентифікатор покупця і загальну суму до сплати (P_15) та завантажуєш XML або PDF без входу в систему. Кілька невдалих спроб поспіль спричиняють тимчасове блокування. Без QR-коду рахунок відкриєш анонімно в Aplikacja Podatnika (застосунку платника від МФ): потрібні номер KSeF, P_2, ідентифікатор і назва покупця та P_15.

Посібник KSeF 2.0, ч. II, пп. 5.4.1, 5.4.3, 5.5 і 5.7

Сам код не порівняє того, що видно на PDF, з XML. МФ описує перевірку так: покупець завантажує рахунок із KSeF і перевіряє, чи його дані збігаються з отриманою роздруківкою. Будь уважним на другому кроці: система питає про P_15 з рахунку в KSeF, тож сума, переписана з хибного PDF, може не спрацювати (це наш висновок), а наступні спроби заблокують доступ. Якщо маєш NIP, простіше увійти в KSeF, відкрити рахунок там і порівняти його з PDF поле за полем.

Для розробників: один XML, одне джерело PDF

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

МФ не радить надсилати до KSeF XML з основними даними, а термін оплати чи номер рахунку в банку тримати лише на візуалізації. Для цих даних є місце в структурі FA(3): Platnosc, Rozliczenie, WarunkiTransakcji, DodatkowyOpis. Позначки (Adnotacje) розміщуєш на візуалізації лише тоді, коли вони є (наприклад, P_16 = 1 означає «metoda kasowa», касовий метод); відсутність позначок описувати не треба. Як виглядає візуалізація, вирішує виставник або інтегратор, а МФ прямо відповідає, що вона не мусить виглядати як зразок Міністерства. МФ також надає власний генератор візуалізації на GitHub, яким можна, але не обов'язково користуватися.

CIRFMF/ksef-pdf-generator

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