SAF-T UA без паніки: як виглядає електронний аудит очима бухгалтера

Що є чинним станом на 11 вересня 2026 року

Від облікової бази до перевірок ДПС

Структура файлу мовою бухгалтера

Як «читаються» окремі ділянки обліку

Контрольний список якості аналітики

Навчальний приклад: шукаємо розрив між обороткою і SAF-T

Типові помилки підготовки

Як організувати готовність без аврального проєкту

Головний висновок

Уявімо робочий ранок: надійшов запит у межах документальної перевірки, а в ньому — вимога надати SAF-T UA за визначений період. Перша реакція цілком людська: «Невже доведеться вручну перекладати всю базу на мову податкової?» Насправді SAF-T UA — не новий паралельний облік і не величезна декларація. Це стандартизований XML-файл, у якому знайомі бухгалтеру дані розкладено за узгодженою структурою, щоб їх можна було автоматично перевіряти.

Головна складність не в самому XML. Вона в якості облікової аналітики: чи однаково ідентифіковано контрагента в різних підсистемах, чи кожна проводка має джерело, чи складські рухи узгоджуються з кількістю та сумою, чи первісна вартість основного засобу не загубилася під час міграції. Тому підготовка до SAF-T починається не з кнопки «Вивантажити», а зі звірки того, що вже є в BAS, ERP, складській системі та допоміжних реєстрах.

Що є чинним станом на 11 вересня 2026 року

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

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

SAF-T UA не є податковою декларацією і не подається щомісяця чи щокварталу за календарем звітності. Це електронні документи та інформація, пов’язані з предметом перевірки. ДПС називає 2024 рік першим календарним роком, за який може запитуватися такий файл, і підтверджує, що оновлену структуру SAF-T UA версії 2.0 оприлюднено 6 листопада 2024 року. На офіційному ресурсі доступні XSD-схема, технічний опис, додаток, опис змін і приклади валідних та помилкових файлів.

Ще одна корисна межа між фактом і старими прогнозами: законопроєкт № 6255 про впровадження електронних перевірок був відкликаний 17 липня 2025 року. Отже, таблиці майбутніх етапів, які колись будувалися на його тексті, не можна подавати як чинний календар поширення SAF-T UA. Окремого штрафу виключно під назвою «за SAF-T» Кодекс не встановлює; ДПС пов’язує відповідальність із загальними правилами неподання або неповного подання інформації на запит. Грошовий розмір у такій ситуації залежить від мінімальної зарплати на 1 січня відповідного податкового року, тому його слід перевіряти саме для періоду й підстав конкретного запиту.

Від облікової бази до перевірок ДПС

Логіку процесу зручно бачити як послідовність контрольованих перетворень. Якщо помилка з’явилася на одному етапі, не потрібно переробляти все: достатньо визначити, де саме дані втратилися, дублювалися або змінили аналітику.

У цій схемі XSD-валідація відповідає лише на питання, чи правильно побудований файл технічно: чи дозволений елемент, тип даних, формат дати, кількість знаків, обов’язковість поля. Вона не доводить, що сума правильна. XML може бути бездоганно валідним і водночас містити пропущений документ, дубльовану проводку або контрагента з неправильним кодом.

Структура файлу мовою бухгалтера

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

1. Заголовок: хто, за який період і з якої системи

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

2. Довідники: єдина мова для всіх операцій

У довідниковому шарі зібрано сутності, на які посилаються проводки й документи. Його слід уявляти як контрольований експорт карток із бази:

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

Ключова вимога тут — сталість ідентифікаторів. Якщо той самий постачальник у закупівлях має код «P-154», а в проводці — старий код «000154», автоматична перевірка побачить дві різні сутності або «сиротинське» посилання. Для людини назви можуть виглядати однаково; машина звіряє ключі.

3. Головна книга: не просто оборотка, а кожна лінія проводки

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

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

4. Первинні документи: звідки виникла проводка

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

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

Як «читаються» окремі ділянки обліку

Контрагенти

