Формат SAF-T UA стає одним із ключових інструментів податкового контролю в Україні. Він базується на міжнародному стандарті OECD та передбачає передачу податковим органам повного зрізу бухгалтерських даних у структурованому XML-вигляді. На відміну від звичайних регламентованих звітів, це комплексний файл із довідниками, проводками, первинними документами та історією обліку — фактично «цифровий близнюк» вашої фінансової системи.
У цій статті ми розглянемо практичні етапи переходу на SAF-T UA, вимоги ДПС, типові помилки та алгоритм підготовки BAS до звітності нового покоління.
SAF-T UA — що це означає для підприємців
Мова йде про стандартизований файл, побудований за методологією OECD, який містить повний набір бухгалтерських даних у структурованому XML-форматі. Він дозволяє податковим органам швидко аналізувати облік без додаткових запитів і вибіркових перевірок.
Для підприємств, які працюють у BAS, це означає необхідність завчасної технічної та методологічної підготовки. Формат вимагає чіткої структури даних: коректних довідників, узгоджених планів рахунків, повних історичних записів і правильних зв’язків між документами та регістрами. Будь-яка невідповідність може унеможливити експорт або призвести до некоректного читання файлу ДПС.
Важливо: конфігурації BAS не містять вбудованого механізму формування SAF-T UA. Для цього потрібно встановити окремий Модуль SAF-T UA для BAS, а його інтеграція включає підготовку бази, налаштування алгоритмів заповнення, коригування довідників, перевірку структури даних і тестові вивантаження.
Законодавчі вимоги SAF-T в Україні
Впровадження SAF-T — це перехід до прозорої податкової звітності та автоматизованих перевірок. ДПС рухається за стандартами OECD, які вже працюють у Польщі, Литві, Португалії, Румунії та інших країнах. Логіка проста: податковим органам потрібен єдиний формат даних, який можна швидко аналізувати без додаткових запитів і документів. Бізнесу — прогнозованість і мінімум дублюючої роботи.
На сьогодні SAF-T UA перебуває в стані поетапного запуску. ДПС вже визначила основну структуру XML-файлу та тестує механізми приймання. Обов’язковість звітування вводитиметься поступово, але компаніям, які працюють у BAS, варто готуватися заздалегідь — формат напряму пов’язаний з якістю даних у системі.
Хто фактично має готувати SAF-T UA:
- підприємства, що використовують BAS/облікові системи старого покоління або інші ERP-системи;
- компанії, які потрапляють під документальні перевірки;
- бізнес, щодо якого ДПС проводить ризикоорієнтований аналіз і може вимагати файл SAF-T для детального перегляду обліку.
Формат прописує чітку структуру даних. SAF-T UA очікувано містить:
- MasterFiles — довідники (контрагенти, номенклатура, план рахунків, податкові ставки);
- GeneralLedgerEntries — бухгалтерські проводки, регістри, обороти;
- SourceDocuments — первинні документи (реалізація, закупівлі, банківські й касові операції);
- додаткові таблиці, що описують господарські процеси.
Головна вимога ДПС — цілісність і синхронність даних, які буде містити бухгалтерія SAF-T. Вимоги до кожного подавача: усі довідники, проводки, регістри та документи мають формувати єдину логічну модель. Будь-які дублікати, розриви у зв’язках або застарілі записи стають критичними під час формування та валідації файлу. Податкова система очікує структурований XML, у якому кожен довідник і кожна операція формально узгоджені.
Іншими словами, SAF-T UA — це вимога до «гігієни» бухгалтерських даних і здатності компанії швидко надати повний зріз обліку в машинозчитуваному форматі.
Як підготуватися до переходу на SAF-T
Підготовка до SAF-T UA вимагає повної узгодженості даних, а отже — системної роботи з BAS, довідниками, документами й регістрами. Рекомендовано рухатися поетапно: від технічної готовності системи до перевірки структури XML і тестових вивантажень.
Перевірка готовності BAS
Перший крок — оцінити, чи готова ваша облікова система до роботи з форматом SAF-T. Оскільки Модуль SAF-T UA для BAS не входить до стандартних продуктів, важливо переконатися, що:
- модуль коректно встановлений на робочі бази BAS;
- система оновлена до актуального релізу, сумісного з модулем;
- налаштовані довідники, облікові політики та механізми обміну.
На цьому етапі важливо:
- Перевірити конфігурацію BAS. Чи коректно встановлено розширення та обробки, що відповідають за формування даних SAF-T.
- Оцінити якість довідників. SAF-T UA вимагає актуальних кодів контрагентів, коректного плану рахунків, валідних одиниць виміру й податкових ставок.
- Переглянути відповідність структури обліку. Наприклад, рахунки мають бути узгоджені з регістрами, а документи — мати зв’язки з проводками.
У практиці впроваджень саме цей блок дає найбільше помилок. Якщо в BAS накопичені дублікати контрагентів або історичні записи в довідниках, їх потрібно ліквідувати ще до тестової генерації файлу.
Формування SAF-T файлів у системі
Після встановлення Модуля SAF-T UA для BAS та технічної підготовки можна переходити до генерації SAF-T. Механізм реалізований як експорт у структуру XML, що включає основні секції:
- MasterFiles — довідники;
- GeneralLedgerEntries — бухгалтерські записи;
- SourceDocuments — документи операційного обліку.
Що потрібно налаштувати:
- Параметри експорту. Дати, період, обсяг даних, включення історії довідників.
- Правила заповнення реквізитів. Неповні або некоректні поля викликають помилки валідації.
- Тестовий файл SAF-T. Рекомендовано формувати кілька варіантів — за короткий період, за повний місяць, із повною історією.
Тестування передачі звітності
Формат SAF-T UA жорстко структурується, тому тестування — обов’язковий етап. Він включає:
- Валідацію XML-файлу. Перевірку структури, тегів, типів даних, символів, форматів дат.
- Контроль бізнес-логіки. Наприклад: документ реалізації повинен мати контрагента, ставка ПДВ — відповідати довіднику.
Типові помилки:
- розірвані зв’язки між документами й проводками;
- некоректні або дубльовані коди;
- «порожні» поля в довідниках;
- різні формати дат;
- неузгодженість рахунків у документах та в головній книзі.
Після проходження всіх тестів компанія отримує повне розуміння, наскільки її система відповідає вимогам обміну даними SAF-T і чи готова вона до роботи у форматі. У більшості випадків ми рекомендуємо формувати кілька тестових пакетів, щоб мати повну картину того, як працює звітність SAF-T: наприклад, за короткий місяць, повний квартал чи з окремим акцентом на MasterFiles та GeneralLedgerEntries.
Типові помилки при налаштуванні SAF-T
Попри стандартизовану структуру SAF-T UA, більшість компаній стикаються з однаковими технічними й методологічними проблемами. Це не стільки помилки BAS, скільки наслідки накопичених неточностей у даних, «історичних» довідників і різних підходів до ведення обліку всередині підприємства. Нижче — основні ризикові зони.
1. Неправильна структура або формат XML
SAF-T — це жорсткий формат. Будь-яке відхилення від схеми (відсутній тег, зайвий атрибут, неправильний тип даних) призводить до відмови у валідації.
Типові сценарії:
- невірний формат дати (наприклад, «01.01.2024» замість ISO «2024-01-01»);
- символи, не сумісні з XML;
- порожні обов’язкові вузли;
- змішування числових і текстових значень у полях сум.
Такі помилки неможливо «обійти» вручну — потрібно виправляти структуру або первинні дані.
2. Неповні або «засмічені» довідники
Одна з ключових вимог структури файлу SAF-T — цілісність даних. Проблеми виникають, коли:
- контрагенти дублюються з різними кодами;
- номенклатура має однакові назви, але різні ідентифікатори;
- одиниці виміру, ставки податків чи групи товарів заповнені частково;
- довідники містять неактуальні або застарілі записи.
SAF-T формує повну історію MasterFiles, тому некоректні записи «спливають» автоматично.
3. Використання застарілих версій BAS
У старих релізах відсутні:
- актуальні механізми формування даних для SAF-T;
- оновлені довідники;
- схеми XML та механізми валідації.
У результаті формуються файли, які не відповідають актуальній структурі ДПС, або дані експортуються частково.
4. Помилки у зв’язках між бухгалтерськими та реєстраційними даними
Тут виникають складні випадки:
- документ має проводки, але відсутні записи у регістрах;
- змінились типи документів, але історичні записи не оновлені;
- суми в регістрах і головній книзі не збігаються;
- неузгоджені рахунки (наприклад, у документах використані старі субрахунки).
Для SAF-T це критично, оскільки секції GeneralLedgerEntries та SourceDocuments повинні бути повністю синхронізованими.
5. Відсутність автоматизованих перевірок перед експортом
Компанії часто запускають експорт одразу, без попередньої перевірки. Це призводить до:
- великої кількості XML-помилок;
- некоректних сум у проводках;
- пропущених обов’язкових реквізитів;
- повторних ітерацій формування файлу.
Найкраща практика — автоматизована перевірка даних у BAS перед створенням SAF-T-файлу: контроль дублювання, аналіз заповнення, валідація рахунків.
Висновок
Перехід на SAF-T UA — це перевірка того, наскільки коректно працює ваша облікова система, наскільки структуровані довідники та наскільки стабільною є логіка бухгалтерських процесів. Чим раніше компанія почне підготовку BAS і впровадження Модуля SAF-T UA для BAS, тим менше ризиків отримати некоректний файл, помилки валідації або затримки при поданні даних до ДПС.
Якщо ви хочете пройти перехід без технічних збоїв і зайвих ітерацій — замовте консультацію наших фахівців BAS. Ми допоможемо встановити модуль, налаштувати формат, перевірити структуру даних і уникнути помилок при звітності.
