Коротко
- ДПС оприлюднила на вебпорталі документ «Типові технічні помилки автоматизованої перевірки даних файлу SAF-T UA» — орієнтовно 24–25 вересня 2026 року.
- Документ підготовлено за результатами тестування файлів SAF-T UA та практичного досвіду взаємодії ДПС із платниками, у відповідь на запити бізнесу щодо роз'яснення технічних помилок.
- Перелік має дві частини: «Перевірка обмежень ідентифікації (key / keyref)» — 116 перевірок із кодами FE, і «Перевірка логічної узгодженості та цілісності даних» — 18 перевірок із кодами RE.
- FE-перевірки — це, по суті, перевірки посилальної цілісності: чи кожне значення-посилання (код рахунку, контрагента, типу податку, одиниці виміру тощо) існує у відповідному довіднику файлу.
- RE-перевірки — це перевірки логічної та довідкової узгодженості даних: частина з них (п'ять) є бухгалтерськими балансовими контрольними співвідношеннями (Головна книга, запаси, основні засоби, розрахунки з контрагентами), а решта — коректність класифікаторів (ІПН платників ПДВ, коди податків, країн, валют, УКТ ЗЕД/ДКПП).
- Для п'яти ключових балансових перевірок (RE-2–RE-6) документ прямо вказує допустиме відхилення — 100,00 грн.
- Це перший офіційний матеріал такого рівня деталізації: раніше точні контрольні співвідношення ДПС окремо не публікувала, і профільні видання лише загально згадували факт існування переліку.
- Для бізнесу практичний висновок незмінний: після базової XSD-валідації залишаються ще два окремі класи контролю — посилальна цілісність (FE) і логічна узгодженість (RE), тож XML, що пройшов XSD, ще не можна вважати готовим до автоматизованої перевірки ДПС.
Що за документ оприлюднила ДПС
Документ має назву «Типові технічні помилки автоматизованої перевірки даних файлу SAF-T UA» і опублікований на вебпорталі ДПС у форматі таблиці Excel. За інформацією профільних видань, ДПС підготувала перелік за результатами тестування файлів SAF-T UA та практичного досвіду взаємодії з платниками, а також у відповідь на численні запити бізнесу щодо роз'яснення технічних помилок. Це прямо підтверджує те, про що ми вже писали раніше: формування коректного SAF-T — це не одноразова технічна дія, а ітеративний процес, де без розуміння конкретних контрольних процедур складно одразу отримати чистий файл.
Це перший настільки деталізований матеріал ДПС щодо автоматизованих перевірок SAF-T UA. У попередніх публічних роз'ясненнях і профільних виданнях конкретні контрольні співвідношення та їхні допустимі відхилення окремо не наводились.
Кількості 116 перевірок FE і 18 перевірок RE — це власний підрахунок LUCAS за оприлюдненим Excel-файлом ДПС (кожна перевірка має окремий рядок з унікальним кодом), а не цифра, названа ДПС у супровідному тексті.
Два типи перевірок: FE і RE
Перелік структурований у два розділи, кожен зі своєю логікою перевірки:
- I. Перевірка обмежень ідентифікації (key / keyref) — коди FE. Це перевірки посилальної цілісності: чи існує в довідниках файлу (MasterFiles) кожне значення, на яке посилаються записи в інших розділах — наприклад, чи кожен код рахунку, вказаний у проводці, присутній у Таблиці рахунків.
- ІІ. Перевірка логічної узгодженості та цілісності даних — коди RE. Це перевірки логічної та довідкової узгодженості даних, частина яких є бухгалтерськими балансовими контрольними співвідношеннями: чи збалансовані залишки й обороти, чи коректні класифікатори (податкові коди, ІПН, коди країн і валют), чи узгоджені дані між розділами файлу.
Цей перелік варто розглядати як третій рівень контролю, окремий від того, про що ми писали в статті «Валідація SAF-T UA: XSD-схема, бізнес-правила і типові помилки»: XSD-валідація перевіряє відповідність XML структурі та обмеженням схеми; FE з нового переліку ДПС — насамперед посилальну цілісність (key/keyref) — чи кожне значення-посилання справді існує там, куди воно посилається; а RE — логічну та довідкову узгодженість даних, включно з бухгалтерськими контрольними співвідношеннями. Це три різні рівні перевірки, і проходження одного не гарантує проходження інших.
FE — перевірки ідентифікаційних обмежень (116 перевірок)
Усі 116 FE-перевірок побудовані за однаковою логікою: береться значення-посилання з конкретного розділу чи поля файлу (наприклад, код рахунку в рядку проводки) і перевіряється, що воно існує у відповідному ключовому довіднику (наприклад, у Таблиці рахунків). Якщо значення не знайдено — фіксується відхилення.
Для зручності нижче LUCAS згрупував окремі FE-перевірки ДПС за типом посилання. Це аналітичне групування статті; офіційний файл ДПС перелічує кожну перевірку окремим рядком зі своїм кодом, без такого укрупненого поділу.
| Група посилань | Кількість перевірок | Що перевіряється | Типова причина помилки |
|---|---|---|---|
| Код рахунку (AccountID / CorrespondingAccountID) → план рахунків | 24 | Чи кожен рахунок, використаний у проводках, продажах, закупівлях, платежах, запасах, активах, податкових різницях, існує в Таблиці рахунків | Рахунок використаний у операції, але не внесений (або внесений з помилкою) у довідник плану рахунків файлу |
| Тип податку (TaxType) → довідник типів податків | 13 | Чи тип податку, вказаний для товару, контрагента, власника чи в проводці, присутній у довіднику типів податків | Неузгодженість типу податку між довідником номенклатури/контрагентів і фактичними операціями |
| Код податку (TaxCode) → довідник кодів податків | 9 | Аналогічно для конкретного коду податку (наприклад, ставки ПДВ) | Застарілий або неправильно заведений код ставки податку |
| Постачальник (SupplierID) → довідник постачальників | 9 | Чи постачальник, зазначений в операції, присутній у довіднику постачальників | Дублікат або неузгоджена картка постачальника між модулями обліку |
| Аналітика: тип (AnalysisType) → довідник типів аналітики | 10 | Чи тип аналітичного обліку, застосований у записі, визначений у довіднику | Використання аналітики (субконто), не внесеної до відповідного довідника файлу |
| Аналітика: ідентифікатор (AnalysisID) → довідник значень аналітики | 10 | Чи конкретне значення аналітики існує в довіднику | Та сама проблема на рівні конкретного значення, а не типу аналітики |
| Клієнт (CustomerID) → довідник клієнтів | 7 | Чи клієнт, зазначений в операції, присутній у довіднику клієнтів | Дублікати контрагентів або розбіжність ідентифікаторів між довідниками |
| Власник / засновник (OwnerID) → підрозділ «Власники (засновники)» (Owners) | 7 | Чи ідентифікатор власника (засновника), використаний у проводках, платежах, запасах тощо, присутній у підрозділі «Власники (засновники)» довідників файлу | Неповний довідник засновників або розбіжність ідентифікаторів між операціями й цим довідником |
| Ідентифікатор операції (TransactionID) → розділ «Бухгалтерські операції» (GeneralLedgerEntries) | 7 | Чи посилання на операцію (у податкових різницях, продажах, закупівлях, платежах, активах) відповідає реальній транзакції, записаній у розділі «Бухгалтерські операції» | Розрив зв'язку між первинним документом чи допоміжним розділом і бухгалтерською проводкою |
| Одиниця виміру (UnitOfMeasure) → довідник одиниць виміру | 6 | Чи одиниця виміру товару/операції присутня у довіднику | Нестандартна чи застаріла одиниця виміру в номенклатурі |
| Тип операції (TransactionType) → довідник типів операцій | 5 | Чи тип операції (у проводках, продажах, закупівлях, активах, інших документах) визначений у довіднику | Використання типу операції, якого немає в довіднику TransactionFeatures |
| Код товару (ProductCode) → довідник номенклатури | 4 | Чи код товару в запасах, продажах, закупівлях відповідає довіднику номенклатури | Товар проданий чи списаний під кодом, відсутнім у довіднику запасів |
| Тип руху запасів (MovementType / MovementSubType) | 2 | Чи тип і підтип руху товару визначені у відповідному довіднику | Нестандартний тип складської операції |
| Інші поодинокі перевірки (StockAccountNo, AssetID, унікальність ключів) | 3 | Окремі перевірки — складський рахунок, ідентифікатор активу, унікальність значень ключів у файлі загалом | Дублікати ідентифікаторів або розрив зв'язку з конкретним активом |
Більшість FE-перевірок стосуються саме повноти й узгодженості довідників — тих самих проблем, про які ми писали в статтях про підготовку SAF-T із конкретних облікових систем: дублікати контрагентів, неповні довідники, розбіжності між модулями обліку. Офіційний перелік ДПС підтверджує, що саме ці категорії помилок є типовими на практиці, а не поодинокими випадками.
RE — перевірки логічної узгодженості (18 перевірок)
RE-перевірки — це перевірки логічної та довідкової узгодженості даних, частина яких є бухгалтерськими балансовими контрольними співвідношеннями. П'ять із вісімнадцяти — саме такі ключові балансові перевірки з явними контрольними співвідношеннями:
- RE-2. Збалансованість інформації на рахунках/субрахунках бухгалтерського обліку — залишок на початок періоду плюс рух за період (за даними проводок) має дорівнювати залишку на кінець періоду, а підсумки дебетових і кредитових залишків на початок і на кінець періоду мають збігатися між собою.
- RE-3. Збалансованість інформації про наявність і рух запасів — узгодженість даних розділів «Запаси» і «Операції із запасами» із рахунками Головної книги.
- RE-4. Збалансованість інформації про наявність і рух необоротних активів — узгодженість руху основних засобів (надходження, амортизація, вибуття) з відповідними рахунками.
- RE-5. Збалансованість розрахунків з покупцями та замовниками (дебіторська заборгованість).
- RE-6. Збалансованість розрахунків з постачальниками та підрядниками (кредиторська заборгованість).
Інші 13 перевірок стосуються коректності класифікаторів і довідкових даних: RE-1 — відповідність кодів рахунків/субрахунків Таблиці рахунків (з окремим урахуванням плану рахунків для банків); RE-7 і RE-18 — коректність і повнота зазначення індивідуальних податкових номерів платників ПДВ; RE-8 — коди податків для ПДВ; RE-9 — ідентифікатори груп активів для типу оцінки згідно з Податковим кодексом; RE-10 — ідентифікатори методів амортизації; RE-12 — ідентифікатори типів осіб; RE-13 — коди ознак пов'язаності (що прямо перетинається з темою трансфертного ціноутворення); RE-14 — коди валют; RE-15 — коди країн; RE-16 — коди одиниць виміру; RE-17 — коди УКТ ЗЕД / ДКПП. Окремо стоїть RE-11 — валідація відповідності поданого файлу параметрам запиту ДПС (період, обсяг).
Чому важливе «допустиме відхилення»
Для п'яти ключових балансових перевірок (RE-2–RE-6) документ явно вказує допустиме відхилення — 100,00 грн. Це технічний поріг відповідного контрольного співвідношення: різниця в межах цієї суми не вважається відхиленням. Причину конкретної різниці — як у межах порогу, так і понад нього — потрібно аналізувати за вихідними обліковими даними; документ сам по собі не роз'яснює походження кожної конкретної розбіжності. Перевищення порогу означає непроходження відповідного контрольного співвідношення.
До кожної з цих п'яти перевірок додається окрема пояснювальна таблиця — по суті, шаблон оборотно-сальдової відомості чи відомості розрахунків з переліком колонок, за якими ДПС рахує контрольні суми. Це практично означає, що платник може заздалегідь перевірити файл за оприлюдненою ДПС логікою відповідних автоматизованих контрольних співвідношень — хоча й без гарантії, що опублікований перелік вичерпно відтворює всю внутрішню логіку виробничої системи ДПС.
Що це означає практично для платників
Новий перелік показує, що після базової XSD-валідації залишаються два окремі великі класи контролю: посилальна цілісність даних (FE) та їх логічна узгодженість (RE). Тому XML, який проходить XSD, ще не можна вважати готовим до автоматизованої перевірки ДПС. Для компаній, які готують SAF-T, з цього випливає кілька практичних висновків:
- Перед поданням файлу варто перевіряти не лише XSD-валідність, а систематично проходити FE- і RE-перевірки — особливо п'ять балансових контрольних співвідношень із допустимим відхиленням 100 грн.
- Якість довідників (контрагентів, номенклатури, типів операцій, аналітики) — не формальність, а джерело більшості FE-помилок на практиці.
- Узгодженість даних між розділами файлу (наприклад, запаси й рухи запасів, активи й операції з активами) важливіша, ніж здається на перший погляд — саме на це розраховані RE-перевірки.
- Перелік варто використовувати як практичний чекліст під час побудови внутрішньої валідації SAF-T-рішення — незалежно від того, яка облікова система є джерелом даних.
Повний офіційний текст переліку з детальним описом кожної перевірки, умовами й рекомендаціями ДПС публікує на своєму вебпорталі в розділі, присвяченому SAF-T UA.
Що новий перелік змінює для SAF-T-рішень
Для розробників і впроваджувачів SAF-T-рішень оприлюднений перелік — це не просто довідкова інформація, а готовий матеріал для побудови автоматизованої валідації. FE- і RE-перевірки більше не варто проходити вручну чи «на око»: їх можна й варто перетворити на автоматизовані validation rules, які проганяють файл до фактичного подання. Такі правила доцільно включати в регресійне тестування SAF-T-рішення — щоб зміна мапінгу чи джерела даних не ламала вже пройдені перевірки непомітно. Після оновлення XSD-схеми чи появи нових роз'яснень ДПС шар валідації потрібно оновлювати окремо — він не оновлюється сам по собі. І для кожної перевірки корисно мати простежуваність (traceability) до конкретного вихідного поля й правила мапінгу, з якого походить значення, — це істотно пришвидшує виправлення, коли перевірка не проходить.
Головний висновок тут практичний: якісне SAF-T-рішення має не лише генерувати XML, а й до подання автоматично проганяти файл через максимально повний набір оприлюднених ДПС контролів.
Часті запитання
Що таке перелік типових технічних помилок SAF-T UA?
Це офіційний документ ДПС, який описує автоматизовані перевірки файлу SAF-T UA після проходження XSD-валідації — 116 перевірок ідентифікаційних обмежень (FE) і 18 перевірок логічної узгодженості даних (RE).
Чим FE-перевірки відрізняються від RE-перевірок?
FE перевіряють посилальну цілісність (key/keyref) — чи кожне значення-посилання (код рахунку, контрагента, типу податку тощо) існує у відповідному довіднику файлу. RE перевіряють логічну та довідкову узгодженість даних — частина цих перевірок є бухгалтерськими балансовими контрольними співвідношеннями, інші — перевірки коректності класифікаторів.
Чи означає проходження XSD-схеми, що файл пройде й ці перевірки?
Ні. XSD підтверджує лише відповідність XML структурі та обмеженням схеми. FE (посилальна цілісність) і RE (логічна й довідкова узгодженість) — це окремі рівні контролю, і проходження XSD жодного з них не гарантує.
Яке допустиме відхилення для балансових перевірок?
Для п'яти ключових контрольних співвідношень (RE-2–RE-6 — Головна книга, запаси, необоротні активи, розрахунки з покупцями і постачальниками) документ прямо вказує допустиме відхилення 100,00 грн.
Які перевірки найчастіше пов'язані з довідником контрагентів?
Перевірки груп CustomerID (7 перевірок) і SupplierID (9 перевірок) — вони фіксують відхилення, коли контрагент, зазначений в операції, не знайдений у відповідному довіднику файлу, що найчастіше трапляється через дублікати карток контрагентів.
Чи стосується перелік лише великих платників?
Самі оприлюднені правила технічної перевірки файлу релевантні будь-якому SAF-T UA, сформованому за відповідною схемою. Водночас обов'язок подавати SAF-T UA залежить від статусу платника, виду перевірки та чинних норм законодавства — ці питання перелік технічних помилок не регулює.
Де можна ознайомитися з повним текстом переліку?
Документ опублікований на вебпорталі ДПС у розділі, присвяченому SAF-T UA, у форматі таблиці Excel з описом кожної перевірки, умовами застосування та рекомендаціями.
Висновок
Перелік типових технічних помилок SAF-T UA — перший настільки деталізований офіційний матеріал ДПС про автоматизовані перевірки файлу, і він підтверджує практичний досвід, накопичений у проєктах підготовки SAF-T: основна складність — не в генерації XML, а в якості довідників і узгодженості даних. 116 FE-перевірок показують, наскільки системно податкова контролює посилальну цілісність файлу, а 18 RE-перевірок — наскільки серйозно перевіряється логічна та довідкова узгодженість даних, включно з конкретними бухгалтерськими контрольними співвідношеннями й допустимим відхиленням. Компаніям, які готуються до подання SAF-T UA, варто використовувати цей перелік як практичний чекліст ще на етапі внутрішньої валідації — до фактичного запиту ДПС.
Автоматична валідація у SAF-T Connector.
XSD-валідація та перевірка за оприлюдненими ДПС FE/RE-контролями вбудовані в SAF-T Connector від LUCAS — помилки виявляються до фактичного подання, а не після.