SAF-T в Україні у 2026 році: хто має подавати, структура файлу та підготовка до е-аудиту.

Коротко: SAF-T UA

• SAF-T UA — це XML-файл для е-аудиту, що передає деталізовані первинні дані до ДПС, а не підсумкову звітність: кожну проводку, кожен документ, кожен рух товарів.
• Наразі на запит ДПС подавати SAF-T зобов'язані насамперед великі платники; будь-яка компанія може отримати запит під час документальної перевірки.
• Файл складається з чотирьох блоків: Header, MasterFiles (довідники), GeneralLedgerEntries (проводки), SourceDocuments (первинні документи).
• Найчастіші причини відхилення файлу: неповні дані контрагентів, відсутні коди УКТ ЗЕД, розбіжності між проводками і первинними документами.
• Оптимальний перший крок — readiness assessment: перевірити джерела даних, маппінг плану рахунків, обов'язкові поля і технічну готовність до генерації SAF-T UA.

Що таке SAF-T UA і чим він відрізняється від звичайної звітності

Standard Audit File for Tax (SAF-T) — міжнародний стандарт XML-файлу для передачі детальних облікових і податкових даних від платника до податкового органу. Стандарт розроблений ОЕСР і вже застосовується в Польщі, Португалії, Норвегії, Литві та інших країнах.

SAF-T UA — адаптація цього стандарту для України. Ключова відмінність від звичайної звітності: замість підсумкових показників SAF-T передає деталізовані первинні дані — кожну бухгалтерську проводку, кожен рахунок, кожний рух товарів за обраний період. Це дає ДПС можливість аналізувати облік структуровано та автоматизовано в рамках документальної або камеральної перевірки.

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

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

Кому і коли потрібно подавати SAF-T в Україні

Великі платники податків

Основна зобов'язана категорія на сьогодні. Великі платники подають SAF-T на запит ДПС у межах документальної перевірки. Критерії віднесення до великих платників (обсяг доходів, сума сплачених податків) визначені Податковим кодексом України і можуть переглядатись, тому актуальний перелік слід уточнювати у реєстрі ДПС.

Компанії під час документальної перевірки

Будь-яка компанія, незалежно від розміру, може отримати запит на надання даних у форматі SAF-T під час документальної або фактичної перевірки. Підстава — стаття 85 Податкового кодексу України, що надає органам ДПС право вимагати документи у встановленому форматі. Готовність до такого запиту — питання операційної безпеки бізнесу.

Підприємства суспільного інтересу (ПСІ)

ПСІ мають обов'язок обов'язкового аудиту фінансової звітності (за МСА), але це не створює автоматичного обов'язку подавати SAF-T до ДПС. SAF-T і аудит за МСА — різні інструменти з різними правовими підставами. Якщо ПСІ є водночас великим платником — обов'язок SAF-T виникає з цієї підстави, а не зі статусу ПСІ.

Середній та малий бізнес

Наразі не зобов'язані подавати SAF-T в регулярному режимі. Однак отримати запит під час перевірки може будь-хто. Крім того, тенденція до поширення стандарту на ширше коло платників відповідає загальноєвропейській практиці, тому підготовча робота — маппінг рахунків, очищення довідників — виправдана вже зараз.

Поточний стан та очікувані зміни

Нижче — зведена таблиця по категоріях платників станом на травень 2026 року:

Категорія	Поточний статус	Підстава
Великі платники	Зобов'язані на запит ДПС	Наказ ДПС, ПКУ
Компанії під час перевірки	Зобов'язані на запит	ПКУ, ст. 85
ПСІ (лише за статусом)	Не мають автоматичного обов'язку SAF-T	—
Середній бізнес	Поки не зобов'язані	—
Малий бізнес	Не підпадають	—

Структура файлу SAF-T UA

SAF-T UA — це XML-файл з чітко визначеною структурою, що описана в офіційній XSD-схемі. Файл складається з чотирьох основних блоків:

Header (Заголовок)

