XML та схема FA(3) у KSeF - посібник для бізнесу

Резюме

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

Схема FA(2) була попередньою версією структури рахунку-фактури. З 2026 року обов'язковою є FA(3). Якщо ваша система досі використовує FA(2), рахунки-фактури будуть відхилятися.

Неправильний XML - це відхилений рахунок-фактура, а відхилений рахунок-фактура юридично не існує. Перевірка перед надсиланням є необхідністю, а не опцією.

Зміст

1. Що таке XML - і чому KSeF його вимагає

2. Схема FA(2) - що означає ця назва і звідки вона походить

3. Структура рахунку-фактури у FA(2) - ключові елементи XML

4. FA(2) проти FA(3) - що змінилося і що зараз діє

5. Чому XML і схема FA важливі для інтеграції з KSeF

Ключові висновки

Таблиця нижче підсумовує найважливіші висновки статті - по одному реченню на кожен розділ.

Що таке XML - і чому KSeF його вимагає

XML (eXtensible Markup Language) - це текстовий формат для збереження даних у вигляді, зрозумілому як людям, так і машинам. Це не мова програмування і не програмне забезпечення - це метод організації інформації за допомогою тегів. Кожен елемент даних описується парою відкриваючого та закриваючого тегів; назва контрагента, сума рахунку-фактури або ідентифікаційний номер NIP зберігаються у чітко позначених полях.

Найкраща аналогія - офіційний бланк. Вільний лист може містити ту саму інформацію, що й заповнений бланк, але чиновнику може знадобитися багато часу, щоб знайти відповідь на конкретне запитання. Бланк з визначеними полями дає відповідь одразу. XML працює точно так само: замість вільного тексту є точно позначені поля, які система може зчитувати автоматично.

PDF працює зовсім інакше. Файл PDF - це, по суті, візуальний опис документа - він повідомляє принтеру та екрану, де намалювати текст, скільки пікселів він повинен займати і як виглядати. Людина бачить рахунок-фактуру. Система бачить зображення. Там немає даних, які комп'ютер міг би обробити без додаткового розпізнавання тексту (OCR). Саме тому KSeF не приймає PDF як дійсні рахунки-фактури.

Міністерство фінансів обрало XML з кількох причин. По-перше, XML є машинозчитуваним: система може перевірити, чи має NIP 10 цифр, чи збігаються суми та чи заповнені всі обов'язкові поля - без участі людини. По-друге, XML є валідованим: документ можна перевірити відповідно до шаблону (так звана XSD-схема) ще до надсилання. По-третє, XML є інтероперабельним: кожна ERP-система, програма та сервер можуть читати його однаково, незалежно від постачальника програмного забезпечення.

Підсумовуючи відмінність, яку повинен пам'ятати кожен підприємець: PDF - для очей, XML - для систем. KSeF - це система, а не людина - звідси вимога XML.

Схема FA(2) - що означає ця назва і звідки вона походить

XSD-схема - це шаблон, що описує, як має виглядати правильний XML-документ. Можна думати про неї як про рецепт: рецепт вказує, які інгредієнти використовувати, в якому порядку та в яких пропорціях. XSD-схема повідомляє XML-документу, які елементи мають бути присутніми, які типи даних допустимі (наприклад, дата повинна мати формат РРРР-ММ-ДД) і які зв'язки мають бути між полями. Рахунок-фактура XML, що не відповідає схемі, схожий на страву, приготовлену не за рецептом - результат може бути неїстівним.

Абревіатура FA походить від польського слова для рахунку-фактури. FA(1), FA(2) та FA(3) - це послідовні версії XSD-схеми для структурованих рахунків-фактур у KSeF, що публікуються Міністерством фінансів. FA(1) використовувалася під час пілотної фази системи. FA(2) діяла в період добровільного використання KSeF - компанії могли, але не були зобов'язані виставляти рахунки-фактури через систему. FA(3) є обов'язковою схемою, введеною з поетапним запуском обов'язкового KSeF.

Чому варто знати, що таке FA(2), якщо вона більше не діє? Документація ERP-систем, галузеві статті, посібники та внутрішні процедури багатьох компаній були створені на основі FA(2). Якщо ви стикаєтесь із прикладами полів, описами вузлів XML або інструкціями з налаштування системи, що посилаються на FA(2), ви повинні знати, що маєте справу з застарілою версією. Наслідки можуть бути серйозними: рахунок-фактура, надісланий у форматі FA(2) до KSeF у 2026 році, буде відхилений.

Важлива дата: з 1 лютого 2026 року єдиною схемою, прийнятою KSeF, є FA(3). Це стосується великих компаній (валовий обсяг продажів понад 200 млн злотих у 2024 році). З 1 квітня 2026 року зобов'язання поширюється на всіх інших платників ПДВ. FA(2) більше не приймається системою - і кожен рахунок-фактура, надісланий у цьому форматі, буде автоматично відхилений без виключень.

Структура рахунку-фактури у FA(2) - ключові елементи XML

