Перше вивантаження SAF-T показує не якість ERP, а якість обліку за останні кілька років

SAF-T UA – це стандартний аудиторський файл із повним вивантаженням облікових даних компанії у структурі, яку задає ДПС. Сьогодні його надають великі платники податків на запит під час документальної перевірки, а Національна стратегія доходів передбачає поширення цієї вимоги на всіх платників ПДВ з 2027 року. У SAF-T проєктах, які супроводжує компанія Sapience Tech, найбільше часу з'їдає не формування XML, а те, що файл робить видимим в обліку. Про це в колонці для Mind розповіла Юлія Ліповецька, СЕО та співзасновниця консалтингової компанії Sapience Tech.

Чому SAF-T не є виключно ІТ-задачею

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

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

Причина в тому, що SAF-T влаштований принципово інакше, ніж будь-яка звітність, до якої звикли фінансові служби. Баланс чи звіт про фінансові результати – це агрегати, тобто підсумки, які можна вивірити, узгодити й підписати. SAF-T – це первинні дані у структурі, заданій іззовні. Ви не інтерпретуєте свій облік для регулятора, як це відбувається з балансом чи P&L, ви віддаєте його як є. І файл показує кожне місце, де реальна облікова практика розійшлася з тим, як усе мало б працювати на папері.

У наших проєктах ми бачимо сім таких місць практично в кожній компанії. Перші три з них можна закрити силами фінансової служби. Останні чотири – це вже проєктна робота на місяці.

Сім розривів між обліком і файлом

Що можна закрити силами фінансової служби

Розрив 1. Майстер-дані контрагентів, які ніхто не перевіряв роками

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

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

Країна реєстрації рекомендована до заповнення і задається кодом, який має відповідати державному довіднику.

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

Ще один нюанс виникає з філіями. У довіднику філія часто заведена як самостійний контрагент із власним кодом, а платником ПДВ є головне підприємство. У файлі податкові реквізити такого контрагента мають бути реквізитами головного підприємства, тобто зв'язок «філія – головна юрособа» має існувати в майстер-даних для того, щоб була можливість програмно забрати ці дані.

Але найпідступніша частина майстер-даних – податкові реквізити платників ПДВ. Довідники не оновлюються регулярно: поле «ІПН» або ознака платника ПДВ у картці заповнені при створенні картки контрагента, а подальші зміни не відстежуються. Учора контрагент був платником, сьогодні реєстрацію анульовано, а система знає лише попередній стан. Або зворотна ситуація: контрагент є платником ПДВ кілька років, але в обліковій системі це жодним чином не відображено.

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

Чим це загрожує. Перевірка ІПН контрагентів – один із типових технічних тестів ДПС, що виконуються автоматично при прийманні файлу (тест RE-7). Якщо контрагент мав статус платника у періоді, а ІПН у файлі порожній, або навпаки, ІПН вказано для періоду, коли він вже не був актуальним, файл отримує відхилення.

Що робити. Два кроки.

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

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

Розрив 2. Номенклатура й одиниці виміру, які нікому не заважали

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

У SAF-T цього знання немає. Файл вимагає унікальних кодів номенклатури і узгодженості між довідником та операціями. А одиниці виміру мають бути співвіднесені з класифікаторами КСПОВО (ДК 011-96) або КОВО-МД (одиниці виміру, що використовуються в митних деклараціях), а не з внутрішньою звичкою. «Штука» у довіднику не є помилклю, але для файлу вона має отримати код із класифікатора, і він має бути спільним для всіх варіантів написання.

Чим це загрожує. Одна й та сама номенклатура у файлі виглядає як п'ять різних, через що залишки й обороти за нею розпадаються на частини, рух запасів між періодами не сходиться, а аналітика за позицією втрачає сенс. Одиниця виміру без відповідності класифікатору – окремий технічний тест ДПС (тест RE-16).

Що робити. Логічний крок – почистити довідники, і це найнебезпечніша реакція. Злиття дублів заднім числом у продуктивній системі ламає історію проведень, залишки й закриті періоди. Вирішення проблеми звітності може призвести до створення проблеми ведення обліку.

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

Розрив 3. Облікова політика у Word і облікова політика у файлі

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

SAF-T не передбачає вкладення документів – наказ у Word чи PDF всередину файлу не покладеш. Натомість розділ II.1 вимагає розкласти політику на окремі елементи, і для кожного вказати чотири речі: назву елемента, його опис, реквізити наказу, яким його затверджено, і найменування стандарту, на якому він ґрунтується (МСФЗ/МСБО або ПСБО). Тобто політика з тексту перетворюється на структурований перелік, де кожен пункт має підставу і документ.

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

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