Метадані файлу: ідентифікатор платника (ЄДРПОУ), звітний період, версія стандарту SAF-T UA, валюта обліку, дата і час генерації файлу. Заголовок дає ДПС первинний контекст для обробки решти даних.

MasterFiles (Довідники)

Загальна довідкова інформація, на яку посилаються всі транзакційні дані:

• Customers — довідник покупців з реквізитами та податковими номерами
• Suppliers — довідник постачальників
• Products — товари і послуги з кодами УКТ ЗЕД
• GeneralLedgerAccounts — план рахунків
• TaxTable — довідник ставок податків

Якість довідників — найкритичніший фактор успішної валідації. Навіть один контрагент без ІПН або товар без коду УКТ ЗЕД може призвести до відхилення файлу.

GeneralLedgerEntries (Журнал господарських операцій)

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

SourceDocuments (Первинні документи)

Деталізація первинних документів за категоріями:

• SalesInvoices — рахунки на продаж з повною деталізацією позицій
• PurchaseInvoices — рахунки на покупку
• Payments — платіжні документи
• MovementOfGoods — рух товарів (актуально для торгівлі та виробництва)

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

Які дані потрібні для формування SAF-T

SAF-T консолідує дані, що зазвичай зберігаються в різних системах та підрозділах компанії. Основні джерела:

• Фінансова система / ERP — бухгалтерські проводки, план рахунків, залишки
• Система продажів / CRM — рахунки-фактури на продаж, деталізація позицій, покупці
• WMS / складська система — рух товарів, списання, переміщення
• Система закупівель — рахунки від постачальників, умови оплати
• Банківська система / казначейство — платіжні документи, виписки

Якщо всі ці дані зберігаються в одній ERP — завдання спрощується. Якщо джерела різні (а для великих компаній це норма) — потрібна консолідація перед генерацією SAF-T.

Типові проблеми з даними

З досвіду підготовки SAF-T-файлів найчастіше виникають такі проблеми:

• Неповні дані контрагентів — відсутні ІПН, ЄДРПОУ, коди країн або адреси в довіднику
• Відсутні або неправильні коди УКТ ЗЕД — обов'язковий реквізит для товарів
• Розбіжності між системами — суми в журналі проводок не збігаються з первинними документами через різні дати рознесення
• Неструктуровані довідники — дублікати контрагентів, застарілі записи, помилки в реквізитах

Виявити і виправити ці проблеми до генерації SAF-T — значно ефективніше, ніж отримати сотні помилок валідації після.

SAF-T UA: що потрібно перевірити перед впровадженням

Як підготувати SAF-T: 5 ключових кроків

Крок 1. Аналіз джерел даних

Визначте, де зберігається кожен тип даних, необхідний для SAF-T: проводки, первинні документи, довідники контрагентів і товарів, платежі, рух товарів. Зафіксуйте формати, доступність і повноту даних у кожному джерелі. Це основа для всіх подальших кроків.

Крок 2. Маппінг плану рахунків

Внутрішній план рахунків компанії потрібно зіставити зі стандартним планом рахунків SAF-T UA. Це не завжди тривіально — особливо якщо у компанії кастомний або розширений план рахунків, або якщо бухгалтерський облік ведеться одночасно за декількома стандартами (П(С)БО і МСФЗ). Маппінг фіксується у таблиці відповідностей і стає частиною технічної документації рішення.

Крок 3. Очищення та збагачення довідників

Довідники контрагентів і товарів приводяться до вимог SAF-T UA: заповнення обов'язкових реквізитів, усунення дублікатів, додавання кодів УКТ ЗЕД, уточнення кодів країн. Цей крок нерідко виявляє системні проблеми в обліку, які раніше не впливали на звітність, але критичні для SAF-T.

Крок 4. Генерація XML відповідно до XSD-схеми

Після підготовки даних вони перетворюються на XML відповідно до офіційної XSD-схеми SAF-T UA. Генерація має враховувати точну структуру схеми: порядок елементів, обов'язкові поля, типи даних, формати дат і числових значень. Один структурний відступ від схеми — і файл не пройде XSD-валідацію.

Крок 5. Валідація (XSD + бізнес-правила)

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