Щоб зрозуміти FA(3) та можливі проблеми міграції з FA(2), варто ознайомитися з базовою структурою XML-рахунку-фактури у KSeF. Документ поділений на кілька основних вузлів, кожен з яких відповідає за певну частину даних рахунку-фактури. Вузли - це не що інше, як розділи документа - як глави в контракті.

Podmiot1 - це розділ, що описує продавця - виписувача рахунку-фактури. Він містить ідентифікаційні дані компанії: NIP, назву та адресу. Це поле є обов'язковим і повинно точно відповідати даним, зареєстрованим у податкових реєстрах. Podmiot2 - це відповідний розділ для покупця. Він також містить NIP, назву та адресу. У разі операцій з фізичною особою, яка не веде підприємницьку діяльність, поле є необов'язковим або заповнюється особливим чином.

Вузол Fa - це заголовок рахунку-фактури, його метадані. Тут знаходяться: номер рахунку-фактури (P_2), дата виписки (P_1), дата продажу (P_6), тип документа (P_15), валюта (KodWaluty), умови оплати (TerminPlatnosci) та інші ключові атрибути. FaWiersz - це позиція рахунку-фактури, один рядок відповідає одному товару або послузі. Він містить опис товару або послуги, кількість, одиницю виміру, ціну нетто за одиницю, ставку ПДВ та суми. Рахунок-фактура може мати кілька таких рядків. Podsumowanie - це вузол, що агрегує суми ПДВ за ставками - загальну суму нетто, ПДВ та суму брутто.

Які поля найчастіше спричиняють помилки валідації? Досвід впровадження показує, що проблеми концентруються у кількох місцях. NIP повинен мати рівно 10 цифр та пройти перевірку контрольної суми - префікс PL та пробіли не допускаються у полі, призначеному виключно для цифр. Дати повинні бути у форматі ISO 8601 (РРРР-ММ-ДД) - запис 15.04.2026 буде відхилений. Коди ставки ПДВ повинні відповідати словнику Міністерства фінансів, а не довільним описам. Суми повинні бути заокруглені відповідно до алгоритму KSeF - навіть різниця в один гріш призводить до відхилення.

FA(2) проти FA(3) - що змінилося і що зараз діє

Перехід з FA(2) на FA(3) - це не просто оновлення номера версії - це зміна вимог, яка безпосередньо впливає на те, як ERP-система або програма для виставлення рахунків-фактур повинна будувати XML-документ. Якщо ваш постачальник програмного забезпечення не оновив інтеграцію до FA(3), рахунки-фактури будуть відхилятися KSeF без будь-якого попередження, зрозумілого кінцевому користувачу.

Що нового запроваджує FA(3)? Передусім розширено можливості опису умов оплати - у FA(3) можна точно вказати кілька термінів оплати для одного рахунку-фактури, що важливо для розстрочених рахунків-фактур. Додано можливість додавати вкладення безпосередньо до XML-рахунку-фактури - раніше це було неможливо. Розширено поле номера банківського рахунку до стандарту IBAN. Додано нові коди спеціальних процедур, зокрема для операцій між пов'язаними сторонами (TP), механізму розщепленого платежу (MPP) та продажів через цифрові платформи (IED). Розширено коди GTU - ідентифікатори видів товарів та послуг, важливі для звітності JPK та декларацій з ПДВ.

Як перевірити, чи ваша система працює на FA(3)? Нижче наведено перелік питань до вашого постачальника ERP або бухгалтерської програми:

Коли востаннє ви оновлювали модуль KSeF у своїй системі? Чи включає оновлення схему FA(3), опубліковану Міністерством фінансів? Чи тестує система рахунки-фактури на демо-середовищі KSeF перед надсиланням? Яку версію XSD-схеми генерує ваш XML-експорт? Чи підтримує система нові поля FA(3): кілька термінів оплати, IBAN, коди TP та MPP? Як система поводиться, коли рахунок-фактура відхиляється KSeF?

Чому XML і схема FA важливі для інтеграції з KSeF

У системі KSeF рахунок-фактура або проходить валідацію та приймається, або відхиляється. Проміжного стану немає. Відхилений рахунок-фактура юридично не існує згідно з податковим законодавством - він не вважається виставленим, не може слугувати підставою для відрахування ПДВ покупцем та не зберігається у системі Міністерства фінансів. Його необхідно виправити та надіслати повторно.

Процес валідації у KSeF відбувається на трьох рівнях. Перший - це XSD-валідація структури: система перевіряє, чи правильно побудований XML - чи елементи знаходяться у правильному порядку, чи збігаються типи даних та чи присутні обов'язкові поля. Якщо файл не проходить цей етап, він не переходить до подальших перевірок. Другий - це бізнес-валідація: система перевіряє логічні правила - чи дата продажу не є пізнішою за дату виписки, чи є математично правильною сума ПДВ та чи мають податкові ідентифікатори правильний формат. Третій - це перевірка дублікатів: KSeF перевіряє, чи рахунок-фактура з таким самим номером, NIP продавця та типом документа вже був зареєстрований у системі (перевірка охоплює 10 років тому).

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

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