Перевірка дивиться не лише на назву. Важливі код, податковий ідентифікатор, роль покупця або постачальника, адресні дані та використання одного ключа в документах і проводках. Дублікати на кшталт «ТОВ Альфа» і «Альфа, ТОВ» — не косметична проблема, якщо за ними розпорошені обороти й податкові суми.

Запаси

За запасами одночасно мають узгоджуватися три площини: кількість, вартість і бухгалтерський рахунок. Негативний залишок, змішування одиниць виміру, списання без партії чи складський документ без відповідної проводки створюють різні сигнали. Тому звірка лише рахунку 28 із балансом недостатня: потрібні контрольні підсумки за складом, номенклатурою та одиницею виміру.

Основні засоби

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

Податки

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

Контрольний список якості аналітики

Перед тестовим вивантаженням корисно зафіксувати не лише позначки «виконано», а й доказ: назву звіту, параметри відбору, дату запуску, кількість рядків, контрольну суму та відповідального. Мінімальний список виглядає так:

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

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

Навчальний приклад: шукаємо розрив між обороткою і SAF-T

Припустімо, за рахунком 281 «Товари на складі» оборотно-сальдова відомість за квітень показує:

• початкове сальдо — 1 250 000 грн;
• дебетовий оборот — 780 000 грн;
• кредитовий оборот — 690 000 грн;
• кінцеве сальдо — 1 340 000 грн.

Формула сходиться: 1 250 000 + 780 000 − 690 000 = 1 340 000 грн. Але після агрегації рядків головної книги з тестового SAF-T кінцевий залишок становить 1 310 000 грн. Розрив — 30 000 грн. Панікувати й одразу виправляти проводки не слід: спочатку треба довести, у якому шарі з’явилася різниця.

Крок 1. Зробити порівнювані набори

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

Крок 2. Визначити бік розриву

Початкове сальдо й дебет у двох наборах однакові. Кредит у SAF-T дорівнює 720 000 грн, тобто перевищує оборотку саме на 30 000 грн. Отже, шукати слід не «десь у товарах», а серед кредитових рядків рахунку 281.

Крок 3. Згрупувати до рівня документа

Рядки групуємо за датою, номером документа, сумою та ідентифікатором операції. Майже всі документи дають однакові підсумки. Лише переміщення запасів № СК-000184 на 30 000 грн у XML присутнє двічі, а в оборотці — один раз.

Крок 4. Знайти технічну причину

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

Крок 5. Виправити й довести результат

Розробник змінює правило з’єднання, щоб кожна лінія проводки мала унікальний ключ. Новий файл проходить три перевірки: кредитовий оборот рахунку 281 дорівнює 690 000 грн, кінцеве сальдо — 1 340 000 грн, документ № СК-000184 представлений один раз. Додатково варто перевірити інші рахунки з тією самою податковою аналітикою: локальне виправлення могло вплинути на весь експорт.

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

Типові помилки підготовки

• Перевіряти лише валідність XML. Валідний формат не гарантує повноти та правильності сум.
• Будувати файл без участі бухгалтера. Розробник бачить поля й типи, але не завжди знає, чому конкретне сторно, ручна проводка або закриття місяця мають саме таку економічну логіку.
• Звіряти тільки баланс. Однакове кінцеве сальдо може приховувати взаємно компенсовані пропуски в дебеті та кредиті.
• Очищати довідники напередодні перевірки. Масове об’єднання дублів без карти відповідності може розірвати історичні посилання.
• Перераховувати історію новими правилами. Експорт має відтворювати облікові дані періоду, а не створювати їх нову версію.
• Не зберігати протокол формування. Без параметрів, версії обробки, часу, кількості рядків і контрольних сум важко відтворити результат.
• Покладатися на одну людину. Бухгалтер, фахівець з облікової системи та відповідальний за передавання мають знати свої дії й резервний порядок.

Як організувати готовність без аврального проєкту

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

Другий крок — розподілити відповідальність. Бухгалтер визначає економічну правильність і контрольні звіти; фахівець BAS або ERP відповідає за відбір, мапінг та повторюваність; ІТ-фахівець — за ресурси, захищене зберігання й передавання; керівник затверджує строки та порядок реагування. Результатом має бути не один «успішний файл», а відтворюваний процес.

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

Головний висновок

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

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