Валідація: XSD та бізнес-правила

Валідація SAF-T — двохрівневий процес, і обидва рівні однаково важливі.

XSD-валідація (структурна)

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

Бізнес-валідація (логічна)

Перевіряє змістовну правильність даних. Типові правила:

• Сума дебету дорівнює сумі кредиту в кожній проводці
• Загальні суми по документах збігаються з сумами по позиціях
• Контрагенти, на яких є посилання в транзакціях, присутні у довіднику MasterFiles
• Дати операцій потрапляють у заявлений звітний період
• Податкові ставки відповідають записам у TaxTable
• Рахунки-фактури посилаються на валідні товари з довідника Products

Критично важливо, щоб інструмент валідації описував помилки зрозумілою мовою, а не просто вказував на номер рядка в XML. Повідомлення на кшталт "Контрагент ТОВ 'Приклад': відсутній ІПН у довіднику постачальників (рядок 14 573)" дозволяє виправити проблему за хвилини. Технічне "validation error at line 14573" може перетворити процес на багатогодинне розслідування.

Подача файлу до ДПС

Подача SAF-T здійснюється через електронний кабінет платника податків із застосуванням кваліфікованого електронного підпису (КЕП). Технічно — це завантаження XML-файлу через спеціальний сервіс ДПС.

Практичні аспекти подачі:

• Розмір файлу — для великих компаній файл SAF-T може сягати сотень мегабайтів і навіть кількох гігабайтів. Завантаження потребує стабільного з'єднання і може тривати тривалий час
• КЕП — підпис має бути чинним і відповідати вимогам ДПС на момент подачі
• Технічні збої — у разі помилки на стороні ДПС зберігайте докази успішного завантаження (квитанції, скриншоти, логи)

Подані файли SAF-T слід зберігати у власній інфраструктурі протягом строків зберігання первинних документів. Це і доказова база, і джерело для повторної подачі у разі технічних проблем.

Технічні рішення для підготовки SAF-T

Вибір технічного підходу залежить від архітектури IT-інфраструктури компанії, обсягів даних та частоти очікуваних запитів ДПС.

ERP-незалежні платформи

Спеціалізовані рішення, що підключаються до будь-яких джерел даних — незалежно від того, яка ERP або облікова система використовується. Головна перевага: здатність консолідувати дані з кількох систем одночасно (ERP + CRM + WMS + кастомні бази). Підходять для великих компаній зі складною IT-архітектурою, де дані розподілені між системами.

Аутсорсинг підготовки

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

Самостійна розробка

Компанії з потужними власними IT-командами іноді будують генератор SAF-T самостійно. Це реалістично за наявності досвіду роботи з XML-схемами великого обсягу та ресурсів на підтримку рішення при оновленнях XSD-схеми. Для більшості бізнесів — надмірна інвестиція.

Чому ERP-модуль не завжди достатній

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

Проблема 1: Дані в кількох системах. Фінанси — в ERP, продажі — в CRM, склад — в WMS, а іноді частина даних ще й у Excel. ERP-модуль збирає SAF-T лише зі свого джерела і не може отримати дані з інших систем без додаткової інтеграції.

Проблема 2: Неможливість консолідації між системами. SAF-T повинен відображати цілісну картину обліку. Якщо первинні документи й проводки рознесені між різними системами, ERP-модуль або пропустить частину даних, або вимагатиме ручного зведення.

Проблема 3: Продуктивність при великих обсягах. Генерація SAF-T для великої компанії — це обробка мільйонів записів. ERP-модулі часто не оптимізовані для таких задач і можуть виконуватись годинами або створювати навантаження на продуктивні системи.

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

SAF-T Connector від LUCAS

SAF-T Connector — власне рішення LUCAS для підготовки та валідації SAF-T-файлів, розроблене на Python. Створювалось як відповідь на реальні потреби великих українських підприємств з розподіленою IT-інфраструктурою.

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

ERP-незалежність. Connector підключається до будь-яких джерел: SAP, Odoo, Microsoft Dynamics, кастомні бази даних, Excel-файли. Якщо у компанії кілька систем — Connector консолідує дані з усіх у єдиний SAF-T-файл.

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