Перспектива: чому варто розуміти XML навіть без технічних знань

Власник бізнесу не повинен писати XML-код або запам'ятовувати специфікацію XSD-схеми. Але варто розуміти, що таке XML і навіщо він існує - хоча б тому, що ці знання захищають від сліпої довіри до програмного забезпечення. Якщо ви знаєте, що структурований рахунок-фактура - це файл даних, а не візуальний документ, ви також знаєте, що просте створення PDF у своїй бухгалтерській програмі не є рівнозначним виставленню рахунку-фактури у KSeF. Ця різниця коштує реальних грошей і часу, якщо її виявляють занадто пізно.

Найпоширеніша організаційна помилка компаній, що впроваджують KSeF, - це розподіл відповідальності: IT-відділ відповідає за технічну інтеграцію, а бухгалтерія - за змістову правильність рахунків-фактур - і ці два світи не спілкуються між собою на етапі налаштування. Передбачуваний результат - XML-файл, що є технічно правильним щодо XSD-схеми, але містить неправильні ставки ПДВ, неправильні коди GTU або відсутні позначення процедур. Такі рахунки-фактури проходять структурну валідацію, але спричиняють проблеми у податковому обліку.

Інструменти дедалі ефективніше абстрагують XML від кінцевого користувача. Хороша програма для виставлення рахунків-фактур або інтегрована ERP-система дозволяє виставляти правильний рахунок-фактуру KSeF без ручної роботи з XML-файлом. Але ця зручність має свою ціну: якщо система генерує неправильні дані, а користувач не розуміє, як побудований документ, помилка може довго залишатися непоміченою. Базові знання структури XML дають можливість ставити постачальнику програмного забезпечення правильні запитання: чи генеруєте ви FA(3) чи FA(2)? Де у XML зберігаються коди GTU? Чи валідація запускається до чи після надсилання?

Практична рекомендація: перш ніж запустити виробниче надсилання рахунків-фактур через KSeF, протестуйте повний цикл у демо-середовищі Міністерства фінансів. Виставлення рахунку-фактури, перевірка статусу валідації, отримання номера KSeF та UPO, а потім перевірка того, чи дані у системі відповідають тому, що ви очікували надіслати - це абсолютний мінімум перед запуском. Тестове середовище доступне безкоштовно і не впливає на реальні податкові декларації. Кожна година, витрачена на тести, - це година менше, яку ви витрачаєте на гасіння пожеж у виробничому середовищі.

Перевірте свої XML-рахунки-фактури перед надсиланням до KSeF

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

Найчастіші запитання

Чи FA(2) ще приймається KSeF? - Ні. З 1 лютого 2026 року (великі компанії) та з 1 квітня 2026 року (всі інші платники ПДВ) єдиною прийнятою схемою для структурованих рахунків-фактур є FA(3). Рахунок-фактура, надісланий у форматі FA(2), буде автоматично відхилений системою KSeF без надання номера KSeF.

Як перевірити, чи відповідає мій XML-файл FA(3)? - Найефективніший метод - це локальна валідація відповідно до XSD-схеми, опублікованої Міністерством фінансів. Ви можете скористатися XSD-валідатором, доступним онлайн, або інструментами редагування XML. Міністерство фінансів також надає тестове середовище KSeF (ksef-test.mf.gov.pl), де ви можете надіслати тестовий документ і перевірити, чи він пройде валідацію без впливу на реальні податкові декларації.

Чим XML-файл KSeF відрізняється від звичайного XML-файлу? - Кожен XML-файл KSeF повинен відповідати конкретній XSD-схемі, опублікованій Міністерством фінансів - наразі FA(3). Недостатньо, щоб файл був технічно правильним XML. Він повинен містити точно ті вузли, в точному порядку та з точними типами даних, що визначені у схемі FA(3). Крім того, файл повинен відповідати бізнес-правилам KSeF - наприклад, суми ПДВ повинні бути математично узгоджені з позиціями.

Що означає відхилення рахунку-фактури KSeF - чи потрібно його виставляти повторно? - Так. Відхилений рахунок-фактура не реєструється у системі KSeF, що означає, що за податковим законодавством він не був виставлений. Вам потрібно виправити XML-файл (видалити помилку, зазначену системою), а потім повторно надіслати рахунок-фактуру. Номер рахунку-фактури залишається тим самим - ви не створюєте новий документ, а виправляєте та повторно надсилаєте той самий. Виняток - якщо той самий номер рахунку-фактури вже був успішно зареєстрований - у цьому випадку KSeF відхилить документ як дублікат.

Рекомендовані статті

Читайте також: Валідація та обробка XML у KSeF - як система KSeF перевіряє документ перед присвоєнням номера KSeF. Конвертер PDF до KSeF XML - як перетворити PDF-рахунок-фактуру на правильний файл FA(3), готовий до надсилання. Найпоширеніші труднощі при впровадженні KSeF - помилки, нетипові випадки та аварійні процедури, що не описані в жодному законі. Чи можна надіслати PDF до KSeF? - коротка та конкретна відповідь на одне з найчастіших запитань про KSeF.