Що робити. Провести ревізію політики під структуру розділу II.1, і це корисна вправа сама по собі. Пройти документ по пунктах і для кожного з них дати три відповіді: чи ведеться облік насправді так, як тут написано; яким наказом і від якої дати цей пункт затверджено або змінено; на який пункт ПСБО/МСБО/МСФЗ чи іншої нормативної документації він спирається. Там, де практика розійшлася з політикою, треба або привести політику у відповідність окремим наказом, або повернути практику до політики. Там, де підстави немає, її треба знайти або визнати, що пункт тримається на звичці. На виході отримуєте перелік елементів, готовий до вивантаження у файл, і актуальну політику, яка вперше за довгий час відповідає обліку.

Що вже є проєктною роботою

Розрив 4. Ручні проведення без аналітики

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

У SAF-T кожен рядок головної книги має власний набір обов'язкових полів. Ручне проведення на кілька мільйонів без жодної аналітики – це не технічна помилка, це рядок, який неможливо пояснити структурно.

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

Що робити. Ми завжди починаємо з інвентаризації та дивимося, скільки ручних проведень за період, на які суми, скільки з них не мають потрібних полів. Далі два потоки. Для майбутнього – використання інших підходів у системі для оформлення подібних операцій (наприклад, системний тип документа, у якого є потрібний набір полів), щоб проблема перестала накопичуватися. Для минулого – визначення пріоритетів за сумами й ризиком, розгортання аналітики та дозаповнення вручну.

Розрив 5. Перша подія, яку визначає бухгалтер, а не система

Розділ II.2 SAF-T – довідник типів операцій, і він обов'язковий. Обов'язкове й посилання на нього, оскільки кожне проведення в головній книзі та кожен документ продажу чи закупівлі має отримати код типу операції. Самі коди та класифікацію підприємство визначає на власний розсуд, але з однією жорсткою умовою – операції продажу й закупівлі мають бути поділені за правилом першої події відповідно до ПКУ, а закупівлі необоротних активів виділені окремою категорією.

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

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

Чим це загрожує. Довідник II.2 і посилання на нього обов'язкові, тому без класифікації файл не збереться взагалі. Помилка в класифікації за першою подією – це вже не питання якості даних, а питання податкового обліку з ПДВ.

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

Розрив 6. Типи руху запасів, яких у 1С і BAS не існує

Є вимоги, які взагалі неможливо закрити наведенням ладу, і найяскравіший приклад – довідник типів руху запасів (розділ II.10 структури файлу). Наводити лад немає в чому, бо наводити нема чого.

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

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

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

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

Розрив 7. Один файл із п'яти систем

Майже жодне велике підприємство не працює в одній системі: ERP для обліку, окремий білінг, WMS на складі, окрема система для зарплати, іноді ще одна для основних засобів. Кожна робить свою роботу добре.

А SAF-T – це один цілісний файл. Дані з усіх систем мають бути зведені так, ніби вони завжди були одним масивом: із наскрізними ідентифікаторами контрагентів, номенклатури, документів. На практиці – наскрізних ідентифікаторів немає. У системі, що відповідає за рух запасів, ведеться деталізація за кількістю, ціною, сумою та номенклатурою, але відсутні проведення. Щомісяця дані заводяться як зведене проведення у ERP, але відсутнє лінкування «зведене проведення у ERP vs X операцій у системі обліку запасів». Звірки за оборотами можуть проводитись з урахуванням матеріальності у розумінні бухгалтера. Тому навіть за наявності лінкування залишаються несуттєві різниці в оборотах між системами (прийнятно з точки зору обліку, але неприйнятно з точки зору автоматизованих контролів SAF-T).

Чим це загрожує. Розглянемо типовий випадок. Дані для журналу проведень (розділ III) беруться з ERP, дані про рух запасів (розділ IV.4) – з окремої системи обліку запасів. У кожному рядку руху запасів є обов'язковий елемент TransactionID – посилання на проведення в головній книзі. Якщо між системами немає лінкування за номером проведення, цей елемент нема чим заповнити, і файл не пройде валідацію вже на рівні обов'язкових елементів, ще до будь-якого аналізу змісту. Другий бар'єр – несуттєві різниці. Серед типових технічних тестів ДПС є перевірка збалансованості запасів (тест RE-3): залишки на початок і кінець періоду мають узгоджуватися з операціями надходження та вибуття і з даними оборотно-сальдової відомості. Різниця в кілька сотень гривень, яку бухгалтер роками закривав як несуттєву, для цих тестів є розбіжністю, і файл отримає відхилення на суто технічному рівні. Тобто те, що з точки зору обліку було прийнятним, з точки зору автоматизованих контролів SAF-T стає помилкою.