Впровадження під ключ за 3–4 місяці. LUCAS веде проєкт від аналізу джерел даних до першого успішно поданого файлу. У цей час входить маппінг плану рахунків, налаштування підключень, тестова валідація і навчання команди.

Детальніше про рішення — на сторінці SAF-T Connector.

Як LUCAS допомагає

LUCAS поєднує аудиторську методологію з технічною реалізацією. Це означає, що ми не просто налаштовуємо інструмент — ми розуміємо, які дані потрібні для SAF-T з позиції аудитора, і знаємо, де типово виникають проблеми в обліку реальних підприємств.

Як ми допомагаємо компаніям готуватись до SAF-T:

• Оцінка готовності даних — аналіз поточного стану облікових систем і довідників, виявлення прогалин до початку впровадження
• Маппінг плану рахунків — розробка таблиці відповідностей між внутрішнім планом і стандартом SAF-T UA
• Впровадження SAF-T Connector — налаштування підключень, конфігурація під специфіку клієнта, тестова генерація
• Тестова валідація — перевірка реальних даних і усунення помилок до першої офіційної подачі
• Супровід — підтримка при оновленнях XSD-схеми та змінах у нормативній базі

Маєте питання про SAF-T або хочете оцінити готовність вашої компанії? Зв'яжіться з нашою командою — розберемося разом.

У практиці LUCAS оцінка готовності до SAF-T майже завжди виявляє проблеми, про які клієнт не знав заздалегідь: довідники контрагентів із пропущеними ІПН, товари без кодів УКТ ЗЕД, дані, розкидані між трьома системами без консолідації. Виявити і виправити ці проблеми до першого запиту ДПС — значно дешевше, ніж у авральному режимі після отримання запиту.

Часті запитання

Що таке SAF-T UA?

SAF-T UA — це XML-формат для передачі детальних облікових і податкових даних від платника до ДПС у рамках е-аудиту. Абревіатура розшифровується як Standard Audit File for Tax, адаптований для України. На відміну від регулярної звітності, SAF-T містить первинні дані — кожну бухгалтерську проводку, кожен документ, кожен рух товарів за звітний період.

Чи є SAF-T податковою звітністю?

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

Які дані входять до SAF-T?

SAF-T UA містить чотири блоки даних: Header (ідентифікаційні дані платника і звітний період), MasterFiles (довідники контрагентів, товарів і план рахунків), GeneralLedgerEntries (журнал усіх бухгалтерських проводок за звітний період) та SourceDocuments (деталізація первинних документів: рахунки на продаж і купівлю, платежі, рух товарів).

Чи обов'язковий SAF-T для всіх підприємств України?

Ні. Наразі подавати SAF-T на запит ДПС зобов'язані насамперед великі платники податків. Будь-яка компанія може отримати запит під час документальної перевірки, але регулярна обов'язкова подача для середнього і малого бізнесу поки не запроваджена.

Чи зобов'язані ПСІ подавати SAF-T?

Статус підприємства суспільного інтересу (ПСІ) не створює автоматичного обов'язку подавати SAF-T до ДПС. Обов'язок аудиту фінансової звітності за МСА і обов'язок SAF-T — це різні правові інструменти. Якщо ПСІ також є великим платником — обов'язок SAF-T виникає з підстав великого платника.

Як часто потрібно подавати SAF-T?

SAF-T подається на запит ДПС у межах перевірки, а не автоматично щомісяця чи щоквартально. Тобто регулярного розкладу подачі немає — є обов'язок надати файл у встановлений строк після отримання запиту.

Що відбувається під час е-аудиту?

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

Чим SAF-T відрізняється від декларації з ПДВ?

Декларація з ПДВ — регулярна підсумкова звітність, що подається за встановленим графіком. SAF-T — деталізований файл з первинними даними (кожна проводка, кожен документ), що надається на запит. Обидва інструменти існують паралельно і не замінюють один одного.

Що таке XSD-валідація SAF-T?

