Схема FA(3): які поля е-фактури насправді обов'язкові

KSeF (Krajowy System e-Faktur — польська національна система е-фактур) відхиляє фактуру за частку секунди, коли бракує NIP (податковий номер) продавця або одного з обов'язкових блоків. Це якраз легко помітити — отримуєте помилку й виправляєте. Гірша інша категорія: поля, які виглядають необов'язковими, але стають обов'язковими, щойно виникає конкретна правова умова. Цих KSeF не перевіряє. Фактуру прийме, присвоїть номер, а проблема випливе аж під час перевірки JPK_V7 (реєстр ПДВ).

Від 1 лютого 2026 р. логічна структура FA(3) — єдиний прийнятний формат фактури в KSeF; вона замінила FA(2). За чинним законом штрафи за ст. 106ni закону про VAT діють з 1 січня 2027 року. 16 вересня 2026 року Міністерство фінансів оголосило про їх перенесення на 1 січня 2028 року — це законопроєкт, ще не ухвалений, і він переносить лише штрафи, а не сам обовʼязок працювати в KSeF. Тому саме зараз — реальний момент, щоб упорядкувати дані, поки ціна помилки ще нульова.

Нижче ми розкладаємо схему на три рівні обов'язковості й показуємо, які поля треба заповнювати завжди, які лише за умови, а які — не треба взагалі.

Три рівні обов'язковості — і чому це не просто термінологія

