KSeF і VAT marża. Як виставити рахунок-фактуру

Рахунок-фактура VAT marża в KSeF є структурованим XML-документом FA(3), але стосується особливого способу оподаткування за ст. 119 або ст. 120 Закону Польщі про ПДВ. KSeF не створює нової процедури маржі й не вирішує за компанію, чи можна застосувати її до конкретної операції.

У FA(3) ключове значення мають позначення процедури маржі, зокрема P_PMarzy та відповідний докладний варіант. Посібник Міністерства фінансів Польщі та KSeF також рекомендує P_13_11 для загальної вартості продажу за процедурою маржі, але це поле не слід описувати як просту безумовну вимогу для кожного випадку без аналізу конкретної структури.

Найбільший операційний ризик полягає в змішуванні чотирьох рівнів: податкового рішення про право на процедуру маржі, рахунка-фактури XML FA(3), читабельної PDF-візуалізації та позначень JPK, таких як MR_T і MR_UZ. Ці елементи пов'язані, але не є одним і тим самим.

KSeFGPT може допомагати з імпортом, перевіркою даних, роботою з XML FA(3), пошуком рахунків-фактур і підготовкою інформації для бухгалтерії. Його не слід вважати інструментом, який автоматично кваліфікує операцію до процедури VAT marża.

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

Стаття описує стан на 29 червня 2026 року. Її обсяг навмисно вузький: рахунок-фактура, поля FA(3), межа з JPK і процес контролю в малій компанії. Ми не вирішуємо, чи конкретний товар, автомобіль або послуга відповідає умовам процедури маржі.

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

1. Як працює процедура маржі за Законом Польщі про ПДВ

2. Чого рахунок-фактура VAT marża не показує покупцеві

3. Мапа рахунка-фактури VAT marża у FA(3)

4. Де закінчується рахунок-фактура й починається JPK

5. Процес малої компанії перед надсиланням до KSeF

6. Сценарій автомобільного комісу

7. Найпоширеніші помилки у VAT marża

8. Як KSeFGPT допомагає, не приймаючи податкового рішення

9. Погляд експерта

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

У таблиці зібрано головні рішення й відмінності, які потрібно врахувати перед виставленням рахунка-фактури VAT marża в KSeF.

У Законі Польщі про ПДВ є два головні напрями процедури маржі, важливі для цієї статті. Стаття 119 стосується туристичних послуг і визначає, що базою оподаткування є сума маржі, зменшена на суму належного податку. Стаття 120 стосується, зокрема, постачання вживаних товарів, творів мистецтва, предметів колекціонування й антикваріату.

Для туристичних послуг маржа є різницею між сумою, яку має сплатити покупець послуги, та фактичними витратами на придбання товарів і послуг в інших платників податків для безпосередньої користі туриста. Для вживаних товарів і подібних категорій ст. 120 визначає маржу як різницю між сумою продажу й сумою придбання, зменшену на суму податку.

Практичний поділ: туристична агенція перевіряє ст. 119, а коміс або магазин уживаних товарів - ст. 120. Технічна умова: лише після такого рішення можна правильно підготувати рахунок-фактуру у FA(3). Ризик: сам факт, що товар уживаний, ще не означає автоматичного права на VAT marża.

Власник компанії має відокремити податкове питання від технічного. Податкове питання звучить так: чи відповідає операція умовам процедури? Технічне питання: як після цього рішення правильно записати рахунок-фактуру у структурі FA(3)?

Коли межа між ст. 119 і ст. 120 зрозуміла, можна перейти до того, що покупець бачить у самому рахунку-фактурі.

Рахунок-фактура VAT marża відрізняється від звичайного тим, що не показує покупцеві стандартного поділу бази оподаткування й податку. Посібник KSeF 2.0 вказує, що рахунок-фактура за процедурою маржі не містить, зокрема, ціни одиниці нетто, вартості продажу нетто, ставки податку, загальних сум продажу нетто за ставками та сум податку від цих значень.

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

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

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

Коли зрозуміло, чого рахунок-фактура за процедурою маржі не показує як звичайний документ, можна перейти до полів FA(3), що описують процедуру.

Посібник KSeF 2.0 підтверджує, що FA(3) підтримує рахунки-фактури VAT marża для туристичних послуг, постачання вживаних товарів, творів мистецтва, предметів колекціонування й антикваріату. Головним місцем є елемент позначень PMarzy, у якому декларується застосування або відсутність процедури маржі.

