Абросимова Євгенія,
Партнер з ТЦУ
Зміст статті
Уявіть ситуацію: у п’ятницю ввечері головний бухгалтер великого підприємства отримує запит від податкової — надати SAF-T UA файл. На підготовку — два робочих дні. Не два тижні, не місяць. Два дні на те, щоб вивантажити, перевірити і здати структурований електронний файл з усіма проводками, документами і зв’язками між ними за період перевірки.
Для більшості компаній це той момент, коли з’ясовується, що “у нас начебто є модуль для SAF-T” і “воно насправді працює” — це дві абсолютно різні речі.
Що таке SAF-T UA насправді — і чому це не просто “ще один звіт”
Технічно SAF-T UA – це XML-файл, що має відповідати офіційній XSD-схемі ДПС. Але зводити суть до “формату файлу” – типова помилка, яка потім дорого коштує. SAF-T вимагає не просто вивантажити дані, а вивантажити їх **узгоджено, з повними зв’язками між документами і коректною класифікацією кожної операції**. Це, по суті, знімок всієї фінансово-господарської логіки компанії – і будь-яка тріщина в цій логіці стає видимою миттєво.
Дві пастки, у які потрапляє більшість компаній
Пастка перша: “У нас є ліцензія на модуль — отже, ми готові”
Пастка друга: “Ми пройшли XSD-валідацію — файл коректний”
Тут ховається одна з найпоширеніших ілюзій безпеки. SAF-T-файл проходить перевірку у два рівні:
- Перший рівень — структурний: чи всі обов’язкові елементи на місці, чи коректні типи даних. Це те, з чим технічний модуль справляється автоматично, і його проходження нічого не каже про якість даних усередині.
- Другий рівень — змістовний: чи узгоджені суми між розділами файлу, обліковою системою і поданою звітністю; чи кожен документ продажу пов’язаний з відповідною податковою накладною; чи коректно класифікована кожна операція за ставкою ПДВ і видом податку.
Саме тут виявляється реальна готовність компанії — і саме цей рівень найчастіше залишається неперевіреним до моменту, коли перевіряти вже пізно.
Що насправді означає “бути готовим”
Три рівні перевірки компанії до отримання запиту від ДПС:
-
Довідники та реєстраційні дані: Чи повні картки контрагентів, чи актуальний план рахунків, чи достатньо деталізації в аналітиці для коректного мапінгу на структуру SAF-T.
-
Узгодженість сум: Чи збігаються обороти в тестовому SAF-T-файлі з даними облікової системи і з уже поданою податковою звітністю. Розбіжність навіть у кілька гривень – сигнал, який варто дослідити, а не проігнорувати.
-
Зв’язки та класифікація операцій: Чи кожен документ у файлі має коректні перехресні посилання на пов’язані документи, чи правильно визначена ставка і вид податку для нестандартних операцій – експорту, посередницьких схем, безоплатної передачі, операцій з пов’язаними особами.
Останній пункт – найскладніший, і саме тут технічне рішення безсиле. Правильно класифікувати нетипову операцію може лише фахівець, який розуміє одночасно і облікову політику компанії, і логіку податкового законодавства. Це та точка, де закінчується робота IT-модуля і починається робота методолога.
Головний висновок для бізнесу
Практична рекомендація
Тому практична рекомендація проста: не чекайте запиту від податкової, щоб дізнатися, готова компанія чи ні. Проведіть діагностику готовності заздалегідь – поки є час виправити знайдене, а не пояснювати його контролюючому органу постфактум.
Потрібна консультація?
