Чек-лист для великого бізнесу - підготовка 1C/BAS до вимог SAF-T UA
Етап 1. Governance: організація проєкту
Призначити власника проєкту
Рекомендовано: CFO або Head of Tax як бізнес-власник, CIO/IT Director як технічний співвласник, головний бухгалтер як власник методології.
Чому це важливо: SAF-T UA зачіпає одночасно бухгалтерський облік, податковий облік, ІТ-архітектуру, майстер-дані, регламентні процедури, інтеграції та внутрішній контроль.
Створити робочу групу
До команди варто включити:
головного бухгалтера;
податкового менеджера;
власника BAS/1C;
адміністратора бази;
аналітика з регістрів бухгалтерії;
власників довідників контрагентів і номенклатури;
фахівця з інтеграцій;
внутрішній аудит;
зовнішнього консультанта з SAF-T UA / BAS.
Зафіксувати RACI
Напрям | Responsible | Accountable | Consulted | Informed |
Методологія обліку | Головний бухгалтер | CFO | Податковий консультант | CEO |
Технічна архітектура | ІТ/BAS команда | CIO | ERP -консультант | CFO |
Мапінг даних | BAS -аналітик | Головний бухгалтер | Власники процесів | Внутрішній аудит |
Якість довідників | MDM -власники | CFO/CIO | Бухгалтерія, закупівлі, продажі | Бізнес-напрями |
Валідація XML | ІТ/BAS команда | CIO | Податковий менеджер | CFO |
Подання/комунікація з ДПС | Податковий менеджер | CFO | Юристи | CEO |
Етап 2. Нормативна і технічна база
Зібрати актуальні документи
Потрібно завантажити й централізовано зберігати:
актуальну XSD -схему SAF-T UA;
детальний технічний опис елементів SAF-T UA;
додаток до технічного опису;
опис змін релізів;
приклади XML -файлів;
роз’яснення ДПС;
внутрішню методологію мапінгу BAS → SAF-T UA.
ДПС має окремий розділ для XSD, технічного опису, додатків і прикладів файлів SAF-T UA.
Визначити реліз SAF-T UA
Необхідно встановити, яку версію SAF-T UA підтримує ваше рішення: V1.3, V1.4, V2.0 або іншу актуальну версію. У 2024 році ДПС обговорювала порядок формування і подання SAF-T UA V2.0, а також повідомляла про оновлення технічного опису й додатків.
Етап 3. Інвентаризація BAS-ландшафту
Описати всі інформаційні бази
Для великого бізнесу часто існує кілька баз:
юридичні особи в окремих BAS -базах;
виробнича база;
торгова база;
бухгалтерська база;
база зарплати;
архівні бази;
тестові/історичні копії;
база консолідації.
SAF-T UA прив’язаний до платника податків і періоду, тому потрібно розуміти, які саме бази є джерелом юридично значущого бухгалтерського обліку.
Перевірити конфігурації та доробки
Потрібно зафіксувати:
назву конфігурації;
версію платформи;
версію конфігурації;
перелік змінених об’єктів;
нестандартні регістри;
зовнішні обробки;
інтеграції;
обмін між базами;
регламентні завдання;
архівні механізми.
Виявити “тіньові” джерела даних
Проблемою можуть бути Excel -файли, ручні розрахунки, зовнішні облікові таблиці, окремі системи казначейства, WMS або виробничі модулі, які не повністю синхронізовані з BAS. SAF-T UA передає дані з облікової системи, але податковий аудит може зіставляти їх із первинними документами, фінзвітністю та іншими джерелами.
Етап 4. Data readiness assessment
Це найважливіший етап. Його мета — зрозуміти, чи здатна BAS -база сформувати повний, логічно узгоджений і технічно валідний SAF-T UA.
Перевірка організацій
Чи заповнені повні реквізити організації?
Чи коректний ЄДРПОУ?
Чи збігаються назви організації в BAS, податковій звітності, M.E.Doc та первинних документах?
Чи коректно ведеться історія змін реквізитів?
Чи розділено дані за юридичними особами?
Перевірка облікової політики
У SAF-T UA передається інформація про елементи облікової політики, включно з реквізитами наказу про облікову політику і змінами до нього.
Що зробити в BAS:
формалізувати облікову політику;
перевірити методи амортизації;
перевірити методи оцінки запасів;
перевірити правила визнання доходів і витрат;
перевірити податкові різниці;
зафіксувати зміни політик за періодами.
Перевірка плану рахунків
Типові ризики:
нестандартні рахунки без опису;
рахунки без аналітики;
субконто використовуються непослідовно;
одна операція відображається різними схемами;
рахунки не відповідають внутрішній методології;
відсутній мапінг до SAF-T UA.
Контроль:
обороти Дт/Кт мають збігатися з Головною книгою;
усі рахунки, що використовуються у проводках, повинні бути описані;
аналітика має бути заповнена там, де вона обов’язкова;
ручні проводки мають мати документальне пояснення.
Перевірка контрагентів
Критично перевірити:
ЄДРПОУ/ІПН;
назву;
тип контрагента;
адресу;
країну;
статус платника ПДВ;
договори;
банківські рахунки;
дублікати;
архівні й неактивні записи.
Типові проблеми BAS:
один контрагент заведений кілька разів;
контрагент і договір використовуються як “заглушка”;
договори не відповідають реальним первинним документам;
адреси відсутні або заведені довільним текстом;
нерезиденти не мають повного набору реквізитів.
Перевірка номенклатури
Що перевірити:
унікальність SKU;
одиниці виміру;
групи номенклатури;
коди УКТ ЗЕД/ДКПП, якщо застосовно;
ставки ПДВ;
ознаки товар/послуга/робота;
серії, партії, характеристики;
склади;
відповідність первинним документам.
У практичних оглядах SAF-T UA серед частих проблем згадуються неповні дані контрагентів, відсутні коди товарів та розбіжності між проводками і первинними документами.
Перевірка основних засобів
Контрольні питання:
Чи всі ОЗ мають інвентарні номери?
Чи коректно відображено введення в експлуатацію?
Чи є історія модернізацій, переоцінок, переміщень?
Чи збігається бухгалтерська й податкова амортизація?
Чи є зв’язок із первинними документами?
Чи коректні рахунки обліку, амортизації й витрат?
Перевірка запасів
Що перевірити:
залишки за складами;
партійний облік;
серійний облік;
собівартість;
переміщення;
списання;
інвентаризації;
відповідність бухгалтерським проводкам.
Перевірка платежів
Контрольні точки:
банківські виписки;
касові документи;
еквайринг;
взаємозаліки;
аванси;
курсові різниці;
зв’язок оплат із договорами та документами реалізації/закупівлі.
Етап 5. Мапінг BAS → SAF-T UA
Побудувати матрицю мапінгу
Приклад структури матриці:
SAF-T блок | SAF-T елемент | Джерело BAS | Об’єкт BAS | Правило трансформації | Ризик |
Header | Company ID | Довідник Організації | Организация. Код по ЕДРПОУ | Передати без пробілів | Відсутній або старий код |
Customers | Customer ID | Довідник Контрагенти | Контрагент. Код | Унікальний ID | Дублікати |
Suppliers | Tax Registration Number | Контрагенти | ІПН/ЄДРПОУ | Валідація формату | Неповні дані |
Products | Product Code | Номенклатура | Артикул/Код | Унікальний код | Дублікати SKU |
General Ledger Entries | Account ID | План рахунків | Рахунок Дт/Кт | Мапінг рахунку | Нестандартні рахунки |
Source Documents | Invoice No | Реалізація/Надходження | Номер документа | Нормалізація номера | Ручні документи |
Окремо описати нестандартні об’єкти
Якщо у BAS є дороблені документи, потрібно вирішити:
чи потрапляють вони в SAF-T UA;
як вони пов’язані з проводками;
чи є первинними документами;
які поля є джерелом для XML;
хто відповідає за методологію їх інтерпретації.
Версіонувати правила мапінгу
Кожна зміна в XSD або технічному описі має відображатися у версії мапінгу. ДПС періодично оновлювала технічні матеріали та публікувала релізи, тому компанії потрібно мати процес управління змінами.
Етап 6. Очищення та нормалізація даних
Контрагенти
Очистити:
дублікати;
контрагентів без кодів;
некоректні адреси;
неактуальні банківські рахунки;
договори без номерів і дат;
“службових” контрагентів.
Номенклатура
Очистити:
дублікати позицій;
різні одиниці для одного товару;
“послуги” в товарних групах;
товари без кодів;
неактуальні SKU;
некоректні ставки ПДВ.
Документи
Перевірити:
проведені/непроведені документи;
документи без проводок;
проводки без документів;
ручні операції;
сторно;
коригування;
закриття місяця;
регламентні операції.
Проводки
Перевірити:
баланс Дт/Кт;
незаповнені субконто;
проводки на технічні рахунки;
операції за закритими періодами;
ручні зміни рухів документа;
відповідність первинним документам.
Етап 7. Технічна реалізація в 1C/BAS
Є три базові варіанти.
Варіант A.Внутрішня розробка в BAS | Варіант B.Готовий модуль SAF-T UA | Варіант C.Проміжне сховище / SAF-T Connector |
Плюси:
| Плюси:
| Плюси:
|
Мінуси:
| Мінуси:
| Мінуси:
|
На ринку вже є модулі, які позиціонуються для формування SAF-T UA з BAS, УТП, ERP та інших облікових систем, включно з XSD -перевіркою, збереженням файлів, переглядом, редагуванням і експортом XML.
Етап 8. Валідація SAF-T UA
Технічна валідація
Технічна перевірка має встановити:
XML відповідає XSD;
усі обов’язкові поля заповнені;
дати в правильному форматі;
числові поля коректні;
кодування правильне;
файл не перевищує обмеження;
структура відповідає актуальній версії;
посилання між елементами не “биті”.
ДПС публікує XSD -схеми та приклади SAF-T UA, що дозволяє проводити технічну перевірку на відповідність структурі.
Бухгалтерська валідація
Потрібно перевірити:
баланс дебету і кредиту;
відповідність оборотів Головній книзі;
відповідність залишків ОСВ;
відповідність декларації з ПДВ;
відповідність фінансовій звітності;
коректність закриття періоду;
відсутність “висячих” аналітик;
відповідність документів проводкам.
Податкова валідація
Перевіряються:
ставки ПДВ;
податкові накладні;
операції з нерезидентами;
імпорт/експорт;
акцизні товари, якщо є;
податкові різниці;
операції з пов’язаними особами;
трансфертне ціноутворення, якщо застосовно.
Логічна валідація
Приклади тестів:
документ реалізації має мати контрагента, договір, номенклатуру, суму, ПДВ;
оплата має бути пов’язана з контрагентом і банківським рахунком;
рух запасу має мати склад і номенклатуру;
ОЗ має мати інвентарний номер;
проводка має мати документ-джерело або обґрунтовану ручну операцію;
сума документа має відповідати сумі проводок.
Етап 9. Тестове формування файлу
Рекомендовано не чекати перевірки, а провести кілька ітерацій.
Мінімальний план тестування
Інтеграція | Період | Мета | |
1 | 1 місяць | Перевірити технічне формування XML | |
2 | квартал | Перевірити обсяг, продуктивність, повноту | |
3 | півріччя | Перевірити сталість правил і якість даних | |
4 | рік | Провести повний dry run перед аудитом |
Професійні джерела рекомендують не відкладати підготовку, оскільки процес аналізу даних, налаштування мапінгу і формування SAF-T UA є тривалим і трудомістким.
Етап 10. Регламенти та контроль
Регламент щомісячної перевірки
Щомісяця після закриття періоду потрібно виконувати:
контроль довідників;
контроль незаповнених субконто;
контроль ручних операцій;
контроль закриття місяця;
контроль розбіжностей між BAS і податковою звітністю;
тестове формування SAF-T за місяць;
протокол помилок;
план виправлення.
Регламент змін у BAS
Будь-яка зміна конфігурації має проходити SAF-T impact assessment:
чи змінює документ проводки;
чи змінює регістри;
чи додає нові реквізити;
чи впливає на мапінг;
чи потребує оновлення правил експорту;
чи впливає на XML.
Регламент master data
Для довідників потрібні правила:
хто створює контрагента;
хто перевіряє код ЄДРПОУ/ІПН;
хто затверджує договір;
хто створює номенклатуру;
хто контролює одиниці виміру;
хто блокує дублікати;
хто відповідає за архівування.
Типові помилки великого бізнесу при підготовці SAF-T UA
Помилка 1. “Це завдання програмістів”
Насправді SAF-T UA — це насамперед завдання методології обліку і якості даних. Програміст може сформувати XML, але не може самостійно вирішити, як інтерпретувати некоректні контракти, ручні проводки, нестандартні рахунки або розриви між первинкою і проводками.
Помилка 2. “У нас BAS типова — значить, усе готово”
Навіть типова BAS -база може містити роки ручних операцій, неповні довідники, дублікати контрагентів, нестандартні схеми документів і закриття періоду. SAF-T UA вимагає не просто типової конфігурації, а якісно заповнених даних.
Помилка 3. “Зробимо, коли прийде запит”
Для великих платників у професійних роз’ясненнях згадується строк надання електронних документів після запиту контролюючого органу під час перевірки, зокрема два робочі дні в контексті порядку надання документів ВПП в електронній формі.
За такий строк неможливо якісно очистити довідники, виправити мапінг, протестувати XML і пояснити розбіжності.
Помилка 4. “Головне — пройти XSD”
XSD -перевірка підтверджує лише технічну валідність структури. Вона не гарантує бухгалтерської коректності, податкової логіки, відповідності первинним документам, відсутності ризикових операцій або правильності облікової політики.
Помилка 5. “SAF-T не стосується управлінського обліку”
Якщо управлінські документи впливають на бухгалтерські проводки або є джерелом первинних даних, вони непрямо впливають на SAF-T UA. Особливо це актуально для виробництва, логістики, мережевого ритейлу, агро, дистрибуції, імпорту та холдингових структур.
Коментарі