Схема FA(3) — це файл XSD, опублікований Міністерством фінансів Польщі в Центральному репозиторії зразків документів (простір імен http://crd.gov.pl/wzor/2025/06/25/13775/). Кожне поле має один із трьох рівнів:

1. Обов'язкові — мають бути заповнені в кожній фактурі. Брак = відхилення файлу системою KSeF.

2. Опціональні (умовно обов'язкові) — заповнюєте обов'язково, але лише коли виникає конкретна правова умова. KSeF не перевіряє, чи умова настала — відповідальність лежить на платнику.

3. Факультативні — заповнення залежить винятково від вас. Пропуск не має наслідків.

Найбільше клопоту завдає другий рівень, бо інтуїція підказує «опціональне поле = можна пропустити». У FA(3) це хибне припущення. Поле ставки при звільненому продажу, позначення split payment чи внутрішньоспільнотної поставки технічно опціональні, але юридично обов'язкові — і валідатор KSeF вас не зупинить.

Чотири блоки, без яких KSeF відхилить фактуру

Головна схема FA(3) складається з кількох надрядкових блоків. Чотири з них обов'язкові беззастережно в кожній фактурі:

• Naglowek (заголовок) — технічні дані документа: код формуляра (FA), варіант формуляра (3), дата створення.

• Podmiot1 (продавець) — NIP і повна назва обов'язкові. Брак NIP продавця гарантує відхилення.

• Podmiot2 (покупець) — тут перша пастка (див. нижче).

• Fa — центральний блок із даними транзакції: дата виставлення (P_1), номер фактури (P_2), код валюти, вид фактури, підсумки ПДВ і позиції.

Спрощений каркас показує, як небагато треба, щоб фактура була технічно коректною:

<Faktura>
  <Naglowek>
    <KodFormularza kodSystemowy="FA (3)" wersjaSchemy="1-0E">FA</KodFormularza>
    <WariantFormularza>3</WariantFormularza>
    <DataWytworzeniaFa>2026-06-21T10:00:00Z</DataWytworzeniaFa>
  </Naglowek>
  <Podmiot1>
    <DaneIdentyfikacyjne>
      <NIP>1234567890</NIP>
      <Nazwa>ITCompass Artem ...</Nazwa>
    </DaneIdentyfikacyjne>
    <Adres>
      <KodKraju>PL</KodKraju>
      <AdresL1>ul. Przykładowa 1</AdresL1>
      <AdresL2>00-001 Warszawa</AdresL2>
    </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>
      <Zwolnienie>
        <P_19N>1</P_19N>
      </Zwolnienie>
      <NoweSrodkiTransportu>
        <P_22N>1</P_22N>
      </NoweSrodkiTransportu>
      <P_23>2</P_23>
      <PMarzy>
        <P_PMarzyN>1</P_PMarzyN>
      </PMarzy>
    </Adnotacje>
    <RodzajFaktury>VAT</RodzajFaktury>
    <FaWiersz>
      <NrWierszaFa>1</NrWierszaFa>
      <P_7>Послуга з програмування</P_7>
      <P_11>1000.00</P_11>
      <P_12>23</P_12>
    </FaWiersz>
  </Fa>
</Faktura>

Каркас оглядовий. Точні назви атрибутів і формат полів завжди беріть з офіційного файлу XSD.

Пастка, про яку легко забути: у Podmiot2 поля JST (одиниця місцевого самоврядування) і GV (група ПДВ) обов'язкові. Навіть якщо фактура не стосується самоврядування чи групи ПДВ, треба вписати значення 2 («не стосується»).

Позиція фактури: що справді має в ній бути

В елементі FaWiersz (позиція) схема вимагає лише одного поля, а ще два вимагає закон про VAT:

• NrWierszaFa — порядковий номер позиції; єдине поле позиції, якого вимагає схема XSD. Без нього файл відхиляється.

• P_7 — назва товару або послуги. У схемі опціональна, але за загальним правилом вимагається законом; виняток — коригувальні фактури, що документують гуртові знижки за цілий період. Поле вміщує до 512 символів.

• P_12 — ставка ПДВ. У схемі опціональна (у деяких випадках зі ст. 106e закону про VAT її можна пропустити), але за загальним правилом вимагається законом, а якщо вказана, має бути допустимого значення, напр. 23, 8, 5, zw, np I, 0 KR, 0 WDT.

Деталь, що збиває з пантелику інтеграторів: FaWiersz за загальним правилом не містить суми ПДВ для окремої позиції. Сума податку потрапляє до підсумку документа (поля P_13_x нетто й P_14_x ПДВ, за ставкою), з P_15 як загальною сумою до сплати. Виняток — поле P_11Vat: сума податку в позиції у випадку зі ст. 106e ч. 10 закону про VAT. Поле P_6A (дата поставки в позиції) опціональне — заповнюєте лише тоді, коли окремі позиції мають різні дати продажу. Поля на кшталт Indeks, GTIN, PKWiU, CN факультативні.

Adnotacje: вісім елементів, які не можна пропускати

Блок Adnotacje (примітки) обов'язковий, і схема вимагає в ньому восьми елементів — жодного не можна опускати. П'ять із них — позначки типу «так/ні» (1 = так, 2 = ні). Ще три — блоки з вибором між «не стосується» (1) і повною версією:

• P_16 — касовий метод

• P_17 — самофактурування

• P_18 — зворотне нарахування (reverse charge)

• P_18A — механізм розділеного платежу (MPP, split payment)

• Zwolnienie (звільнення) — або P_19N = 1 (звільнених поставок немає), або P_19 = 1 із правовою підставою в P_19A, P_19B чи P_19C

• NoweSrodkiTransportu (нові транспортні засоби) — або P_22N = 1 (таких поставок немає), або P_22 = 1 з описом транспортних засобів

• P_23 — спрощена процедура в трикутних транзакціях

• PMarzy (процедура маржі) — або P_PMarzyN = 1 (процедури маржі немає), або P_PMarzy = 1 із зазначенням виду процедури

Тобто навіть «звичайний» продаж потребує п'яти двійок і трьох позначок «не стосується» (P_19N, P_22N, P_PMarzyN, кожна зі значенням 1). Повні версії цих блоків (P_19 для звільнення з правовою підставою в P_19A/B/C, P_22 для нових транспортних засобів, P_PMarzy для процедури маржі) заповнюєте лише тоді, коли випадок має місце.

«Опціональні» поля — пастка, яку KSeF не виявить

Це найважливіша частина. Наведені позначки схема пропустить у будь-якому вигляді, але вони юридично обов'язкові, коли виникає умова, — а KSeF прийме фактуру без належної позначки:

• P_18A = 1 при split payment. Обов'язок розділеного платежу стосується фактур, брутто-сума яких перевищує 15 000 zł і які містять позиції з додатка № 15 до Закону про ПДВ (ст. 108a). KSeF не знає ні граничної суми, ні предмета — не перевірить цього. Брак позначки наражає продавця на санкції.

• Ставка 0 WDT при внутрішньоспільнотній поставці товарів. Таку поставку позначають ставкою 0 WDT у полі P_12; позначка P_22 стосується лише нових транспортних засобів, а не кожної поставки WDT. Ставка, що не відповідає виду транзакції, не блокує файл, але псує реєстр JPK_V7.

• 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 (вимагає закон про VAT).

• Adnotacje: усі вісім елементів присутні — п'ять позначок (P_16, P_17, P_18, P_18A, P_23) мають значення 1 або 2, а Zwolnienie, NoweSrodkiTransportu і PMarzy заповнені (хоча б як P_19N, P_22N, P_PMarzyN).

• Правові умови: split payment (P_18A=1), WDT (ставка 0 WDT), звільнення (P_19 + підстава) позначені, якщо стосуються.

• Іноземна валюта: суми нетто/брутто можуть бути у валюті, але ПДВ (P_14_xW) завжди в PLN.

Підсумок

У FA(3) важлива не стільки кількість полів, скільки розуміння трьох рівнів обов'язковості. Чотири обов'язкові блоки й кілька полів у позиції вирішують, чи KSeF узагалі прийме файл. Але саме «опціональні» поля — split payment, WDT, підстава звільнення — відповідають за більшість проблем під час перевірки, бо система їх не контролює.

Biurko перевіряє кожну фактуру за офіційною схемою XSD ще перед надсиланням, за замовчуванням виставляє потрібні позначки (зокрема JST/GV та примітки) і перекладає 28 найпоширеніших кодів відхилення KSeF на зрозуміле повідомлення (решту показує текстом Міністерства фінансів) замість сирого коду помилки. Замість вчити структуру XML напам'ять, ви заповнюєте форму, а коректність контролює система. Спробуйте Biurko безкоштовно 14 днів і виставте першу фактуру FA(3) із перевіркою схеми перед відправленням.

FAQ

Які поля у FA(3) беззастережно обов'язкові? Беззастережно потрібні чотири блоки: Naglowek, Podmiot1 (з NIP і назвою продавця), Podmiot2 та Fa. У позиції схема вимагає лише номера позиції; назву товару/послуги (P_7) і ставку ПДВ (P_12) вимагає закон про VAT, а не схема. Без блоків і полів, яких вимагає схема, KSeF відхиляє файл.

Чи перевіряє KSeF, що я застосував split payment? Ні. KSeF не знає ні граничної суми, ні предмета транзакції, тому не перевіряє обов'язку MPP. Поле P_18A схема вимагає завжди, але значення 1 (split payment) юридично обов'язкове, коли фактура перевищує 15 000 zł брутто й містить позиції з додатка № 15. Відповідальність лежить на платнику.

Чим відрізняються опціональні поля від факультативних? Опціональні стають обов'язковими, коли виникає правова умова (напр. ставка при звільненому продажу) — їхній брак наражає на санкції. Факультативні (GTU, PKWiU, колонтитул, додатковий опис) повністю добровільні, і їх пропуск не має податкових наслідків.

Чи треба заповнювати коди GTU на кожній фактурі? Ні. Коди GTU (01–13) стосуються винятково визначених груп товарів і послуг. Для звичайного продажу послуг чи товарів поза списком поле лишається порожнім, і фактура повністю коректна.

Чи має фактура в іноземній валюті містити суми в PLN? Частково. Суми нетто й брутто можуть бути виражені в іноземній валюті (KodWaluty ≠ PLN), але сума ПДВ у полі P_14_xW має завжди бути перерахована на злоті відповідно до ст. 31a Закону про ПДВ.