Що робити. Практично це означає створення карти систем із відповіддю на два питання по кожній: джерелом яких даних для файлу вона є (чи потрібна ця система для SAF-T?); за яким ключем її записи зв'язуються з ERP.

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

У якому порядку за це братися

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

Перший крок – карта систем (розрив 7). Скільки систем містять дані для файлу, які саме дані в кожній живуть, яка з них є джерелом для якого розділу і за яким ключем її записи зв'язуються з ERP. Без цієї карти неможливо оцінити обсяг жодної іншої роботи: незрозуміло, у якому довіднику наводити лад, звідки братиметься рух запасів і де шукати ручні проведення.

Другий крок – паралельно, силами фінансової служби, три розриви, які не залежать від ІТ-проєкту. Майстер-дані контрагентів: дублі карток, довжина найменувань, реєстраційні дані резидентів і нерезидентів, ведення ІПН за періодами. Номенклатура й одиниці виміру: дублі та відповідність класифікатору. Облікова політика: переведення у формат розділу II.1, ревізія пунктів на актуальність і пошук підтвердження в нормативній документації та стандартах. Це роботи на тижні, і починати їх можна одразу, щойно карта систем показала, де саме живуть ці довідники.

Третій крок – два методологічні потоки, що не залежать один від одного і можуть рухатись паралельно. Довідник типів операцій і перша подія (розрив 5) – робота того, хто відповідає за ПДВ на підприємстві. Типи руху запасів (розрив 6) – коли вже відомо, з якої системи береться рух запасів і як він зв'язується з проведеннями – критичним ресурсом стає людина, яка розуміє, як саме на підприємстві рухаються запаси. Це найдовші потоки в проєкті.

Четвертий крок – ручні проведення (розрив 4): після першого вивантаження головної книги потрібно ідентифікувати ручні проведення, які підлягають розширеному розкриттю. Минулі періоди – пріоритезація за сумами й ризиком, розгортання аналітики та дозаповнення вручну поза системою. Майбутні – використання інших підходів у системі для оформлення подібних операцій (наприклад, системний тип документа з необхідним набором полів).

І завершальний етап – тестове вивантаження та звірка розділів файлу між собою, що покаже, чи вдалося усунути виявлені розриви.

Самодіагностика за один день

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

1. Візьміть десять контрагентів, з якими працювали весь рік: порахуйте, скільки з них заведено більше ніж однією карткою, і перевірте в реєстрі платників ПДВ, чи змінювався їхній статус протягом року. Якщо змінювався хоча б в одного – з'ясуйте, чи знає про це ваша система.
2. Порахуйте дублі в номенклатурі та одиницях виміру і перевірте, чи є в одиниць виміру відповідність класифікатору. Не виправляйте, просто порахуйте.
3. Відкрийте наказ про облікову політику і для будь-яких трьох пунктів спробуйте відповісти: яким наказом затверджено, на який стандарт спирається, чи так насправді ведеться облік. Якщо хоча б на одне питання відповіді немає, ревізія потрібна.
4. Вивантажте головну книгу за один квартал і подивіться на ручні проведення: скільки їх, на які суми, скільки з них не мають аналітики. Це п'ять хвилин роботи, після яких масштаб буде уже більш зрозумілим.
5. Візьміть двадцять операцій закупівлі з різних місяців і спробуйте визначити першу подію лише за даними системи, не відкриваючи податкову накладну і не питаючи бухгалтера. Якщо не виходить – критерію в системі немає.
6. Якщо ви на 1С або BAS – проаналізуйте, скільки різних сценаріїв руху запасів є на підприємстві. Це і є кількість правил, які доведеться побудувати.
7. Складіть перелік систем, які містять дані для файлу, і чесно оцініть, чи є між ними зв'язок на рівні операцій.

Така оцінка ще не означає готовності до SAF-T. Вона дає розуміння реального обсягу робіт і часу, який знадобиться на підготовку. Компанія, яка зробить це у 2026 році, матиме більше часу на вибір рішення, ніж у випадку, коли оцінка почнеться вже після отримання запиту від податкової.

Що ви отримаєте, крім витрат

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

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