KSeF у 2026 році: терміни, ліміт 10 000 zł і практичний чек-лист

Вступ

KSeF (Krajowy System e-Faktur) — це не просто «новий формат електронних рахунків». З 2026 року це обов’язковий контур роботи з фактурами в Польщі, який змінює процеси, ролі та вимоги до даних.

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

У цій статті — практичне пояснення, що саме змінюється у 2026 році, хто і коли зобов’язаний підключитися до KSeF, як працює виняток 10 000 zł і що реально потрібно підготувати — без маркетингу та загальних фраз.

Коли KSeF стає обов’язковим: ключові дати

Обов’язкове використання KSeF вводиться поетапно:

• з 1 лютого 2026 року — компанії, у яких оборот за 2024 рік перевищив 200 млн zł (з ПДВ)
• з 1 квітня 2026 року — усі інші платники ПДВ

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

Виняток 10 000 zł до кінця 2026 року — як він працює насправді

До 31 грудня 2026 року дозволяється виставляти рахунки поза KSeF (паперові або звичайні електронні), якщо сума таких рахунків у конкретному місяці не перевищує 10 000 zł з ПДВ.

Важливо розуміти:

• ліміт рахується помісячно, а не за рік;
• щойно ліміт у місяці перевищено — подальше виставлення поза KSeF стає проблемним (потрібно переходити на KSeF);
• виняток стосується виставлення, але не скасовує потреби розуміти процес прийому та обробки документів.

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

KSeF 2.0: що зазвичай пропускають під час планування

1) Це не лише API та інтеграція

Разом із KSeF з’являються регламенти: доступи та повноваження, відповідальність за помилки, обробка відхилень, коригування, контроль даних і зв’язок зі звітністю (наприклад, JPK). Часто роблять «технічне відправлення», але не закривають питання: хто власник процесу end-to-end.

2) Рахунки з додатками — окремий процес

Якщо у вас є додатки до рахунків (специфікації, розрахунки, технічні файли), це потрібно планувати як окремий сценарій: строки, правила, зберігання та операційну обробку. Інакше «дрібниця» починає ламати строки виставлення й внутрішні SLA.

Практичний чек-лист підготовки до KSeF

Процеси та відповідальність (фінанси / бухгалтерія)

• Які типи рахунків ви реально використовуєте (B2B, B2C, коригування, аванси)?
• У який момент рахунок вважається виставленим юридично?
• Хто відповідає за доступи, ролі, підпис/відправлення та обробку відхилених рахунків?
• Скільки винятків і нестандартних сценаріїв існує на практиці (а не «за регламентом»)?

Дані та системи (ERP / IT / інтеграції)

• Наскільки повні та узгоджені дані: NIP, адреси, умови оплати, ставки ПДВ?
• Зі скількох систем фактично формуються рахунки?
• Чи є черга відправлення, повторні спроби, логування та моніторинг статусів?
• Як ви будете працювати з додатками (якщо вони є)?

Типові помилки, які проявляються після запуску

• «У нас усе в ERP» — але частина рахунків виявляється ручною.
• Немає власника процесу end-to-end (помилки «між відділами»).
• Коригування й винятки не протестовані.
• Фокус лише на відправленні, а прийом і обробку вхідних документів залишили «на потім».

План впровадження 30 / 60 / 90 днів

0–30 днів — побачити реальну картину

• Повний список джерел рахунків
• Аудит даних і довідників
• Призначення власника процесу

31–60 днів — зібрати робочий «скелет»

• Базова інтеграція з KSeF
• Налаштування ролей і доступів
• Тестування нестандартних сценаріїв

61–90 днів — стабілізація

• Процедури на випадок помилок і відхилень
• Метрики відхилень і затримок
• Готовність до додатків і пікових навантажень

Автоматизація навколо KSeF: безкоштовні / open-source варіанти

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

Для цього часто використовують low-code / internal tools платформи — щоб швидко зібрати «операційний шар» навколо KSeF без дорогої кастомної розробки.

Open-source / безкоштовні інструменти для “операційного шару”

• Appsmith (open-source) — внутрішні панелі, ручна обробка помилок, контроль статусів.
  Site · GitHub
• ToolJet (open-source) — швидкі внутрішні інтерфейси поверх API/БД, зручно для моніторингу й операцій.
  Site · GitHub
• MyCompany (lsFusion) (open-source) — platform-first підхід: бізнес-логіка описується декларативно, зручно, коли процеси змінюються і важливий контроль змін.
  Site · GitHub
• Budibase (community/open-source) — адмін-інтерфейси, внутрішні застосунки, прості workflow.
  Site · GitHub
• NocoBase (open-source) — розширювана low-code платформа з плагінами, CRUD-застосунки + процеси.
  Site · GitHub

Ці інструменти не «замінюють KSeF», але допомагають зробити процес стійким: менше ручних винятків, більше прозорості, швидша реакція на помилки та зміни вимог.

Висновок

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

Чому автоматизація справді потрібна (навіть якщо у вас “невеликі обсяги”)

• Бо винятки множаться. Перші тижні можуть бути спокійними, а далі з’являються “нестандартні” кейси: коригування, аванси, різні джерела даних, рахунки з додатками, ручні рахунки, повернення, розбіжності ставок ПДВ. Без операційного шару це швидко перетворюється на чат + Excel + “запитай бухгалтерію”.
• Бо потрібна видимість, а не здогадки. Треба знати, що відправлено, що прийнято, що відхилено, де «застрягло», хто має реагувати і скільки це триває. Моніторинг + черга + алерти зазвичай дають більше користі, ніж “ще одна інтеграція”.
• Бо зменшує ризик прострочень і комплаєнс-ризик. Проблеми частіше в даних і процесі, ніж в API: неправильний контрагент, неповна адреса, неузгоджені довідники, дубль документа. Автоперевірки перед відправленням і передбачувана обробка помилок суттєво зменшують операційний ризик.
• Бо дає можливість масштабуватися без найму людей під ручний контроль. Зростання, нова філія, новий модуль ERP або новий тип документів найшвидше ламають ручні схеми. Автоматизація — це стійкість і контроль змін.

Офіційні джерела

• KSeF на podatki.gov.pl
• KSeF на gov.pl (Міністерство фінансів)

Схожі пости