KSeF 2.0 vs 1.0: що змінилося в API та схемі FA(3)
З 1 лютого 2026 року схема FA(3) замінила FA(2), а продакшн API 1.0 припинив роботу. Це був не апдейт, а новий інтеграційний контракт. Головні зміни в API: автентифікація JWT окремо від сесії, обовʼязкове шифрування кожної фактури, сертифікати KSeF, незалежна обробка фактур у пакеті, нове виявлення дублікатів і нова модель прав доступу. Головні зміни в схемі: вузол додатка, нова роль «Pracownik» (працівник), розбиття ставки 0% і коду NP на детальні коди, гнучкий термін оплати, IBAN до 34 знаків. Наслідки не лише технічні: інша нумерація фактур, інше зіставлення ставок ПДВ, інші права працівників бухгалтерського бюро.

Якщо постачальник програми каже вам «ми підтримуємо KSeF» (Krajowy System e-Faktur, польська національна система е-фактур), ця фраза нічого не означає. Значення має, чи працює програма на API 2.0 і схемі FA(3), бо з 1 лютого 2026 року інше просто не приймається. Старі адреси середовищ вимкнули 17 січня 2026 року, а продакшн KSeF 1.0 завершив роботу під час технічної перерви 26 до 31 січня 2026 року.
Це стосується вас навіть тоді, коли ви не займаєтеся інтеграціями. Зміни в схемі впливають на нумерацію фактур, на позначення ставок ПДВ при продажу за кордон і на те, кого з працівників бюро реально бачить клієнт у системі. А з 1 січня 2027 року до системи входять найменші платники. За чинним законом штрафи за ст. 106ni закону про VAT діють від того самого дня; 16 вересня 2026 року Міністерство фінансів оголосило про їх перенесення на 1 січня 2028 року — це законопроєкт, ще не ухвалений, і він переносить лише штрафи, а не сам обовʼязок працювати в KSeF.
Далі конкретика.
Дві різні системи, а не дві версії однієї
KSeF 1.0 працював із 2022 року як добровільна система. Логіка була інша: автентифікація зрощена з відкриттям сесії, шифрування в інтерактивному режимі опційне, успадкування прав, схема FA(1), потім FA(2).
KSeF 2.0 будували вже під загальний обовʼязок. Графік впровадження виглядав так:
| Дата | Що сталося |
|---|---|
| 30.06.2025 | Публікація документації API 2.0 (OpenAPI 3.0.4) і структури FA(3) |
| 30.09.2025 | Відкриті тести API 2.0 |
| 15.10.2025 | Передпродакшн середовище (Demo) |
| 01.11.2025 | Старт Модуля сертифікатів і прав (MCU) |
| 01.01.2026 | Модуль заяв про фактури з додатком в e-Urząd Skarbowy (електронна податкова) |
| 17.01.2026 | Повне вимкнення старих адрес середовищ |
| 01.02.2026 | Продакшн KSeF 2.0, лише FA(3) |
Деталі щодо адрес описані в повідомленні Міністерства фінансів для інтеграторів.
Що змінилося в API
Міністерство фінансів опублікувало офіційний огляд ключових змін API 2.0. Найважливіше:
Автентифікація відокремлена від сесії. У 1.0 вхід був невіддільний від відкриття інтерактивної сесії. У 2.0 ви автентифікуєтеся один раз, отримуєте токен JWT і відкриваєте стільки сесій, скільки потрібно. Токени JWT (це не те саме, що токени KSeF) можна оновлювати та відкликати.
Уніфікований старт сесії. Інтерактивна і пакетна сесії стартують однаково:
POST /sessions/online
POST /sessions/batch
В обох випадках передається код формуляра і зашифрований ключ AES.
Шифрування обовʼязкове для всіх фактур. У 1.0 воно вимагалося лише в пакетному режимі. У 2.0 кожна фактура, зокрема одинична, має бути зашифрована локально ключем AES, згенерованим для сесії. Симетричний ключ шифрується асиметрично за схемою RSA-OAEP з SHA-256 і MGF1-SHA256, а актуальні сертифікати публічних ключів беруться з GET /security/public-key-certificates.
Сертифікати KSeF. Новий модуль дозволяє подати заяву на внутрішній сертифікат KSeF, завантажити його, перевірити статус заяви та ліміт сертифікатів. Сертифікати бувають двох типів: для автентифікації та типу Offline, потрібного для другого QR-коду на фактурах, виставлених у режимі offline. Це окремі сертифікати, які виключають один одного.
Пакет без принципу «все або нічого». У 1.0 одна помилкова фактура могла відхилити всю посилку. У 2.0 кожна фактура обробляється незалежно, а помилкові забираються окремим ендпоінтом разом із причиною відхилення.
Інше виявлення дублікатів. Замість хешу файлу система порівнює бізнес-дані: NIP (польський податковий номер) з Podmiot1, RodzajFaktury і номер фактури P_2.
Нова модель прав. Успадкування прав замінили непрямим наданням. Клієнт надає бюро право з опцією подальшої передачі, а бюро передає його конкретним працівникам. Можливі також генеральні права, що охоплюють усіх клієнтів бюро.
Ліміти викликів. Кожен ендпоінт має ліміти на секунду, хвилину і годину, які рахуються за контекстом та IP-адресою. Значення публічні й відрізняються залежно від середовища.
Що змінилося у схемі FA(3)
FA(3) опублікували в CRWDE 25 червня 2025 року, і з 1 лютого 2026 року вона замінила FA(2) (опис структури).
Додатки. Зʼявився вузол Zalacznik, але це не PDF, приклеєний до фактури. Додаток має структуровану форму і є частиною того самого файлу XML. Умова: подати заяву про намір до Szef KAS (керівник Податкової адміністрації) через e-Urząd Skarbowy, розгляд до 3 робочих днів (повідомлення MF). Ліміт розміру фактури з додатком становить 3 МБ. Маркетинговий контент у додатку може коштувати вам самого права ним користуватися.
Нова роль «Pracownik». Третю сторону на фактурі можна позначити як працівника, що спрощує облік відряджень, пального і готелів. Вузол необовʼязковий, тож не варто будувати на ньому всю автоматизацію витрат.
Нові коди ставок. Ставку 0% розбили, а загальний код NP скасували:
0 KR ставка 0% у внутрішніх операціях
0 WDT внутрішньоспільнотна поставка товарів
0 EX експорт товарів
np II послуги, ПДВ з яких розраховує отримувач (ст. 100 п. 1 підп. 4 закону про ПДВ)
np I інші поставки товарів і послуг за межами Польщі
Гнучкий термін оплати. Замість самої дати можна вказати кількість одиниць часу і початкову подію, наприклад 14 днів від отримання фактури.
Дрібниці, які ламають валідацію. Номер рахунку вміщує до 34 знаків (повний IBAN, важливо для закордонних рахунків), назва товару чи послуги — до 512 знаків, додано поле для ідентифікатора платежу KSeF.
Фактури VAT RR мають власну схему. Фактура для rolnik ryczałtowy (сільгоспвиробник на паушальній системі) не є варіантом FA(3). Це окремий міністерський зразок FA_RR із власним варіантом формуляра і власними типами документів (VAT_RR, KOR_VAT_RR). Інтеграція, яка знає лише FA(3), такої фактури не виставить.
Чому це стосується вас, навіть якщо ви не пишете код
Три ситуації з практики:
Нумерація і дублікати. Ви надсилаєте фактуру FV/2026/07/14, отримуєте помилку валідації, правите XML і надсилаєте повторно з тим самим номером, хоча перша версія все ж була прийнята. У 1.0 інший вміст файлу давав інший хеш і проходив. У 2.0 збіг трійки NIP, тип документа і номер означає дублікат. Виправлення йдуть коригуючою фактурою, а не повторним надсиланням.
Ставки ПДВ. Компанія, яка продає послуги до Німеччини і мала в системі одну позицію «NP», тепер має вирішити, це np II чи np I. Це податкове рішення на момент виставлення фактури, а не на момент звітності. Узгодьте зіставлення з бухгалтером один раз і запишіть його в шаблони товарів та послуг.
Права в бухгалтерському бюро. Раніше працівник із правом до фактур самого бюро автоматично обслуговував клієнтів, від яких бюро мало права. Тепер це розділено. Якщо в лютому частина клієнтів «зникла» з видимості працівників, причина майже завжди у відсутності непрямого надання прав, а не в збої системи.
Чек-лист перевірки постачальника
Питайте прямо, чи система надсилає через API 2.0 і FA(3), а не «чи підтримує KSeF».
Перевірте, чи вміє вона виставляти фактуру в режимі offline, тобто чи керує сертифікатом KSeF і генерує потрібні QR-коди.
Перевірте підтримку FA_RR, якщо купуєте у сільгоспвиробників на паушальній системі.
Переконайтеся, що одна помилкова фактура в пакеті не блокує решту.
Перегляньте зіставлення ставок:
0 KR,0 WDT,0 EX,np I,np II.У бюро зробіть аудит прав у модулі MCU, клієнт за клієнтом.
Якщо потрібні додатки, подайте заяву в e-Urząd Skarbowy до того, як плануєте впровадження.
Підсумок
KSeF 2.0 не є черговою версією того самого інтерфейсу. Це інша модель автентифікації, інше шифрування, інша модель прав і інша структура фактури. Більшість цих відмінностей видно лише тоді, коли щось відхиляється.
Biurko від початку побудований на API 2.0 і схемі FA(3), з окремою обробкою FA_RR, автентифікацією через Profil Zaufany або сертифікат KSeF, пакетним надсиланням, режимами offline та імпортом фактур закупівлі з KSeF. Інтерфейс доступний українською. Створіть безкоштовний акаунт на biurko.io і пройдіть шлях від фактури до UPO (офіційне підтвердження отримання) на власному документі.
FAQ
Чи можна ще виставити фактуру в схемі FA(2)? Ні. З 1 лютого 2026 року KSeF приймає лише FA(3). Це стосується і коригувань до фактур, спершу виставлених у FA(2): коригуюча фактура вже має бути в новій структурі.
Чи працюють старі токени та інтеграції з API 1.0? Ні. Продакшн KSeF 1.0 завершив роботу під час технічної перерви 26 до 31 січня 2026 року, а старі адреси середовищ вимкнули 17 січня 2026 року без переадресації.
Чи кожному потрібен сертифікат KSeF? Не обовʼязково. Для автентифікації наразі можна використати й токен KSeF, але за чинними правилами токени KSeF перестають діяти 31 грудня 2026 року. На консультаціях 9 червня 2026 року Міністерство фінансів запропонувало їх зберегти, але рішення у формі акта ще немає — безпечніше перейти на сертифікат KSeF. Для другого QR-коду на фактурах offline потрібен окремий сертифікат типу Offline; без нього фактура offline не має другого QR-коду.
Що саме може бути додатком до фактури? Виключно структуровані дані, які доповнюють фактуру, наприклад деталі споживання чи розрахункових позицій. Не PDF, не скан, не маркетингові матеріали. Потрібна попередня заява до Szef KAS через e-Urząd Skarbowy.
Я ФОП з України, зареєстрований у Польщі як JDG. Мене це стосується? Так. JDG (jednoosobowa działalność gospodarcza, аналог ФОП) як платник ПДВ входить у загальний обовʼязок нарівні з іншими. Значення має не форма діяльності, а статус платника ПДВ і обороти, від яких залежить графік входження в систему.
Теги
Попередня стаття
Ліміт 10 000 zł у KSeF у 2027 році: чи залишиться він?
Наступна стаття
Технічна перерва KSeF і Profil Zaufany: де перевіряти статус