Електронний кабінет платника податків – що планувалось і як сталось…
Олександр Шемяткін
Партнер КМ Партнери
Зацікавленість влади у вдосконалені роботи електронного кабінету платника податків (далі – ЕК) викликає надію, що цей проєкт отримає людське обличчя.
Але для цього слід згадати, як ЕК замислювався та що пішло не так. Тому, користуючись нагодою, як ідеолог та автор відповідних положень Податкового кодексу, прокоментую ситуацію.
Задумка ЕК полягала в тому, щоб перевести майже всі взаємовідносини платника податку з податковою у цифру, як це було на початку 2000-х років зроблено в Естонії. Естонія почала свій e-governance саме з податкової сфери.
Мета положень Податкового кодексу щодо ЕК – зробити законодавчі умови для створення не просто інструменту взаємодії, а й сервісу для платників податку. Наприклад, платник недоплатив податки, а в ЕК йому приходить повідомлення – доплатити, умовно, 20 грн до 30 числа, щоб уникнути штрафу та пені. Тому законопроєкт про ЕК на початковому етапі передбачав одночасне створення єдиного рахунку для сплати податків (для 2014 року це було занадто, як сказала Тетяна Острікова, – «ти хочеш все і одразу», тому ці положення викинули з законопроєкту).
Під час підготовки законопроєкту була дискусія, чи має ЕК бути обов’язковим для всіх, чи використовуватись за бажанням? Вирішили, що податкова має «зачарувати» користувачів сервісом, щоб платники самі бажали використовувати ЕК. Чому так і чого боялись?
- По-перше, насамперед, була недовіра до інформації в електронних базах податкової.
- По-друге, податкова працювала на застарілій техніці, а на місцях (на той час) це була навіть не техніка податкової (сумлінні платники допомагали комп’ютерами), тому ЕК міг працювати з перебоями.
- По-третє, були питання до кваліфікації технічного персоналу ДФС щодо можливості створити сервіс для платників, на кшталт програмного забезпечення «Приват24». Цей ризик посилювався «тісним» зв’язком ДФС із «Медок» – повноцінна реалізація ЕК призводила до створення конкурента.
Із часом з’ясувалось, що зазначені побоювання не виявились марними.
Щоб вирішити ці проблеми, законопроєкт передбачав, що:
– Електроні бази знаходяться не в ДФС, а в Мінфіні чи у створеному з цією метою підприємстві. Податкова мала бути виключно користувачем ЕК та наповнювачем інформації.
Цього не сталося і бази залишились в ДФС.
– Перед передачею баз даних із ДФС мав бути проведений аудит баз даних та оприлюднений результат.
Цього не сталося (щось було, але зовсім не те, що очікувалось).
– Методологом ЕК мав бути Мінфін, але перед голосуванням правкою з голосу це змінили і Методологом зробили ДФС. Чому це було важливо? Податкова не мала втручатися в алгоритми роботи системи, як це відбувається зараз із реєстрацією податкових накладних. Крім того, усувався конфлікт інтересів, якщо щось не так. Платник мав звертатися з проблемами не до податкової, а до третьої особи, яка б їх фіксувала і вирішувала, а платник за помилки в ЕК чи за непрацюючий сервіс не ніс би відповідальності. В цій частині законопроєкт змінили і все замкнули на ДФС. Залишились лише норми про звільнення від відповідальності за непрацюючий сервіс, але ходять чутки, що і це з Податкового кодексу планують прибрати.
Детальніше про те, що так і не запрацювало в ЕК, читайте в нашому матеріалі за посиланням.
Крім перелічених у матеріалі проблем є ще проблема встановлення рівнів доступу для працівників однієї компанії, щоб обмежити доступ до конфіденційної інформації (наприклад, працівник, який реєструє податкову накладну через ЕК, не повинен мати доступ до інформації щодо зарплат).
Що треба зробити, щоб ЕК став сервісом, як він замислювався:
- провести аудит баз даних та виявити алгоритми їх роботи (наразі це найбільш засекречена інформація в країні);
- передати бази даних до Мінфіну чи спеціалізованого підприємства;
- надати Мінфіну статус Методолога ЕК;
- переробити повністю цей совковий інтерфейс ЕК та логіку його роботи (про один клік там ніхто не чув);
- повністю змінити команду, яка супроводжує розробку ЕК (це не мають бути люди із системи, бо сервіс для них – це вчасно згенерований системою штраф платнику податків);
- усунути якнайдалі від цього процесу вплив зовнішніх потенційних конкурентів ЕК;
- забезпечити безперебійну систему роботи ЕК відповідним технічним забезпеченням (сервера);
- забезпечити можливість обміну в ЕК електронними примірниками документів та сканованими копіями документів (із паперових примірників);
- врешті-решт, виконати вимоги Податкового кодексу щодо всього функціоналу ЕК.
Окремою темою, але пов’язаною з розробкою ЕК, є система блокування податкових накладних. До блокування податкових накладних податкова використовувала систему розірвання договорів про визнання електронного цифрового підпису. Оскільки цей незрозумілий механізм перешкоджав використанню ЕК, то було вирішено замінити цю систему на блокування, щоб дати податковій механізм протидії схемному податковому кредиту.
Але початково законопроєкт передбачав, що блокування буде здійснюватися податковою у судовому порядку за спрощеною процедурою (як це відбувається з податковим арештом).
На жаль, податкова переконала Мінфін, що вони «замахаються» ходити по судах, а тому право блокування надали податковій. Сталося, як і очікувалось: наразі «замахалися» платники податків у зв’язку з необґрунтованим блокуванням, а податкова отримала гарний корупційний інструмент. Сьогодні цей механізм має катастрофічні наслідки для малого та середнього бізнесу, бо відбувається значне вимивання обігових коштів у країні, де банківський кредит коштує від 22 %!
Тому, якщо є бажання створювати довіру до податкових сервісів, то (до більш системного вирішення проблеми з ПДВ) треба змінити механізм блокування, передбачивши процедуру судового блокування.
PS: Сподіваюсь побачити протягом року Електронний кабінет платника податків як сервіс із людським обличчям і забути про цей архаїзм.
МАТЕРІАЛИ ПО ТЕМІ
З 18 жовтня 2023 року реєстрація всіх юридичних осіб в «Електронному суді» стає обов’язковою: що це означає і які ризики несе?
Відтепер на рівні закону – визнання іноземних КЕП в Україні та інші зміни навколо КЕП
Іноземні електронні підписи визнаються в Україні
Документ без номера й без дати: новий ДСТУ 4163:2020
Огляд ПДВ-змін у законопроекті 4184, або не Google єдиним
Доказова сила імейлів: позиції Касаційного господарського суду
Електронний документообіг та момент виникнення податкових зобов’язань – і не тільки…
Проект закону № 2260: що зміниться у сфері електронного документообігу у разі його підписання Президентом України
Довірили свій електронний підпис іншій особі: які ризики?
Онлайн-договір Шредінгера – він є чи його немає?
Податок на виведений капітал