У якій формі та якому форматі великі платники податків зобов’язані надавати документи (інформацію), що належать або пов’язані з предметом перевірки, на належним чином оформлений письмовий запит контролюючого органу?
Згідно з підпунктом 16.1.5 пункту 16.1 статті 16 Податкового кодексу України (далі – Кодекс) платник податків зобов’язаний подавати на належним чином оформлену письмову вимогу контролюючих органів (у випадках, визначених законодавством) документи з обліку доходів, витрат та інших показників, пов’язаних із визначенням об’єктів оподаткування (податкових зобов’язань), первинні документи, регістри бухгалтерського обліку, фінансову звітність, інші документи, пов’язані з обчисленням та сплатою податків та зборів. У письмовій вимозі обов’язково зазначаються конкретний перелік документів, які повинен надати платник податків, та підстави для їх надання.
Відповідно до вимог пункту 85.2 статті 85 Кодексу платник податків зобов’язаний надати посадовим (службовим) особам контролюючих органів у повному обсязі всі документи, що належать або пов’язані з предметом перевірки. Такий обов’язок виникає у платника податків після початку перевірки.
При цьому великий платник податків (далі – ВПП) на запит контролюючого органу зобов’язаний також надати посадовим (службовим) особам контролюючих органів засобами електронного зв’язку в електронній формі з дотриманням вимог законів України «Про електронні документи та електронний документообіг» та «Про електронну ідентифікацію та електронні довірчі послуги» копії таких документів, що створюються ним в електронній формі з обліку доходів, витрат та інших показників, пов’язаних із визначенням об’єктів оподаткування (податкових зобов’язань), первинних документів, регістрів бухгалтерського обліку, фінансової звітності, інших документів, пов’язаних з обчисленням та сплатою податків і зборів, не пізніше двох робочих днів, наступних за днем отримання запиту.
Для платників податків, які відповідно до пункту 85.2 статті 85 Кодексу зобов’язані надавати інформацію в електронному вигляді, загальний формат та порядок подачі такої інформації визначаються центральним органом виконавчої влади, що забезпечує формування та реалізує державну фінансову політику. У разі невстановлення електронного формату та порядку надання такої інформації платник податків звільняється від обов’язку подання її в електронній формі.
На виконання вимог пункту 85.2 статті 85 Кодексу загальний формат та порядок подачі такої інформації визначено наказом Міністерства фінансів України від 07.11.2011 № 1393 «Про затвердження Порядку надання документів великого платника податків в електронній формі», зареєстрованим у Міністерстві юстиції України 16.01.2012 за № 44/20357, зі змінами та доповненнями, внесеними наказом Міністерства фінансів України від 15.09.2020 № 561 «Про затвердження Змін до Порядку надання документів великого платника податків в електронній формі при проведенні документальної перевірки», зареєстрованим у Міністерстві юстиції України 12.11.2020 за № 1123/35406 (далі – Порядок), що набрали чинності з 27 серпня 2021 року.
Цим Порядком визначено формат і структуру надання документів ВПП на запит контролюючого органу в електронній формі, що належать або пов’язані з предметом перевірки.
Пунктом 3.2 розділу III Порядку передбачено, що електронні документи (інформація) ВПП надаються у форматі XML у вигляді стандартного аудиторського файлу (SAF-T UA), який представляє собою електронний файл стандартизованої структури, що містить експортовані з вихідної системи обліку дані про наявність та стан активів, власного капіталу та зобов’язань, а також інформацію щодо змін у фінансово-господарському стані суб’єкта господарювання за певний період. Структура надання електронних документів (інформації) ВПП (стандартний аудиторський файл (SAF-T UA)) наведена у додатку до Порядку.
Згідно з пунктом 2.4 розділу II Порядку контролюючими органами забезпечуються:
надання відомостей про формат електронних документів (інформації) ВПП шляхом їх розміщення на офіційному веб-порталі Державної податкової служби України;
направлення ВПП запиту у довільній формі про надання електронних документів (інформації) ВПП та відомостей про можливі способи їх подання, електронну адресу та контактні телефони відповідальних осіб;
приймання електронних документів (інформації) ВПП відповідно до встановлених вимог;
зберігання отриманих електронних документів (інформації) ВПП.
На веб-порталі ДПС створено банер «SAF-T UA», в якому розміщено інформацію щодо стандартного аудиторського файлу, в тому числі Детальний технічний опис елементів SAF-T UA та XSD (визначення схеми XML) для SAF-T UA, які призначені для платників податків, розробників і постачальників програмного забезпечення, які мають на меті включити функцію експорту даних з вихідної системи обліку згідно з вимогами до SAF-T UA.
У разі внесення змін до XSD SAF-T UA, яку версію структури XML слід використовувати для формування та подання SAF-T UA?
Формувати та надавати SAF-T UA на належним чином оформлений письмовий запит контролюючого органу необхідно згідно з останньою актуальною версією XSD SAF-T UA, розміщеною на офіційному веб-порталі ДПС.
Чи є розроблене програмне забезпечення для формування SAF-T UA?
Відповідно до пункту 2.1 розділу ІІ Порядку для надання електронних документів (інформації) ВПП до контролюючих органів, що проводять перевірку, платник податків повинен мати:
програмне забезпечення з ведення бухгалтерського обліку для формування електронних документів (інформації) ВПП у визначеному цим Порядком форматі;
доступ до мережі Інтернет та можливість відправлення/приймання електронних повідомлень по електронній пошті;
отримані у кваліфікованого надавача електронних довірчих послуг кваліфіковані сертифікати відкритих ключів посадових осіб юридичної особи, що мають право підпису (керівника, бухгалтера), та/або кваліфікованої електронної печатки (за наявності).
Державна податкова служба України не є розробником програмного забезпечення для формування SAF-T UA.
Якими засобами телекомунікаційного зв’язку приймається SAF-T UA?
Згідно з пунктом 2.2 розділу ІІ Порядку для приймання електронних документів (інформації) ВПП від платника податків контролюючий орган повинен мати:
програмне забезпечення приймання та обробки електронних документів (інформації) ВПП із надійними засобами кваліфікованого електронного підпису чи печатки для накладання та перевірки кваліфікованого електронного підпису та направленого шифрування електронного документа (інформації) ВПП;
чинні кваліфіковані сертифікати відкритих ключів, сформовані кваліфікованим надавачем для контролюючого органу.
Приймання SAF-T UA здійснюється через електронний кабінет.
Якщо ВПП не має технічної можливості надіслати SAF-T UA до контролюючого органу засобами телекомунікаційного зв’язку, чи передбачена можливість подати файл в інший спосіб (наприклад, на електронному носії)?
Відповідно до пункту 3.5 розділу ІІІ Порядку електронні документи (інформація) ВПП надсилаються до контролюючого органу засобами телекомунікаційного зв’язку.
Пунктом 3.6 розділу ІІІ Порядку передбачено, що при прийманні електронних документів (інформації) ВПП від платника податків контролюючим органом здійснюється їх розшифрування, перевіряється кваліфікований електронний підпис, визначається відповідність електронного документа (інформації) ВПП, надісланого засобами телекомунікаційного зв’язку, затвердженому формату.
При надходженні електронних документів (інформації) ВПП засобами телекомунікаційного зв’язку здійснюється також їх автоматизована перевірка відповідно до Порядку обміну електронними документами з контролюючими органами, затвердженого наказом Міністерства фінансів України від 06.06.2017 № 557, зареєстрованого в Міністерстві юстиції України 03.08.2017 за № 959/30827 (далі – Порядок № 557).
Подання SAF-T UA до контролюючого органу в інший спосіб (наприклад, на електронному носії) не передбачено.
Згідно з пунктом 3.8 розділу ІІІ Порядку у випадку виникнення у посадових осіб контролюючого органу під час проведення перевірки необхідності у розгляді і дослідженні електронних документів (інформації) ВПП, не наданих платником податків, ВПП зобов’язаний забезпечити доступ посадових осіб контролюючого органу до електронних документів (інформації) ВПП за місцезнаходженням платника податків та його підрозділів (при проведенні документальних виїзних перевірок) або додатково надати електронні документи (інформацію) ВПП, що належать або пов’язані з предметом перевірки, на вимогу контролюючого органу, не пізніше двох робочих днів, наступних за днем отримання запиту контролюючого органу, в порядку та обсязі, визначених у цьому запиті.
Чи може контролюючий орган встановити більш тривалий строк для підготовки та надання SAF-T UA, якщо специфіка роботи підприємства та значний обсяг документів (інформації) потребує більше часу ніж два робочі дні?
Пунктом 85.2 статті 85 Кодексу передбачено, що платник податків зобов’язаний надати посадовим (службовим) особам контролюючих органів у повному обсязі всі документи, що належать або пов’язані з предметом перевірки. Такий обов’язок виникає у платника податків після початку перевірки.
При цьому ВПП на запит контролюючого органу зобов’язаний також надати посадовим (службовим) особам контролюючих органів засобами електронного зв’язку в електронній формі з дотриманням вимог законів України «Про електронні документи та електронний документообіг» та «Про електронну ідентифікацію та електронні довірчі послуги» копії таких документів, що створюються ним в електронній формі з обліку доходів, витрат та інших показників, пов’язаних із визначенням об’єктів оподаткування (податкових зобов’язань), первинних документів, регістрів бухгалтерського обліку, фінансової звітності, інших документів, пов’язаних з обчисленням та сплатою податків і зборів, не пізніше двох робочих днів, наступних за днем отримання запиту.
Якщо специфіка роботи підприємства та значний обсяг документів (інформації) потребує більшого часу ніж два робочі дні для підготовки SAF-T UA, платник податків може завчасно формувати SAF-T UA для дотримання строків, визначених законодавством.
У яких випадках SAF-T UA може бути відхилений?
Відповідно до пункту 7 розділу ІІ Порядку № 557 автоматизована перевірка електронного документа включає:
підтвердження дійсності кваліфікованого або удосконаленого електронного підпису та печатки (за наявності), що базуються на кваліфікованому сертифікаті електронного підпису та кваліфікованому сертифікаті електронної печатки за умов, встановлених Законом України «Про електронну ідентифікацію та електронні довірчі послуги»;
перевірку обов’язковості та послідовності накладання на електронний документ кваліфікованого або удосконаленого електронного підпису та печатки (за наявності), що базуються на кваліфікованому сертифікаті електронного підпису та кваліфікованому сертифікаті електронної печатки підписувачів у встановленому порядку;
перевірку відповідності електронного документа затвердженому формату (стандарту);
перевірку обов’язкових реквізитів;
перевірку права підпису електронного документа підписувачем.
Згідно з Детальним технічним описом елементів SAF-T UA файли даних SAF-T UA, надіслані до ДПС суб’єктами господарювання в XML-форматі, проходять контроль (валідацію) із застосуванням схеми контролю XML-документів (файл XSD). Це перший рівень контролю даних файлу SAF-T UA, після якого формується перша квитанція.
У стовпці «Валідація» для окремих елементів відображена умова, за якою буде проходити валідація даних, які будуть розміщуватися в зазначеному елементі. Це другий рівень контролю даних файлу SAF-T UA, після якого формується друга квитанція.
При цьому, зі структури XSD видалена валідація «Ключ-Посилання»; перевірка валідності даних «Ключ-Посилання» здійснюється на рівні системи обробки звітності ДПС України (друга квитанція).
Пунктом 3.7 розділу ІІІ Порядку передбачено, що підтвердженням прийняття та реєстрації або відхилення контролюючим органом електронних документів (інформації) ВПП є повідомлення, яке направляється платнику податків у вигляді електронного документа засобами телекомунікаційного зв’язку. У разі неодержання від контролюючого органу протягом двох робочих днів повідомлення про прийняття і реєстрацію або про відхилення електронного документа (інформації) ВПП відправник вживає додаткових заходів з використанням інших засобів зв’язку для одержання від адресата відповідного повідомлення.
У разі одержання від контролюючого органу повідомлення про відхилення електронного документа (інформації) ВПП відправником вживаються заходи для усунення причин відхилення і забезпечення повторного відправлення цього документа. Підтвердження факту одержання від контролюючого органу повідомлення щодо електронного документа (інформації) ВПП не здійснюється.
Як заповнюються елементи зі статусом «Mandatory», якщо інформація для їх заповнення відсутня в системі обліку суб’єкта господарювання та/або не передбачена Порядком?
Відповідно до Порядку у стовпчику «Обов’язковість заповнення» наявність позначки «*» означає, що показник (інформація) повинен обов’язково бути заповнений, відсутність такої позначки означає, що показник може бути заповнений у разі його наявності.
У таблиці 6 «Опис елементів SAF-T UA» Детального технічного опису елементів SAF-T UA наведено структуру таблиці з описом та призначенням кожного стовпця для правильної роботи з технічним описом елементів SAF-T UA.
Обов’язковість (Status) вказує, чи є елемент обов’язковим («Mandatory») або необов’язковим («Optional»). Під час передачі даних до ДПС технічний статус обов’язковості передбачає таку реалізацію положень Порядку:
статус «Mandatory» означає, що показник (інформація) повинен обов’язково бути заповнений;
необов’язкові елементи («Optional»), які передбачені Порядком, повинні бути заповнені в разі їх наявності;
необов’язкові елементи («Optional»), які не передбачені Порядком, можуть бути заповнені, якщо, на думку платника податків, це забезпечує більш повне відображення даних, що належать або пов’язані з предметом перевірки.
У деяких випадках статус «Optional» технічно реалізований через атрибут «minOccurs=”0″» у визначенні елементів вищого рівня XSD-схеми. Це означає, що елемент може бути не включений у XML-документ без порушення валідності, що, в свою чергу, робить усі вкладені (дочірні) елементи необов’язковими до заповнення.
Використання порожніх елементів можна інтерпретувати, ніби вони мають значення, тому порожні елементи не слід використовувати взагалі, якщо немає даних для заповнення необов’язкового елемента
Необов’язкові елементи («Optional»), які не передбачені Порядком, заповнюються у разі, якщо суб’єкт господарювання вважає, що у зв’язку зі специфікою ведення бухгалтерського обліку та/або особливостями роботи автоматизованого програмного забезпечення, яке використовується суб’єктом господарювання, доцільно внести додаткові елементи обліку та дані, які забезпечать більш повне та достовірне відображення інформації щодо обліку доходів, витрат, фінансового результату та інших показників, пов’язаних із визначенням об’єктів оподаткування, повнотою та своєчасністю сплати податків.
При цьому слід звернути увагу, що файл SAF-T UA розроблений на основі Рекомендацій ОЕСР щодо стандартного аудиторського файлу (версія 2.0), згідно з якими основне припущення полягає в тому, що всі елементи, включені в модель ОЕСР, є потенційно корисними для аудиторів.
Формування SAF-T UA повинно здійснюватися на основі даних вихідної системи обліку відповідно до обраної підприємством форми бухгалтерського обліку як певної системи регістрів обліку, порядку і способу реєстрації та узагальнення інформації в них з додержанням єдиних засад, встановлених Законом України від 16.07.1999 № 996-XIV «Про бухгалтерський облік та фінансову звітність в Україні» (далі – Закон № 996), та з урахуванням особливостей своєї діяльності і технології обробки облікових даних.
Чи потрібно у SAF-T UA відображати дані про особу або програму, яка здійснила запис операції в бухгалтерському обліку?
У елементі «Код джерела» (SourceID) відображаються дані про особу або програму, яка здійснила запис операції в бухгалтерському обліку (рекомендується обов’язкове заповнення).
Відображення цих даних відіграє важливу роль у забезпеченні контролю повноти та достовірності відображення інформації щодо обліку доходів, витрат, фінансового результату та інших показників, пов’язаних із визначенням об’єктів оподаткування, повнотою та своєчасністю сплати податків.
Дані про особу або програму, яка здійснила запис операції в бухгалтерському обліку, дозволяють використовувати механізми контролю достовірності даних, виявляти нетипові та підозрілі операції, аналізувати коригувальні дії тощо.
Що означає слеш у прикладах заповнення елементів SAF-T UA?
Відповідно до Детального технічного опису елементів SAF-T UA у стовпці «Приклад» відповідних елементів наводяться наочні приклади заповнення конкретного елемента для кращого розуміння природи даних.
У окремих випадках приклади заповнення елемента наведені комплексно:
шляхом посилання на довідники: приклади, які не є обмеженими списками ідентифікаторів;
через крапку з комою: декілька умовних значень, які більш наочно розкривають заповнення елемента складного типу;
через слеш: декілька умовних значень окремого заповнення елемента, які більш наочно розкривають комплексні приклади.
У Детальному технічному описі елементів SAF-T UA наведено комплексний приклад уцінки основного засобу (складського приміщення № 1), раніше не дооцінюваного, станом на 30.06.2021 р.:
первісна вартість на дату здійснення операції: 5 000 000,00 грн.;
балансова вартість на дату здійснення операції: 3 968 750,00 грн.;
знос на дату здійснення операції: 1 031 250,00 грн. (5 000 000,00 – 3 968 750,00);
справедлива вартість відповідно до звіту незалежного оцінювача: 3 000 000,00 грн.;
метод переоцінки: пропорційна зміна;
індекс переоцінки: 0,755906 (3 000 000,00 / 3 968 750,00).
Результати первинної уцінки складського приміщення № 1 відображені в прикладах елементів підрозділів «Необоротні активи» (Assets), «Податкові різниці» (TaxDifferences) та «Операції з необоротними активами» (AssetTransactions) через слеш як декілька умовних значень окремого заповнення згідно з такими проведеннями:
уцінка зносу (Дт 131 «Знос основних засобів» – Кт 103 «Будинки та споруди»): 251 721,94 грн. (1 031 250,00 х (1 – 0,755906));
уцінка залишкової вартості (Дт 975 «Уцінка необоротних активів і фінансових інвестицій» – Кт 103 «Будинки та споруди»): 968 748,06 грн. (5 000 000,00 х (1 – 0,755906) – 251 721,94).
У чому полягає суть підходу формування множини файлів SAF-T UA, які сформовані на основі завершеної порції даних?
Детальним технічним описом елементів SAF-T UA передбачено два основних підходи щодо формування файлів даних SAF-T UA:
формування одного файлу: полягає в тому, що один відбір даних призводить до формування одного файлу даних SAF-T UA;
формування множини файлів: полягає в тому, що один відбір даних призводить до формування множини файлів даних.
При формуванні множини файлів передбачається гнучке число файлів, які сформовані на основі завершеної порції даних, і всі вони разом містять повний набір даних SAF-T UA.
Кожен файл – завершена порція даних – має проходити перевірку (тобто бути валідний) згідно зі схемою XSD незалежно від інших файлів. У додатку 1 до Детального технічного опису елементів SAF-T UA наведено детальний опис та приклади таких XML файлів.
Під час поділу файлу на частини необхідно забезпечити умову формування частин як повноцінного, коректно сформованого XML-документа, що містить завершений блок даних та може бути незалежно провалідований відповідно до заданої схеми XSD. Це вимагає дотримання таких умов:
кожна частина повинна мати структуру автономного, незалежного XML-документа;
кожна частина повинна містити заголовок (Header);
кожна частина повинна містити батьківські елементи (parent elements) для тих елементів, що внесені в цю частину;
елементи не повинні бути розділені між частинами, тобто відкриваючий і закриваючий теги будь-якого елемента повинні знаходитися в межах одного XML-документа;
не допускається розрив моделі елементів, що належить до блоку вибору (choice);
Тобто, кожна частина вірно поділеного файлу є цілісною частиною XML-документа та представляє собою кореневий елемент разом з усіма вкладеними елементами, атрибутами й текстовими даними, які надають даним організований, структурований вигляд.
Цілісність XML-файлу забезпечується суворим збереженням синтаксису та правил XML, що дозволяє його коректно обробляти, аналізувати, передавати між системами.
Чи є обмеження щодо використання спеціальних символів (наприклад, &, @, / тощо) під час заповнення елементів SAF-T UA?
Згідно з Детальним технічним описом елементів SAF-T UA значення показників символьного типу не можуть містити такі заборонені символи:
|
Заборонений символ |
Опис |
Дозволений XML еквівалент |
|
& |
амперсанд |
& |
|
‘ |
апостроф |
' |
|
< |
менше |
< |
|
> |
більше |
> |
|
” |
подвійні лапки |
" |
|
&# |
амперсанд-хеш |
еквівалент відсутній |
|
— |
подвійне тире |
еквівалент відсутній |
|
/* |
слеш-зірочка |
еквівалент відсутній |
Розділ І «Заголовок» (Header)
Чи може суб’єкт господарювання подавати SAF-T UA у вигляді декількох файлів окремо по кожній філії?
Відповідно до Порядку в розділі «Заголовок» необхідно відображати загальні дані про суб’єкта господарювання, який подає SAF-T UA, в тому числі про структурні підрозділи (за їх наявності).
Детальним технічним описом елементів SAF-T UA передбачено, що в розділі «Заголовок» (Header) відображається загальна інформація про файл, включаючи назву програмного забезпечення, що генерує файл; загальні дані про суб’єкта господарювання, який подає SAF-T UA, критерії відбору, за якими формується файл тощо.
У елементі «Інформація про філію» (BranchInfo) відображається інформація про філії (структурні підрозділи), яким делеговано право складання податкових накладних, а в елементі «Відокремлений підрозділ» (TaxEntity) відображається найменування відокремлених підрозділів суб’єкта господарювання.
Таким чином, SAF-T UA повинен включати інформацію про всі структурні підрозділи (за їх наявності) суб’єкта господарювання, але подання SAF-T UA у вигляді декількох файлів окремо по кожній філії не передбачено.
Розділ ІІ «Довідники» (MasterFiles)
Підрозділ ІІ.1 «Облікова політика» (AccountingPolicies)
Які елементи облікової політики суб’єкта господарювання підлягають обов’язковому відображенню в SAF-T UA?
Згідно з Порядком у підрозділі «Облікова політика» зазначається інформація щодо елементів облікової політики суб’єкта господарювання в періоді, за який формується SAF-T UA, з наведенням реквізитів наказу(ів) про облікову політику (дата, номер) за відповідні звітні періоди (та про внесення змін до них – у разі наявності).
Також необхідно зазначити, які саме стандарти бухгалтерського обліку застосовуються суб’єктом господарювання для ведення бухгалтерського обліку – ПСБО/МСБО, та застосування класів рахунків.
Інформація заповнюється в табличному вигляді згідно з наведеним зразком, при цьому відображенню підлягає вся інформація, передбачена у наказі(ах) про облікову політику. У колонку «Елемент» переноситься показник щодо методів амортизації, порядку формування резервів, у тому числі резервів сумнівних боргів, методів оцінки вибуття запасів, визначення порогів суттєвості, проведення інвентаризації, порядку формування інших показників фінансової звітності тощо (відображення яких передбачено нормативно-правовими актами щодо облікової політики підприємства чи Концептуальною основою складання та подання фінансових звітів (для – МСФЗ)).
Отже, обов’язковому відображенню в SAF-T UA підлягає інформація, яка передбачена нормативно-правовими актами щодо облікової політики підприємства чи Концептуальною основою складання та подання фінансових звітів (для – МСФЗ).
Чи дозволяється включати великий обсяг тексту при наведенні описів елементів облікової політики?
Елементи підрозділу «Облікова політика» (AccountingPolicies) мають простий тип «SAFstringType», який базується на простому елементі «xs:string». Тип «xs:string» не має встановленого обмеження на кількість символів, що дозволяє вносити детальні описи елементів облікової політики. При цьому, текст не повинен містити заборонених символів.
Чи передбачена в SAF-T UA можливість додавання копій розпорядчих документів про затвердження облікової політики суб’єкта господарювання?
Формат SAF-T UA не підтримує надання копій розпорядчих документів про затвердження облікової політики суб’єкта господарювання безпосередньо у файлі XML.
Підрозділ ІІ.2 «Довідники операцій» (TransactionFeatures)
Чи може суб’єкт господарювання наводити опис типів господарських операцій згідно з власною класифікацією?
Відповідно до Детального технічного опису елементів SAF-T UA підрозділ «Довідники операцій» (TransactionFeatures) передбачає опис типів господарських операцій, що здійснювалися суб’єктом господарювання, із наведенням відповідних умовних позначень операцій та їх характеристик. При наведенні типу та опису операцій, пов’язаних з придбанням/продажем товарів, робіт/послуг, здійснюється відповідне розмежування зазначених операцій з урахуванням того, яка подія (перерахування коштів (додаткова ознака при умовному позначенні операції – «С») або отримання чи постачання товарів, робіт/послуг (додаткова ознака при умовному позначенні операції – «П»)) відбулася першою (у разі якщо суб’єктом господарювання застосовуються інші ознаки або кодування операцій, які дозволяють здійснити вищенаведене розмежування, можуть бути застосовані такі ознаки або коди операцій).
Довідник «Тип операції» (TransactionType), наведений після закладки «Structures» у додатку до Детального технічного опису елементів SAF-T UA, зазначено у стовпці «Приклад» відповідних елементів підрозділу «Довідники операцій» (TransactionFeatures) та є наочним прикладом заповнення для кращого розуміння природи даних. Налаштування (зіставлення) власних об’єктів з цим довідником є необов’язковим.
При наведенні типу та опису операцій у підрозділі «Довідники операцій» (TransactionFeatures) суб’єкт господарювання може застосовувати власну класифікацію.
Чи може суб’єкт господарювання при наведенні типу та опису операцій, пов’язаних з придбанням/продажем товарів, робіт/послуг, здійснити розмежування зазначених операцій з урахуванням часткових передплат (наприклад, додаткова ознака при умовному позначенні операції – «Ч»)?
При наведенні типу та опису операцій, пов’язаних з придбанням/продажем товарів, робіт/послуг, суб’єкт господарювання може здійснити розмежування зазначених операцій з урахуванням часткових передплат (наприклад, додаткова ознака при умовному позначенні операції – «Ч»):
1Ч – придбання продукції/робіт/послуг (перша подія – часткове перерахування коштів);
2Ч – продаж товарів/робіт/послуг (перша подія – часткове перерахування коштів);
3Ч – придбання основних засобів (перша подія – часткове перерахування коштів).
При цьому, застосування додаткової ознаки «С» при розмежуванні для часткових передплат не суперечить Порядку.
Чи може суб’єкт господарювання при наведенні типу та опису операцій, пов’язаних з придбанням/продажем товарів, робіт/послуг, здійснити розмежування зазначених операцій з урахуванням застосування касового методу податкового обліку (наприклад, додаткова ознака при умовному позначенні операції – «К»)?
При наведенні типу та опису операцій, пов’язаних з придбанням/продажем товарів, робіт/послуг, суб’єкт господарювання може здійснити розмежування зазначених операцій з урахуванням застосування касового методу податкового обліку (наприклад, додаткова ознака при умовному позначенні операції – «К»):
1К – придбання продукції/робіт/послуг (касовий метод);
2К – продаж товарів/робіт/послуг (касовий метод);
3К – придбання основних засобів (касовий метод).
Чи потрібно при наведенні типу та опису операцій, пов’язаних з придбанням товарів, робіт/послуг у неплатників податку на додану вартість, здійснювати розмежування операцій з урахуванням того, яка подія відбулася першою?
При наведенні типу та опису операцій, пов’язаних з придбанням товарів, робіт/послуг у неплатників податку на додану вартість, здійснювати розмежування зазначених операцій з урахуванням того, яка подія відбулася першою, не потрібно.
Підрозділ ІІ.3 «Сальдові/оборотні відомості» (GeneralLedgerAccounts)
Якщо номери субрахунків, які застосовуються суб’єктом господарювання, відсутні в таблиці рахунків, то як у такому випадку виконати їх зіставлення?
Згідно з Детальним технічним описом елементів SAF-T UA в підрозділі «Сальдові/оборотні відомості» (GeneralLedgerAccounts) відображається інформація про застосовувані рахунки/субрахунки/аналітичні рахунки бухгалтерського обліку для ведення господарської діяльності суб’єкта господарювання із зазначенням в розрізі кожного рахунку, субрахунку та аналітичного рахунку їх номерів, найменувань, дат створення облікових записів (рахунків/субрахунків/аналітичних рахунків) та розгорнутого сальдо на початок та кінець періоду, з розбивкою по дебету та кредиту цих рахунків/субрахунків/аналітичних рахунків.
Номери та назви рахунків/субрахунків/аналітичних рахунків відображаються в SAF-T UA відповідно до Плану рахунків суб’єкта господарювання.
При цьому, номери рахунків/субрахунків згідно з Планом рахунків суб’єкта господарювання (крім банків і суб’єктів державного сектору) мають бути зіставлені з номером стандартного рахунку (StandardAccountID), класом рахунку (GroupingCategory) та номером синтетичного рахунку (рахунку першого порядку) (GroupingCode) відповідно до Таблиці рахунків бухгалтерського обліку активів, капіталу, зобов’язань і господарських операцій підприємств і організацій (TableOfAccounts).
Номери субрахунків відповідно до Плану рахунків суб’єкта господарювання можуть відрізнятися від номерів стандартних субрахунків. У такому випадку необхідно зазначити субрахунок, найближчий за призначенням. При зіставленні номерів субрахунків необхідно виходити з їх сутності/призначення. Для субрахунків/рахунків, наведених у довіднику «Таблиця рахунків» (TableOfAccounts), може використовуватись призначення, наведене в Інструкції про застосування Плану рахунків бухгалтерського обліку активів, капіталу, зобов’язань і господарських операцій підприємств і організацій, затвердженій наказом Міністерства фінансів України від 30.11.1999 № 291, зареєстрованим у Міністерстві юстиції України 21.12.1999 за № 893/4186.
Якщо номер субрахунку згідно з Планом рахунків суб’єкта господарювання такий самий, як і номер стандартного субрахунку, зіставлення все одно потрібно виконати.
Чи допускається одночасне відображення початкового та кінцевого сальдо як за дебетом, так і за кредитом, у тому числі з нульовими значеннями?
У характеристиці елемента «Вибір між початковим дебетовим та кредитовим сальдо» (Choice between debit and credit balance; Mandatory; 1..2) зазначено, що розгорнуте сальдо зазначається шляхом використання елемента два рази.
У елементі «Початкове дебетове сальдо» (OpeningDebitBalance; SAFmonetaryType; simple; totalDigits 18, fractionDigits 2; nillable=”true”; Mandatory; 1..1) відображається залишок коштів по дебету рахунку/субрахунку на початок періоду.
У елементі «Початкове кредитове сальдо» (OpeningCreditBalance; SAFmonetaryType; simple; totalDigits 18, fractionDigits 2; nillable=”true”; Mandatory; 1..1) відображається залишок коштів по кредиту рахунку/субрахунку на початок періоду.
У характеристиці елемента «Вибір між кінцевим дебетовим та кредитовим сальдо» (Choice between debit and credit balance; Mandatory; 1..2) зазначено, що розгорнуте сальдо зазначається шляхом використання елемента два рази.
У елементі «Кінцеве дебетове сальдо» (ClosingDebitBalance; SAFmonetaryType; simple; totalDigits 18, fractionDigits 2; nillable=”true”; Mandatory; 1..1) відображається залишок коштів по дебету рахунку/субрахунку на кінець періоду.
У елементі «Кінцеве кредитове сальдо» (ClosingCreditBalance; SAFmonetaryType; simple; totalDigits 18, fractionDigits 2; nillable=”true”; Mandatory; 1..1) відображається залишок коштів по кредиту рахунку/субрахунку на кінець періоду.
Таким чином, схема дозволяє включення або одного з елементів (дебетове сальдо або кредитове сальдо), або обох одночасно (розгорнуте сальдо).
Крім того, атрибут nillable=”true” передбачає технічну можливість представлення нульових значень.
Отже, якщо в сальдових/оборотних відомостях SAF-T UA будуть зазначені обидва елементи вибору, в тому числі з нульовими значеннями, це не вважатиметься помилкою.
Як виконати зіставлення технічних рахунків, які використовуються суб’єктом господарювання для відображення технічних бухгалтерських записів, пов’язаних із проміжним закриттям доходів, витрат, фінансових результатів тощо, з таблицею рахунків?
Для зіставлення технічних рахунків, які використовуються суб’єктом господарювання для відображення технічних бухгалтерських записів, пов’язаних із проміжним закриттям доходів, витрат, фінансових результатів тощо, з довідником «Таблиця рахунків» (TableOfAccounts) слід застосовувати такі значення елементів:
номер стандартного рахунку (StandardAccountID): 999;
код групи рахунку (GroupingCode): 99;
категорія рахунку (GroupingCategory): 9.
Як буде виконуватися правило перевірки збалансованості інформації, систематизованої на рахунках/субрахунках бухгалтерського обліку (формула 3)?
Перевірка збалансованості інформації, систематизованої на рахунках/субрахунках бухгалтерського обліку (формула 3), передбачає, що загальна сума дебетових оборотів повинна дорівнювати загальній сумі кредитових оборотів (крім позабалансових).
Згідно з даними розділу «Бухгалтерські операції» (GeneralLedgerEntries) формуються дані щодо дебетових і кредитових оборотів за кожним рахунком/субрахунком. Відбір і формування (сумування) даних щодо дебетових оборотів для відповідних рахунків/субрахунків здійснюється згідно з кодами рахунків (AccountID), а відбір і формування (сумування) даних щодо кредитових оборотів для відповідних рахунків/субрахунків здійснюється згідно з кодами кореспондуючих рахунків (CorrespodingAccountID) незалежно від того, чи суми зазначені за дебетом або кредитом.
Підсумки за всіма рахунками/субрахунками (крім позабалансових) за дебетом та кредитом повинні бути рівні.
Підрозділ ІІ.4 «Таксономії» (Taxonomies)
Чи може суб’єкт господарювання не відображати інформацію згідно з таксономією?
Детальним технічним описом елементів SAF-T UA передбачено, що в підрозділі «Таксономії» (Taxonomies) відображається інформація згідно з таксономією, яка застосовується до рахунку/субрахунку Плану рахунків суб’єкта господарювання (може заповнюватись за бажанням платника податків).
Якщо суб’єкт господарювання вирішує не заповнювати інформацію згідно з таксономією, то весь цей підрозділ не слід включати в XML-документ SAF-T UA.
Використання порожніх елементів можна інтерпретувати так, ніби вони мають значення, тому порожні елементи не слід використовувати взагалі, якщо немає даних для заповнення необов’язкового елемента.
Наявність атрибута «minOccurs=”0″» у визначенні елемента «Таксономії» (Taxonomies) дозволяє опустити (не включати) цей елемент у XML-документ SAF-T UA. При його відсутності XML-документ буде відповідати XSD-схемі і вважатиметься валідним. У разі включення цього підрозділу в XML його структура та обов’язкові дочірні елементи повинні відповідати вимогам XSD-схеми.
Чи буде достатнім відображення в таксономії лише посилань на [210000] Звіт про фінансовий стан, поточні/непоточні та [310000] Звіт про сукупний дохід, прибуток або збиток, за функцією витрат?
Якщо суб’єкт господарювання вирішує відображати в SAF-T UA інформацію згідно з таксономією, яка застосовується до рахунку/субрахунку Плану рахунків суб’єкта господарювання, то він самостійно вирішує, які відомості включати в підрозділ «Таксономії» (Taxonomies).
Підрозділ ІІ.5 «Клієнти» (Customers)
Якщо в періоді, за який формується SAF-T UA, фізична особа – покупець мала різний податковий та правовий статус у зв’язку з реєстрацією підприємцем, чи дозволяється відображати інформацію щодо такого контрагента окремими записами із зазначенням унікальних ідентифікаторів, визначених суб’єктом господарювання?
Детальним технічним описом елементів SAF-T UA передбачено, що в підрозділі «Клієнти» (Customers) відображається інформація щодо контрагентів (покупців), з якими суб’єкт господарювання мав господарські відносини, із зазначенням ідентифікаційних даних (податковий номер/код нерезидента, найменування, номер платника податку на додану вартість), номера рахунку/субрахунку/аналітичного рахунку бухгалтерського обліку, що застосовується суб’єктом господарювання для цього контрагента, сальдо заборгованості на початок та на кінець періоду та розкриттям іншої інформації.
У елементах «Ідентифікатор покупця» (CustomerID) та «Код контрагента» (RegistrationNumber) зазначається унікальний ідентифікаційний номер юридичної особи в Єдиному державному реєстрі підприємств та організацій України/ Реєстраційний номер облікової картки платника податків фізичної особи/ код нерезидента (якщо здійснюється роздрібний продаж без ідентифікації покупця – зазначається умовний код таких операцій, що застосовується).
Для ідентифікаторів покупців (CustomerID) застосовуються обмеження на ключ (key) і посилання на ключ (keyref). Обмеження на ключ (key) і посилання на ключ (keyref) за технічним визначенням призначені для забезпечення унікальності значень ключа та є основою для перевірки того, що всі значення, на які є посилання, присутні у відповідному значенні ключа.
Отже, інформація щодо контрагента (покупця), з яким суб’єкт господарювання мав господарські відносини, повинна бути відображена одним записом.
Який код та найменування контрагента необхідно зазначати при здійснені роздрібного продажу без ідентифікації покупця?
Якщо здійснюється роздрібний продаж без ідентифікації покупця, в елементах «Ідентифікатор покупця» (CustomerID) та «Код контрагента» (RegistrationNumber) проставляється умовний код «100000000000», а в елементі «Найменування контрагента» (Name) зазначається «Неплатник».
Який ідентифікатор покупця необхідно зазначати для фізичних осіб, які через свої релігійні переконання відмовляються від прийняття реєстраційного номера облікової картки платника податків?
Для фізичних осіб – покупців, які через свої релігійні переконання відмовляються від прийняття реєстраційного номера облікової картки платника податків та повідомили про це відповідний контролюючий орган і мають відмітку в паспорті, може зазначатись серія (за наявності) та номер паспорта.
Як заповнювати місцезнаходження (адресу) клієнта, якщо в системі обліку суб’єктів господарювання відсутня повна інформація згідно зі структурою адреси?
У елементі «Місцезнаходження» (Address; AddressStructure; complex; Optional; 0..∞) зазначається місцезнаходження (адреса) контрагента (рекомендується обов’язкове заповнення).
Інформація про країну є особливо важливою, оскільки вона має ключове значення для визначення країни реєстрації контрагента.
Чи можуть при зазначенні типу особи покупця використовуватись дані Єдиного державного реєстру інститутів спільного інвестування, Реєстру неприбуткових установ та організацій, Реєстру платників єдиного податку тощо?
У елементі «Тип особи покупця» (CustomerType; SAFmiddle1textType; simple; maxLength 35; Optional; 0..∞) зазначається тип особи покупця (рекомендується обов’язкове заповнення для контрагентів, господарські операції з якими можуть формувати податкові різниці).
При визначенні типу особи покупця системи обліку суб’єктів господарювання можуть використовувати дані публічних реєстрів, таких як:
Єдиний державний реєстр інститутів спільного інвестування;
Реєстр неприбуткових установ та організацій;
Реєстр платників єдиного податку.
Чи потрібно заповнювати код ознаки пов’язаності для контрагентів – резидентів?
У елементі «Код ознаки пов’язаності» (RelatedPartyCode; SAFcodeType; simple; maxLength 9; Optional; 0..∞) зазначається код ознаки пов’язаності (рекомендується обов’язкове заповнення для пов’язаних осіб, як резидентів, так і нерезидентів).
Чи потрібно в клієнтах відображати інформацію щодо філій?
Інформація щодо філій може зазначатися в підрозділі «Клієнти» (Customers) для відображення в бухгалтерських операціях щодо внутрішньогосподарських розрахунків з виробничими одиницями і господарствами, виділеними на окремий баланс.
Чи потрібно в клієнтах зазначати контрагентів, з якими були обороти, але відсутня заборгованість на початок/кінець періоду?
Відповідно до таблиці 5 «Обмеження відображення даних в довідниках» Детального технічного опису елементів SAF-T UA дані в підрозділі «Клієнти» (Customers) можуть бути обмежені покупцями, з якими здійснювались операції в періоді, за який формується SAF-T UA, та/або для яких наявна заборгованість на початок/кінець періоду (залишок на початок або кінець не дорівнює 0).
Якщо в обліковій системі суб’єкта господарювання назви покупців перевищують максимально допустиму кількість символів для введення, чи допускається скорочення найменувань шляхом обрізання тексту до 70 символів?
Згідно з Детальним технічним описом елементів SAF-T UA обмеження (Facets) задають максимально допустиму кількість символів для введення.
Для елементів, які містять найменування контрагентів, передбачено обмеження в 70 символів (maxLength 70), що відповідає моделі ОЕСР.
Якщо найменування контрагентів містить більшу кількість символів, то доцільно застосовувати скорочену назву, яка міститься в Єдиному державному реєстрі юридичних осіб, фізичних осіб – підприємців та громадських формувань. Якщо ж таке скорочене найменування відсутнє, то доцільно застосувати скорочене найменування, яке зберігає суть назви.
Скорочення найменувань шляхом обрізання тексту до 70 символів також є допустимим.
Чи потрібно інформацію про сальдо розрахунків з покупцем відображати з урахуванням курсових різниць?
У елементі «Дані первинних документів, за якими наявна заборгованість» (OpenInvoices; complex; Optional; 0..∞) відображаються дані аналітичного обліку в розрізі кожного документа в гривнях та валюті, обумовленій договором, із зазначенням дат виникнення заборгованості.
Підпунктом «а» пар. 23 МСБО 21 «Вплив змін валютних курсів» визначено, що на кінець кожного звітного періоду монетарні статті в іноземній валюті слід переводити, застосовуючи курс при закритті.
Отже, інформація в розрізі первинних документів, за якими наявна заборгованість в іноземній валюті, повинна містити дані початкового/кінцевого дебетового/кредитового сальдо в іноземній валюті та в гривнях з урахуванням курсових різниць (для монетарних статей).
Початковий/кінцевий баланс за номером рахунку/субрахунку бухгалтерського обліку, що застосовується суб’єктом господарювання для відповідного контрагента, повинен відповідати початковому/кінцевому сумарному балансу первинних документів, за якими наявна заборгованість (з урахуванням курсових різниць).
Якщо суб’єкт господарювання на підставі прийнятої облікової політики відображає переведення монетарних статей в іноземній валюті на окремому субрахунку, то така інформація може формувати окремий запис сальдо розрахунків з клієнтом, оскільки відображення інформації повинно здійснюватися в розрізі рахунків/субрахунків бухгалтерського обліку, що застосовується суб’єктом господарювання для цього контрагента.
Якщо суб’єкт господарювання на підставі прийнятої облікової політики веде облік сальдо розрахунків з клієнтами в розрізі договорів, а не в розрізі кожного окремого первинного документа, то як у такому випадку відображати суму заборгованості та дату її виникнення?
Елемент «Джерело» (OrderReferences; complex; Optional; 0..1) передбачає відображення посилання на договір/рахунок тощо (рекомендується обов’язкове заповнення) та включає такі елементи:
«Номер замовлення» (OriginatingON; SAFmiddle2textType; simple; maxLength 70; Optional; 0..1): номер договору/рахунку тощо;
«Дата замовлення» (OrderDate; SAFdateType; simple; Optional; 0..1): дата договору/рахунку тощо.
Якщо суб’єкт господарювання на підставі прийнятої облікової політики веде облік сальдо розрахунків з клієнтами в розрізі договорів, а не в розрізі кожного окремого первинного документа, то дані аналітичного обліку доцільно відображати в розрізі кожного договору в гривнях та валюті, обумовленій договором, із зазначенням дат виникнення заборгованості.
Дата виникнення заборгованості може бути визначена на основі дати договору або першого первинного документа, пов’язаного з ним.