На практиці це означає поле P_PMarzy та один із докладних варіантів: P_PMarzy_2 для туристичних агенцій, P_PMarzy_3_1 для вживаних товарів, P_PMarzy_3_2 для творів мистецтва або P_PMarzy_3_3 для предметів колекціонування й антикваріату. XSD FA(3) також описує P_PMarzyN для випадку, коли процедура не застосовується.

P_13_11 потребує обережного опису. XSD FA(3) визначає його як загальну вартість продажу за процедурами маржі зі ст. 119 і ст. 120, а посібник Міністерства фінансів Польщі та KSeF рекомендує зазначати це поле в рахунку-фактурі VAT marża. Однак не слід спрощувати це до твердження, що програма завжди сама знає, коли і як заповнити P_13_11 без рішення людини.

Контроль перед надсиланням: перевірте вид процедури, потрібне формулювання в рахунку-фактурі, варіант P_PMarzy, загальну суму до сплати в P_15 і можливе P_13_11 відповідно до генератора, схеми й бухгалтерської процедури. Контроль після надсилання: збережіть номер KSeF і UPO.

Коли мапа полів рахунка-фактури готова, можна перейти до позначень JPK, які працюють на іншому рівні.

Рахунок-фактура в KSeF і JPK_VAT не є одним файлом. FA(3) описує окремий рахунок-фактуру. JPK_VAT із декларацією описує облік і розрахунок за звітний період. Це важливо для VAT marża, оскільки позначення процедури в рахунку-фактурі не є тим самим, що позначення MR_T або MR_UZ у JPK.

Офіційна брошура JPK_VAT, чинна з 1 лютого 2026 року, вказує, що MR_T стосується туристичних послуг, оподаткованих за процедурою маржі відповідно до ст. 119, а MR_UZ - постачання вживаних товарів, творів мистецтва, предметів колекціонування й антикваріату, оподаткованих за процедурою маржі відповідно до ст. 120.

Та сама брошура пояснює, що поля процедур, зокрема MR_T і MR_UZ, заповнюють для всього документа значенням 1, коли процедура застосовувалася, і залишають порожніми, коли її не було. Брошура також визначає SprzedazVAT_Marza як вартість продажу брутто постачання товарів і надання послуг, оподаткованих за процедурою маржі.

Послідовність контролю: спершу узгодьте процедуру з бухгалтерією, потім створіть правильну FA(3), збережіть статус KSeF і лише в обліковому процесі подбайте про належні позначення JPK. Не визначайте GTU лише за словами VAT marża без окремої перевірки товару або послуги.

Після відокремлення рахунка-фактури від JPK можна перейти до процесу, який мала компанія впроваджує перед надсиланням.

Найбезпечніший процес починається до виставлення рахунка-фактури. Особа, відповідальна за продаж, має знати, чи передбачено для операції процедуру маржі, але податкове рішення власник повинен підтвердити з бухгалтером або радником. Лише потім варто готувати XML FA(3).

У процесі потрібно розділити ролі. Відділ продажів надає дані операції. Бухгалтерія підтверджує підставу зі ст. 119 або ст. 120. Програма для виставлення рахунків-фактур створює FA(3). Особа, яка надсилає документ, перевіряє статус KSeF, номер KSeF і UPO. Облік ПДВ проходить окремий контроль JPK.

Список контролю перед надсиланням: підтверджено право на маржу, вибрано правильний вид процедури, застосовано належне формулювання в рахунку-фактурі, не показано стандартну ставку ПДВ як у звичайному документі, перевірено P_PMarzy і докладний варіант, перевірено P_15, проаналізовано P_13_11 відповідно до посібника й генератора, підготовлено дані для JPK без змішування їх з XML FA(3).

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

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

Припустімо, автомобільний коміс виставляє близько 20 рахунків-фактур на місяць. Частина стосується автомобілів, придбаних за моделлю, яку бухгалтерія кваліфікує до процедури маржі, а частина може потребувати звичайного виставлення рахунків. Найгіршим процесом було б позначення всіх автомобілів як VAT marża лише тому, що вони вживані.

Безпечний процес є складнішим, але зрозумілим. Для кожного автомобіля потрібні документ придбання, рішення бухгалтерії, правильний тип рахунка-фактури, належне формулювання процедури, правильний XML FA(3), номер KSeF після прийняття та інформація для JPK. Нові транспортні засоби в окремому сценарії внутрішньоспільнотного постачання додатково виключені з положень частин 1-20 ст. 120 на підставі ч. 21 ст. 120.

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

Додаткова цінність для компанії проста: програма не повинна приховувати процедуру, а має показувати перелік документів для контролю. Бухгалтерія повинна швидко бачити, які рахунки містять P_PMarzy, які потребують MR_UZ, а які не слід об'єднувати зі звичайним продажем.

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

