KSeF (Krajowy System e-Faktur — польська національна система е-фактур) відхиляє фактуру за частку секунди, коли бракує NIP (податковий номер) продавця або ставки ПДВ. Це якраз легко помітити — отримуєте помилку й виправляєте. Гірша інша категорія: поля, які виглядають необов'язковими, але стають обов'язковими, щойно виникає конкретна правова умова. Цих KSeF не перевіряє. Фактуру прийме, присвоїть номер, а проблема випливе аж під час перевірки JPK_V7 (реєстр ПДВ).
Від 1 лютого 2026 р. логічна структура FA(3) — єдиний прийнятний формат фактури в KSeF; вона замінила FA(2). Захисний період, протягом якого немає штрафів за системні помилки, завершується 31 грудня 2026 р. Санкції починаються від 1 січня 2027 р. Тому саме зараз — реальний момент, щоб упорядкувати дані, поки ціна помилки ще нульова.
Нижче ми розкладаємо схему на три рівні обов'язковості й показуємо, які поля треба заповнювати завжди, які лише за умови, а які — не треба взагалі.
Три рівні обов'язковості — і чому це не просто термінологія
Схема FA(3) — це файл XSD, опублікований Міністерством фінансів Польщі в Центральному репозиторії зразків документів (простір імен http://crd.gov.pl/wzor/2025/06/25/13775/). Кожне поле має один із трьох рівнів:
Обов'язкові — мають бути заповнені в кожній фактурі. Брак = відхилення файлу системою KSeF.
Опціональні (умовно обов'язкові) — заповнюєте обов'язково, але лише коли виникає конкретна правова умова. KSeF не перевіряє, чи умова настала — відповідальність лежить на платнику.
Факультативні — заповнення залежить винятково від вас. Пропуск не має наслідків.
Найбільше клопоту завдає другий рівень, бо інтуїція підказує «опціональне поле = можна пропустити». У FA(3) це хибне припущення. Поле ставки при звільненому продажу, позначення split payment чи внутрішньоспільнотної поставки технічно опціональні, але юридично обов'язкові — і валідатор KSeF вас не зупинить.
Чотири блоки, без яких KSeF відхилить фактуру
Головна схема FA(3) складається з кількох надрядкових блоків. Чотири з них обов'язкові беззастережно в кожній фактурі:
Naglowek (заголовок) — технічні дані документа: код формуляра (
FA), варіант формуляра (3), дата створення.Podmiot1 (продавець) — NIP і повна назва обов'язкові. Брак NIP продавця гарантує відхилення.
Podmiot2 (покупець) — тут перша пастка (див. нижче).
Fa — центральний блок із даними транзакції: дата виставлення (
P_1), номер фактури (P_2), код валюти, вид фактури, підсумки ПДВ і позиції.
Спрощений каркас показує, як небагато треба, щоб фактура була технічно коректною:
<Faktura>
<Naglowek>
<KodFormularza>FA</KodFormularza>
<WariantFormularza>3</WariantFormularza>
<DataWytworzeniaFa>2026-06-21T10:00:00Z</DataWytworzeniaFa>
</Naglowek>
<Podmiot1>
<DaneIdentyfikacyjne>
<NIP>1234567890</NIP>
<Nazwa>ITCompass Artem ...</Nazwa>
</DaneIdentyfikacyjne>
<Adres>...</Adres>
</Podmiot1>
<Podmiot2>
<DaneIdentyfikacyjne>
<NIP>9876543210</NIP>
<Nazwa>Klient Sp. z o.o.</Nazwa>
</DaneIdentyfikacyjne>
<JST>2</JST> <!-- навіть якщо не стосується: треба вписати 2 -->
<GV>2</GV> <!-- навіть якщо не стосується: треба вписати 2 -->
</Podmiot2>
<Fa>
<KodWaluty>PLN</KodWaluty>
<P_1>2026-06-21</P_1>
<P_2>FV/06/2026</P_2>
<P_13_1>1000.00</P_13_1>
<P_14_1>230.00</P_14_1>
<P_15>1230.00</P_15>
<Adnotacje>
<P_16>2</P_16>
<P_17>2</P_17>
<P_18>2</P_18>
<P_18A>2</P_18A>
<P_23>2</P_23>
</Adnotacje>
<RodzajFaktury>VAT</RodzajFaktury>
<FaWiersz>
<NrWierszaFa>1</NrWierszaFa>
<P_7>Послуга з програмування</P_7>
<P_12>23</P_12>
<P_11>1000.00</P_11>
</FaWiersz>
</Fa>
</Faktura>
Каркас оглядовий. Точні назви атрибутів і формат полів завжди беріть з офіційного файлу XSD.
Новинка FA(3), про яку легко забути: у Podmiot2 поля JST (одиниця місцевого самоврядування) і GV (група ПДВ) обов'язкові — навіть якщо фактура не стосується самоврядування чи групи ПДВ, треба вписати значення 2 («не стосується»). Це часта причина відхилень під час перших міграцій з FA(2).
Позиція фактури: що справді має в ній бути
В елементі FaWiersz (позиція) обов'язкові лише три речі:
NrWierszaFa — порядковий номер позиції.
P_7 — назва товару або послуги. За загальним правилом обов'язкова; виняток — коригувальні фактури, що документують гуртові знижки за цілий період. У FA(3) ліміт поля збільшено з 256 до 512 символів.
P_12 — ставка ПДВ. Без неї KSeF відхилить позицію.
Деталь, що збиває з пантелику інтеграторів: FaWiersz не містить суми ПДВ для окремої позиції. Сума податку потрапляє лише до підсумку документа (поля P_13_x нетто й P_14_x ПДВ, за ставкою), з P_15 як загальною сумою до сплати. Поле P_6A (дата поставки в позиції) опціональне — заповнюєте лише тоді, коли окремі позиції мають різні дати продажу. Поля на кшталт Indeks, GTIN, PKWiU, CN факультативні.
Adnotacje: п'ять позначок, які не можна пропускати
Блок Adnotacje (примітки) обов'язковий, а в ньому — п'ять позначок типу «так/ні» (1 = так, 2 = ні), які треба виставляти завжди й не можна опускати:
P_16 — касовий метод
P_17 — самофактурування
P_18 — зворотне нарахування (reverse charge)
P_18A — механізм розділеного платежу (MPP, split payment)
P_23 — спрощена процедура в трикутних транзакціях
Тобто навіть «звичайний» продаж потребує п'яти двійок. Решта полів приміток (напр. P_19 для звільнення разом із правовою підставою в P_19A/B/C, P_22 для внутрішньоспільнотної поставки) заповнюєте умовно.
«Опціональні» поля — пастка, яку KSeF не виявить
Це найважливіша частина. Наведені поля технічно опціональні, але юридично обов'язкові, коли виникає умова — а KSeF прийме фактуру без них:
P_18A = 1 при split payment. Обов'язок розділеного платежу стосується транзакцій ≥ 15 000 zł брутто з товарами з додатка № 15 до Закону про ПДВ (ст. 108a). KSeF не знає ні граничної суми, ні предмета — не перевірить цього. Брак позначки наражає продавця на санкції.
P_22 = 1 при внутрішньоспільнотній поставці товарів. Ставка
0 WDTі примітка мають бути узгоджені; неузгодженість не блокує файл, але псує реєстр JPK_VAT.P_19 + правова підстава при звільненому продажу. Самої ставки
ZW(звільнено) замало — норму треба вписати вP_19A(Закон про ПДВ),P_19B(Директива ЄС) абоP_19C(інші регуляції).JST / GV у
Podmiot2— описано вище; значення2потрібне завжди.
Правило, яке варто запам'ятати: KSeF перевіряє технічну коректність файлу, а не правильність розрахунку по суті. Прийнята фактура не означає «правильно обрахована».
Факультативні поля — що НЕ треба заповнювати
Тут уже багато виставників перегинають у другий бік і заповнюють графи, яких ніхто не вимагає — ні Закон про ПДВ, ні XML-схема. Їхній пропуск ніколи не спричиняє відхилення:
Коди GTU (01–13) — лише для визначених груп товарів і послуг, не для кожної фактури.
PKWiU, CN, GTIN, Indeks — корисні для автоматизації, але не обов'язкові.
DodatkowyOpis (до 10 000 входжень), Platnosc (оплата), TerminPlatnosci (термін оплати), NrZamowienia (номер замовлення) — факультативні.
StopkaFaktury (нижній колонтитул, до 3 × 3500 символів) — для реєстрових даних (KRS, REGON, статутний капітал), годин роботи філій тощо.
Заповнюйте їх, коли вони реально полегшують роботу контрагенту чи вашій бухгалтерії — а не «про всяк випадок».
Швидкий чекліст перед надсиланням до KSeF
Podmiot1: NIP і повна назва продавця присутні.
Podmiot2: покупець ідентифікований (NIP / ПДВ ЄС / без ID для B2C), а
JSTіGVвиставлені (хоча б на2).Fa:
P_1,P_2, код валюти іRodzajFakturyзаповнені;P_15збігається із сумоюP_13_x+P_14_x.FaWiersz: кожна позиція має
NrWierszaFa,P_7іP_12.Adnotacje: п'ять позначок (
P_16,P_17,P_18,P_18A,P_23) мають значення1або2.Правові умови: split payment (
P_18A=1), WDT (P_22=1), звільнення (P_19+ підстава) позначені, якщо стосуються.Іноземна валюта: суми нетто/брутто можуть бути у валюті, але ПДВ (
P_14_xW) завжди в PLN.
Підсумок
У FA(3) важлива не стільки кількість полів, скільки розуміння трьох рівнів обов'язковості. Чотири обов'язкові блоки й кілька полів у позиції вирішують, чи KSeF узагалі прийме файл. Але саме «опціональні» поля — split payment, WDT, підстава звільнення — відповідають за більшість проблем під час перевірки, бо система їх не контролює.
Biurko перевіряє кожну фактуру за офіційною схемою XSD ще перед надсиланням, за замовчуванням виставляє потрібні позначки (зокрема JST/GV та примітки) і перекладає будь-яке відхилення KSeF на зрозуміле повідомлення замість сирого коду помилки. Замість вчити структуру XML напам'ять, ви заповнюєте форму, а коректність контролює система. Спробуйте Biurko безкоштовно 14 днів і виставте першу фактуру FA(3) без ризику відхилення.
FAQ
Які поля у FA(3) беззастережно обов'язкові? Беззастережно потрібні чотири блоки: Naglowek, Podmiot1 (з NIP і назвою продавця), Podmiot2 та Fa. У позиції обов'язкові номер позиції, назва товару/послуги (P_7) і ставка ПДВ (P_12). Без них KSeF відхиляє файл.
Чи перевіряє KSeF, що я застосував split payment? Ні. KSeF не знає ні граничної суми, ні предмета транзакції, тому не перевіряє обов'язку MPP. Поле P_18A технічно опціональне, але юридично обов'язкове, коли транзакція перевищує 15 000 zł брутто з товарами з додатка № 15. Відповідальність лежить на платнику.
Чим відрізняються опціональні поля від факультативних? Опціональні стають обов'язковими, коли виникає правова умова (напр. ставка при звільненому продажу) — їхній брак наражає на санкції. Факультативні (GTU, PKWiU, колонтитул, додатковий опис) повністю добровільні, і їх пропуск не має податкових наслідків.
Чи треба заповнювати коди GTU на кожній фактурі? Ні. Коди GTU (01–13) стосуються винятково визначених груп товарів і послуг. Для звичайного продажу послуг чи товарів поза списком поле лишається порожнім, і фактура повністю коректна.
Чи має фактура в іноземній валюті містити суми в PLN? Частково. Суми нетто й брутто можуть бути виражені в іноземній валюті (KodWaluty ≠ PLN), але сума ПДВ у полі P_14_xW має завжди бути перерахована на злоті відповідно до ст. 31a Закону про ПДВ.