Найголовніше за хвилину

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

SAF-T UA і звичайна звітність: у чому різниця

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

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

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

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

Хто подає SAF-T в Україні

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

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

Будь-яка компанія під час перевірки

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

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

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

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

Регулярна обов’язкова подача наразі не запроваджена. Але запит під час перевірки може отримати будь-хто, а тенденція до розширення кола платників відповідає загальноєвропейській практиці — тож базова підготовча робота (мапінг рахунків, очищення довідників) виправдана вже зараз. Детальніше — у статті «Хто подає SAF-T UA».

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

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

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

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

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

MasterFiles — довідники

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

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

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

GeneralLedgerEntries — журнал операцій

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

SourceDocuments — первинні документи

Деталізація первинки за категоріями: SalesInvoices (рахунки на продаж із позиціями), PurchaseInvoices (рахунки на купівлю), Payments (платежі), MovementOfGoods (рух товарів — актуально для торгівлі та виробництва). Кожен документ містить заголовок, позиції, податкову інформацію та посилання на контрагентів і товари з MasterFiles.

Звідки беруться дані для файлу

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

Типові проблеми з даними, які виявляються на практиці:

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

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

Як підготувати SAF-T: п’ять кроків

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

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

XSD-валідація перевіряє структуру: теги, обов’язкові поля, типи даних, послідовність елементів, простори імен. Файл, який не проходить XSD, система не приймає взагалі — до змістовної перевірки справа не доходить.

Бізнес-валідація перевіряє логіку даних: дебет дорівнює кредиту в проводках; суми документів збігаються з сумами позицій; контрагенти з транзакцій присутні в MasterFiles; дати потрапляють у звітний період; ставки відповідають TaxTable. Детальний розбір типових помилок — у статті «Валідація SAF-T UA».

Важлива практична вимога до інструменту валідації — людиночитабельні повідомлення. «Контрагент ТОВ “Приклад”: відсутній ІПН у довіднику постачальників» дозволяє виправити проблему за хвилини; технічне «validation error at line 14573» перетворює процес на багатогодинне розслідування.

Подання файлу до ДПС

Файл подається через електронний кабінет платника з використанням КЕП. Практичні аспекти:

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

Подані файли варто зберігати у власній інфраструктурі протягом строків зберігання первинних документів — це доказова база і джерело для повторного подання.

Технічні підходи до підготовки

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

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

Власна розробка. Реалістична для компаній із сильними IT-командами та ресурсом на підтримку рішення при оновленнях XSD-схеми. Для більшості бізнесів — надмірна інвестиція.

Чому модуля ERP може бути недостатньо

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

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

Порівняння підходів для конкретних платформ — у статті «SAF-T UA для SAP, BAS та Odoo».

SAF-T Connector

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

On-premise: розгортається в інфраструктурі клієнта, дані не покидають периметр компанії.
ERP-незалежність: підключається до SAP, Odoo, Microsoft Dynamics, кастомних баз даних, Excel-джерел; консолідує кілька систем у єдиний файл.
Валідація зі зрозумілими звітами: кожна помилка описується конкретно — який контрагент, який документ, яке поле.
Впровадження під ключ за 3–4 місяці: від аналізу джерел даних до першого коректно сформованого і провалідованого файлу — етапи описані тут.

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

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

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

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

Регулярного розкладу немає: файл подається на запит ДПС. Обов’язок — надати файл у встановлений строк після отримання запиту.

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

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

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

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

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

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

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

Із налаштованим рішенням регулярна генерація — питання годин. Саме впровадження, від аналізу даних до першого успішно сформованого файлу, займає близько 3–4 місяців.

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

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

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

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

Що таке SAF-T UA: структура, вимоги та підготовка файлу