Перша помилка полягає в надмірній автоматизації податкового рішення. Програма може перевірити наявність полів, узгодженість даних і статус документа, але не повинна самостійно вирішувати, що операція відповідає умовам ст. 119 або ст. 120.

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

Третя помилка - змішування полів FA(3) із позначеннями JPK. P_PMarzy та докладний варіант є елементами рахунка-фактури. MR_T і MR_UZ є обліковими позначеннями. GTU потрібно аналізувати окремо за видом товару або послуги, а не лише за словами VAT marża.

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

Коли зрозуміло, де виникають помилки, можна перейти до ролі KSeFGPT у цьому процесі.

У цьому процесі KSeFGPT слід представляти як приватну програму для роботи з рахунками-фактурами KSeF, а не як державну послугу або податкового радника. Належна роль інструмента - імпорт даних, перевірка XML FA(3), фільтрування рахунків-фактур, статуси, номери KSeF, UPO та підготовка інформації для бухгалтерії.

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

Приклади застосування: імпорт файлу або даних рахунка-фактури, перегляд XML, упорядкування статусів, пошук документів із номером KSeF, підготовка експорту для бухгалтерії та перевірка списку рахунків на операційні пропуски. Ці функції не слід описувати як автоматичне визначення права на процедуру VAT marża.

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

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

VAT marża належить до тем, у яких помилка часто виникає ще до створення XML. Якщо компанія не має задокументованого рішення, чому операція підпадає під ст. 119 або ст. 120, правильно оформлений рахунок-фактура в KSeF не розв'язує проблеми.

Тому надійний процес має починатися з кваліфікації операції, а не з вибору поля в генераторі. Лише після податкового рішення варто розглядати P_PMarzy, P_13_11, P_15, MR_T або MR_UZ. Зворотний порядок створює ризик, що користувач намагається пристосувати закон до форми.

Особливо обережно слід ставитися до продажу вживаних автомобілів. Це поширений бізнес-приклад, але умови придбання, статус попереднього продавця та законодавчі виключення можуть мати значення. Самого слова вживаний недостатньо для безпечної кваліфікації.

Впровадження KSeF не повинно усувати людський контроль із процесу маржі. Воно має зробити рішення, поля XML, номер KSeF, UPO й позначення JPK видимими, узгодженими та обґрунтованими під час подальшої перевірки.

Чи можна виставити рахунок-фактуру VAT marża в KSeF? Так. Посібник KSeF 2.0 вказує, що структура FA(3) дозволяє виставляти рахунки-фактури VAT marża для туристичних послуг, вживаних товарів, творів мистецтва, предметів колекціонування й антикваріату. Однак KSeF не створює окремої податкової процедури. Документ має відповідати належним положенням Закону Польщі про ПДВ.

Чи зазначають у рахунку-фактурі VAT marża ставку й суму ПДВ? Посібник KSeF 2.0 вказує, що рахунок-фактура за процедурою VAT marża не містить, зокрема, ціни одиниці нетто, вартості продажу нетто, ставки податку, загальної суми продажу нетто за ставками та сум податку від цих значень. Суму до сплати покупцем потрібно відокремлювати від внутрішнього розрахунку маржі продавця.

Що означає P_13_11 у рахунку-фактурі VAT marża? XSD FA(3) описує P_13_11 як загальну вартість продажу за процедурами маржі, передбаченими ст. 119 і ст. 120 Закону Польщі про ПДВ. Посібник Міністерства фінансів Польщі та KSeF рекомендує використовувати це поле для рахунка-фактури VAT marża, але його не слід подавати як автоматичне рішення програми без перевірки конкретного випадку.

Чи кожен уживаний автомобіль можна продати за рахунком-фактурою VAT marża? Ні. Стаття 120 Закону Польщі про ПДВ встановлює умови, що стосуються, зокрема, виду товару, мети придбання й оподаткування попереднього постачання. Нові транспортні засоби в окремому сценарії внутрішньоспільнотного постачання виключені з положень частин 1-20 ст. 120. Автокоміс має підтвердити право на процедуру з бухгалтерією до виставлення рахунка-фактури.

Читайте далі: KSeF для малого бізнесу - як упорядкувати базовий процес KSeF, ролі та співпрацю з бухгалтерією.

Авансовий рахунок-фактура в KSeF пояснює, як розділити податкове рішення, тип документа й зв'язки між рахунками-фактурами.

Самофактурування в KSeF описує особливі ролі та позначення під час виставлення рахунків-фактур покупцем.

XML і формат FA(3) у KSeF допомагає зрозуміти, чому формальним рахунком-фактурою в KSeF є структурований XML, а не PDF.