Вона бачить, що придбаний товар не так відобразився у русі запасів. Або що дані однієї облікової системи не збігаються з іншою. Або що одна операція суттєво відрізняється від тисяч попередніх. І лише після цього просить документи та пояснення. Саме так поступово змінюється податкова перевірка в Україні.
З 2026 року ДПС практично застосовує систему електронного аудиту на основі SAF-T UA. Бізнес поки що недооцінює масштаб цієї зміни. Бо SAF-T UA це не просто ще один файл, який бухгалтер має навчитися правильно формувати, — вважає Ксенія Межова, адвокат практики вирішення спорів в Juscutum. Вона розбирає головні ризики нової системи.
Як змінилися стандарти інформування податкової
SAF-T UA wt — стандартизований електронний файл зі структурованими даними бухгалтерського обліку підприємства. Він містить інформацію про господарські операції, активи, зобов'язання, запаси, придбання, реалізацію та інші облікові показники. Тобто податкова бачить не лише фінальний результат, який підприємство показало у звітності, а великий масив даних, з яких цей результат сформувався. І це вже працює на практиці.
За даними ДПС, лише протягом першого кварталу практичного використання е-аудиту контролюючі органи отримали 14 файлів SAF-T UA безпосередньо під час документальних перевірок. Система дозволяє автоматично перевіряти структуру, повноту та логічну узгодженість даних, застосовувати аналітичні та аудиторські тести, виявляти розбіжності та потенційні ризики. Після цього платнику можуть направити запит і попросити пояснити конкретну операцію.
І саме тут відбувається принципова зміна. Раніше інспектор значною мірою мав сам знайти проблему серед документів платника. Тепер система може спочатку знайти аномалію, а вже потім інспектор запитає бізнес, чому вона виникла. Один документ може бути правильним. А вся картина взагалі інша.
Уявімо велику компанію: тисячі контрагентів, десятки тисяч операцій, платежі, складський облік, договори, акти та накладні. Перевірити вручну кожну операцію практично неможливо. Але структуровані дані дозволяють аналізувати не один документ, а взаємозв'язки між різними операціями.
Компанія, наприклад, придбала значну партію товару. Договір є. Накладні є. Оплата проведена. Якщо відкрити кожен документ окремо, то все може виглядати бездоганно. Але аналіз даних дозволяє поставити наступне запитання: а що сталося з товаром далі? Чи був він оприбуткований? Як відображена його реалізація або списання? Чи відповідає рух запасів продажам? Звідки виник незвичний залишок?
Предметом аналізу стає вже не одна накладна, а весь економічний ланцюг операції. І це вже набагато складніше для бізнесу.
Є інша, на мою думку, ще цікавіша ситуація. Підприємство реально працює, здійснює операції, має первинні документи та сплачує податки. Але бухгалтерський облік ведеться в одній системі, складський в іншій, управлінський вже у третій.
Частина даних переноситься автоматично. Частина просто вручну. Компанія могла змінити програмне забезпечення, перенести стару базу, змінити довідники товарів або контрагентів.
Для великого бізнесу нічого екстраординарного тут немає. Але достатньо одного некоректного налаштування або помилки під час міграції, щоб показники, які окремо виглядають правильними, перестали узгоджуватися між собою. І для бухгалтера це може бути технічною похибкою. Для автоматизованого аналізу аномалією, яка потребує пояснення.
Саме тут виникає новий тип податкового ризику: компанія може не мати проблеми з реальною господарською операцією, але мати проблему з тим, як ця операція відображена в її даних.
Податкове питання стає питанням грошей
І тут SAF-T UA перестає бути виключно податковим питанням. Це вже питання грошей. Раніше некоректний запис у величезному масиві бухгалтерської інформації міг роками не мати практичних наслідків. Тепер така невідповідність потенційно може стати точкою входу в детальну перевірку конкретної операції.
А далі починається добре знайома бізнесу економіка податкового спору: робочий час фінансової команди, бухгалтерів і юристів, пошук первинних документів, підготовка пояснень, заперечення до акта перевірки, адміністративне або судове оскарження, а зрештою і ризик донарахувань і фінансових санкцій.
Тому якість бухгалтерських даних поступово перестає бути внутрішньою проблемою бухгалтерії. Вона стає фінансовим ризиком компанії. Але алгоритм не знає, чому впала маржинальність.
Тут є принципова юридична межа, про яку, на мою думку, бізнесу варто говорити вже зараз.
Автоматизована система може знайти розбіжність, нетипову операцію чи інший індикатор ризику. Але між словами «система виявила невідповідність» і «платник порушив податкове законодавство» не можна автоматично ставити знак рівності.
Алгоритм бачить дані. Він не завжди бачить причину. Наприклад, суттєве падіння маржинальності може виглядати нетипово. Але компанія могла втратити ринок збуту, бути змушена продати залишки зі значною знижкою, змінити логістику або понести додаткові витрати через війну. Велике списання також може привернути увагу. Але актив міг бути знищений або пошкоджений. Нетипове коригування також може бути наслідком зміни умов договору.
Тому результат автоматизованого аналізу повинен бути початком дослідження операції, а не доказом податкового порушення сам по собі. Податкова все одно має встановити фактичні обставини, дослідити документи та пояснення платника і довести конкретне порушення, якщо саме воно стає підставою для донарахувань.
Цифровізація податкового контролю не повинна перетворюватися на автоматизацію висновку про порушення. І, я думаю, саме навколо цієї межі з часом виникатиме дедалі більше податкових спорів.
Важливі строки надання SAF-T UA
Є ще одна деталь, яку великому бізнесу точно не варто недооцінювати. Під час документальної перевірки великий платник на запит контролюючого органу має надати SAF-T UA не пізніше двох робочих днів, наступних за днем отримання запиту.
Два робочі дні це дуже мало, якщо саме після отримання запиту компанія вперше починає з'ясовувати, чи здатна взагалі правильно сформувати файл і що міститься всередині.
Стратегія «прийде перевірка і тоді розберемося» тут уже не працює. ДПС навіть дозволяє великим платникам заздалегідь тестувати сформований SAF-T UA через Електронний кабінет.
Але я б пішла далі. Бізнесу варто тестувати не лише файл. Бізнесу варто протестувати самого себе. Якщо податкова отримує інструмент для автоматизованого аналізу бухгалтерських даних підприємства, логічна відповідь бізнесу самому навчитися аналізувати ці дані раніше за податкову. Я б назвала це репетицією е-аудиту.
Чи збігаються дані між різними системами? Де є ручні коригування? Які операції різко відрізняються від звичайних? Де відбувалася міграція інформації? Які великі списання, повернення або коригування можуть потребувати окремого пояснення?
А потім поставити ще одне запитання: якщо завтра ДПС попросить пояснити саме цю операцію, чи зможемо ми швидко знайти документи і зрозуміло пояснити її економічну логіку? Якщо відповідь буде «ні», то ризик уже існує. Просто податкова його ще не побачила.
ФОПам приготуватися?
Сьогодні практичне застосування SAF-T UA під час документальних перевірок насамперед стосується великих платників. Тому не потрібно створювати враження, що завтра кожен ФОП передаватиме податковій всю свою бухгалтерську базу. Але вважати е-аудит проблемою виключно великого бізнесу також було б короткозоро.
Держава послідовно рухається до ризик-орієнтованого цифрового податкового контролю. Подальше розширення застосування SAF-T UA передбачене стратегічними документами держави та потребуватиме відповідних законодавчих рішень.
Тому те, що сьогодні відбувається з великими платниками, варто розглядати як модель того, якою поступово може ставати податкова перевірка загалом.
SAF-T UA у цьому сенсі це не просто новий формат файлу. Це зміна балансу інформації. Податкова отримує можливість швидше побачити те, що раніше могло загубитися серед тисяч документів. А отже бізнесу доведеться краще знати власні дані.
У 2026 році компанії вже недостатньо бути готовою показати податковій свої документи. Вона має бути готовою пояснити власні дані й бажано це зробити ще до того, як податкова знайде в них запитання.