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

Готовність до SAF-T UA як частина облікової дисципліни

Чого не варто робити перед перевіркою

Контрольний перелік готовності

Підготовка бази 1С або BAS

Чому вивантаження дає помилки

Як електронний аудит перевіряє дані

Які дані потрапляють до файлу

Що таке SAF-T UA на практиці

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

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

Що таке SAF-T UA на практиці

SAF-T UA - це стандартизований електронний файл, який формується з облікової системи у встановленій структурі. Зазвичай ідеться про XML-файл, що відповідає актуальній XSD-схемі. Схема визначає назви елементів, обов’язковість полів, допустимі формати дат і чисел, зв’язки між об’єктами та інші технічні правила.

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

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

Які дані потрапляють до файлу

Структуру SAF-T UA зручно розглядати як пов’язаний набір кількох блоків. Конкретний склад обов’язкових і необов’язкових елементів визначається актуальною версією технічного опису та XSD, але зміст основних розділів залишається зрозумілим для бухгалтера.

Заголовок і відомості про підприємство

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

Довідники та початкові дані

Довідники створюють основу для всіх подальших посилань. До них можуть входити:

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

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

Головна книга та журнал бухгалтерських записів

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

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

Первинні документи та рух активів

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

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

Податкові показники та різниці

Файл містить відомості, пов’язані з податковими зобов’язаннями, кодами та ставками податків, податковою базою, сумами податку й податковими різницями. Завдання вивантаження - не заново розрахувати декларацію, а показати, як податковий результат пов’язаний із господарськими операціями та бухгалтерськими даними. Тому особливо небезпечні локальні коди, які зрозумілі одному бухгалтеру, але не зіставлені з передбаченими класифікаторами SAF-T UA.

Як електронний аудит перевіряє дані

Перевірка не зводиться до однієї ознаки «файл відкрився». Корисно розділяти щонайменше два рівні контролю.

Технічний контроль

Спочатку перевіряється відповідність XML актуальній XSD-схемі. На цьому рівні виявляються:

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

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

Логічний та арифметичний контроль

Далі дані можна зіставляти між розділами. Типові контрольні співвідношення мають такий вигляд:

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

Автоматичний контроль добре виявляє масові закономірності. Наприклад, він може виділити операції без контрагента на рахунках розрахунків, від’ємні кількості за звичайного надходження, однакові номери документів, нетипову кореспонденцію або розрив між закупівлею та рухом запасів. Тому одинична «технічна» звичка в 1С або BAS може перетворитися на сотні однотипних зауважень.

Чому вивантаження дає помилки

Найчастіше причина полягає не в самому XML, а у вихідній базі або в правилах перетворення даних.

1. Дублікати довідників. Одного постачальника заведено кілька разів, причому в одній картці є податковий номер, а в іншій - договір та обороти. Вивантаження не може надійно зібрати єдину історію.
2. Порожня аналітика. На рахунку розрахунків відсутній контрагент або договір, на рахунку запасів - номенклатура чи склад, на рахунку основних засобів - об’єкт обліку.
3. Нестійкі коди. Під час кожного вивантаження об’єкт отримує новий ідентифікатор або різні системи використовують несумісні ключі. У результаті посилання між розділами розриваються.
4. Ручні непідтверджені проводки. Запис змінює обороти, але не пов’язаний із документом, бухгалтерською довідкою чи зрозумілою підставою.
5. Розбіжність регістрів. Головну книгу, складський облік, податкові регістри та первинні документи закрито на різні дати або було змінено після формування звітності.
6. Неправильне зіставлення. Власний рахунок, вид операції, податковий код, група активу чи одиниця виміру не пов’язані з допустимим значенням формату.
7. Помилки знака та округлення. Суми вивантажено з протилежним знаком, кількість і вартість округлюються за різними правилами, а підсумок документа відрізняється від суми рядків.
8. Невідповідна версія схеми. Модуль обміну формує старий набір елементів, тоді як перевірка виконується за актуальною XSD.
9. Проблеми періоду. До файлу потрапляють документи за межами запиту, початкові залишки розраховано на іншу дату або дані кількох років помилково об’єднано в один файл.
10. Технічний обсяг. Вивантаження не завершується через нестачу пам’яті, нестабільну обробку великих таблиць або неправильне поділення архівів. Це потрібно виявляти під час тестування, а не в перший день після запиту.

Підготовка бази 1С або BAS

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

1. Зафіксувати периметр

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

2. Скласти таблицю відповідностей

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

3. Нормалізувати довідники

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

4. Закрити прогалини в аналітиці

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

5. Розібрати ручні операції

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

6. Звірити контрольні підсумки

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

7. Виконати пробне вивантаження

Пробу проводять на копії бази або у виділеному контурі, використовуючи той самий період і обсяг, які можуть бути запитані під час перевірки. Файл перевіряють актуальною XSD, потім аналізують логічні помилки та зіставляють контрольні суми з обліковою системою. Важливо виміряти час формування, розмір файлу й споживання ресурсів. Результат «не встигли за ніч» за строку у два робочі дні - повноцінний ризик, навіть якщо алгоритм формально правильний.

Контрольний перелік готовності

Перед тим як вважати базу підготовленою, корисно пройти короткий чек-лист:

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

Чого не варто робити перед перевіркою

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

Не менш ризиковано виправляти лише XML вручну. Якщо вивантаження доводиться «підфарбовувати» після формування, вихідна система та файл починають розповідати різні історії. Допустимі документовані правила перетворення, але вони повинні бути відтворюваними та перевірюваними.

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

Готовність до SAF-T UA як частина облікової дисципліни

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

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