XSD (XML Schema Definition) — офіційна схема, що описує допустиму структуру SAF-T-файлу: перелік тегів, їх порядок, обов'язкові поля, типи даних. XSD-валідація перевіряє, чи відповідає ваш файл цій схемі. Файл, що не пройшов XSD, не приймається системою — без розгляду змісту.

Які штрафи за ненадання SAF-T на запит ДПС?

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

Чи можна підготувати SAF-T без спеціального ПЗ?

Технічно для дуже малих компаній з кількома десятками операцій на місяць можливо. Для будь-якого підприємства з реальним оборотом — непрактично. SAF-T великої компанії містить мільйони XML-записів, і ручна генерація нереальна ні за часом, ні за якістю.

Що робити, якщо дані зберігаються в кількох системах?

Це типова ситуація для середніх і великих підприємств: фінанси в ERP, продажі в CRM, склад в WMS. Рішення — використовувати ERP-незалежну платформу, яка підключається до всіх джерел і консолідує дані в єдиний SAF-T-файл. ERP-модулі з однієї системи цю задачу не вирішують.

Скільки часу займає підготовка SAF-T-файлу?

Після впровадження рішення регулярна генерація SAF-T займає години, не дні. Саме впровадження — від аналізу даних до першого успішно поданого файлу — займає 3–4 місяці. Перша підготовка без готового рішення (вручну або силами команди з нуля) може тривати тижні.

Чи потрібно зберігати подані SAF-T-файли?

Так. Подані до ДПС файли слід зберігати у власній інфраструктурі протягом строків зберігання первинних документів (як правило, 1095 днів згідно з ПКУ, але є винятки). Збережений файл — це доказ виконання вимоги і резервна копія для повторної подачі.

Що таке бізнес-валідація SAF-T і чим вона відрізняється від XSD-валідації?

XSD-валідація перевіряє структуру файлу — правильність тегів і форматів. Бізнес-валідація перевіряє логіку даних — наприклад, чи збігається дебет з кредитом, чи всі контрагенти є в довіднику, чи відповідають дати операцій звітному періоду. Файл може пройти XSD, але не пройти бізнес-правила.

Чи підходить SAF-T Connector для компаній на SAP?

Так. SAF-T Connector від LUCAS є ERP-незалежним і підключається до SAP через стандартні інтерфейси. Компанії на SAP також можуть мати дані в інших системах — Connector консолідує їх усі в єдиний файл.

Як SAF-T пов'язаний з аудитом фінансової звітності?

Це різні інструменти. Аудит фінансової звітності (МСА) — незалежна перевірка звітності компанії аудитором для підтвердження її достовірності. SAF-T — інструмент ДПС для перевірки податкового обліку. Обидва процеси можуть відбуватись паралельно, але мають різні цілі, підстави і результати.

Чи є SAF-T обов'язковим для всіх великих платників без виключень?

SAF-T подається великими платниками на запит ДПС. Це означає, що обов'язок виникає при отриманні конкретного запиту, а не автоматично для кожного великого платника щомісяця. Тим не менш, бути готовим до такого запиту — обов'язок будь-якого великого платника.

Висновок для CFO

SAF-T — це не просто технічний XML-файл, а тест якості облікових даних компанії. Якщо довідники неповні, проводки не пов'язані з документами, а дані розкидані між ERP, CRM і складськими системами, файл буде складно сформувати і пройти валідацію. Тому оптимальний перший крок — readiness assessment: перевірити джерела даних, маппінг, обов'язкові поля і технічну готовність до генерації SAF-T UA.

Читайте також

• Хто зобов'язаний подавати SAF-T UA у 2026 році — великі платники, механізм «на запит ДПС» і хто ще повинен готуватись
• SAF-T UA для SAP, BAS та Odoo — порівняння підходів для різних ERP і мультисистемного середовища
• Валідація SAF-T UA: XSD-схема, бізнес-правила і типові помилки — що перевіряє кожен рівень і як виправляти помилки
• Readiness assessment і план впровадження SAF-T UA — покроковий план підготовки за 3–4 місяці