KSeF відхилив рахунок? Поширені помилки та способи виправлення

Технічно успішна відповідь на запит надсилання ще не означає, що KSeF прийняв рахунок. Статус 100 означає прийняття до подальшої обробки, статус 150 означає, що обробка триває, і лише статус 200 підтверджує успіх.

Відхилений документ не отримує номера KSeF і UPO та не вважається виставленим у KSeF. Спочатку прочитайте код, опис і деталі помилки. Потім виправте P_1, XML FA(3), дозволи, шифрування або іншу вказану причину.

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

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

Статуси 100 і 150 не означають ані відхилення, ані остаточного успіху. Продовжуйте перевіряти той самий рахунок.

Коди помилок треба читати разом із полями description, details і extensions. Код визначає категорію, а деталі вказують конкретну причину.

Не надсилайте документ повторно лише тому, що UPO ще не видно. Спочатку перевірте статус і номер KSeF.

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

Статус може містити номер KSeF, дату його присвоєння та адресу завантаження UPO. Ці дані є результатом успіху, а не самого початку надсилання.

За негативної перевірки KSeF не присвоює номера. Документ не був виставлений у KSeF, тому його можна виправити й надіслати повторно як первинний рахунок.

Поле P_1 містить дату виставлення, указану продавцем. Порівняйте її з фактичною датою надсилання документа до KSeF. Три співвідношення дають три різні результати.

Приклад відхилення: файл надсилається 2 червня 2026 року, але P_1 містить 3 червня. Майбутня дата призводить до відхилення XML.

Приклад offline24: P_1 містить 2 червня, а рахунок надсилається 3 червня. Раніша P_1 не призводить до автоматичного відхилення, а визначає режим offline24.

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

Код 430 означає помилку перевірки файлу, код 450 означає семантичну помилку. Прочитайте деталі, виправте вихідні дані й створіть XML повторно.

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

Можливість автентифікуватися в KSeF не дає автоматичного права виставляти рахунки в кожному контексті. Захищені ресурси API потребують токена доступу, а надсилання звичайного рахунку потребує дозволу InvoiceWrite.

Код 410 означає неправильний обсяг дозволів. Перевірте контекст платника, чинність токена або сесії, фактичного відправника та його право виставлення.

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

Код 440 означає, що KSeF розпізнав дублікат. Відповідь може містити originalSessionReferenceNumber і originalKsefNumber, що ведуть до первинної сесії та раніше присвоєного номера.

Знайдіть указаний рахунок, перевірте статус і завантажте UPO. Не створюйте новий документ і не змінюйте номер лише для обходу контролю дублікатів.

Офіційні джерела підтверджують код 440 і дані API, але не описують повного алгоритму пошуку дублікатів. Спирайтеся на результат API та доказ попереднього успіху.

1. Збережіть референс сесії, референс рахунку, точний час операції та надісланий XML.

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

3. Прочитайте й збережіть code, description, details та extensions.

4. Віднесіть помилку до категорії: P_1, FA(3) або XSD, семантика, дозволи, шифрування, додаток, дублікат чи технічна проблема.

5. Перед кожним повторним надсиланням перевірте, чи документ уже не має номера KSeF.

6. Виправте вихідні дані, а не лише фінальний текст XML.

Якщо рахунок не отримав номера KSeF, виправте вихідні дані або доступ. Створіть новий XML FA(3), перевірте структуру, відкрийте правильну сесію та надішліть документ повторно.

Контролюйте рахунок до кінцевого статусу. Статуси 100 і 150 потребують очікування. Помилка потребує нової діагностики. Процес завершено лише після статусу 200, номера KSeF і доступного UPO.

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

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

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

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

Будову документа описує XML і формат FA(3) у KSeF. Якщо рахунок уже має номер KSeF, скористайтеся матеріалом Коригувальний рахунок у KSeF.

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

Перевірте структуру нового XML, дозволи та P_1, надішліть файл у правильній сесії й контролюйте до статусу 200, номера KSeF і UPO. Якщо номер уже є, створіть коригувальний рахунок.

Рекомендовані матеріали: Надсилання рахунків до KSeF, UPO в KSeF, XML і FA(3) та Коригувальний рахунок у KSeF.