Системи контролю обігу готівки. Світовий досвід. Порівняння з системою в Україні

     Системи контролю обігу готівки. Світовий досвід. Порівняння з системою в Україні.

     Питання: Чи існує у світі ще така система контролю обігу готівкових коштів як ПРРО в Україні?

     Відповідь: Так, абсолютно. Україна тут далеко не одна — більше того, перехід на програмні каси та хмарну фіскалізацію (Cloud Fiscalization) — це глобальний світовий тренд останніх 5–10 років.

     Різні держави називають цю систему по-різному (віртуальні каси, онлайн-фіскалізація, CTC — Continuous Transaction Control), але технічна суть скрізь однакова: відмова від дорогого фізичного «заліза» (мікросхем пам'яті, пломб) на користь програмного забезпечення та миттєвої передачі даних на сервер податкової по API.

     Світовий досвід впровадження аналогів ПРРО можна розділити на кілька основних моделей.

     1. Чиста хмарна фіскалізація (Повні аналоги ПРРО)

     У цих країнах, як і в Україні, бізнесу взагалі не потрібно купувати касовий апарат. Досить встановити додаток на смартфон, планшет чи комп'ютер.

• · Албанія (Система «Fiscalization»): Впроваджена у 2020–2021 роках. Мабуть, один із найближчих аналогів українського ПРРО. Жодного спеціального «заліза». Програма підписує чек цифровим сертифікатом безпеки та надсилає на центральну платформу податкової в реальному часі. Точно так само генерується унікальний QR-код для покупця.
• · Молдова (Проєкт «Електронний моніторинг продажів»): зараз там активно розвивається платформа FiscalCloud. Принцип один в один: додаток для Android/iOS/Windows, який повністю замінює фізичний касовий апарат і надсилає чеки в хмару державної податкової служби.
• · Казахстан (ОФД та програмні каси): Там уже давно класичні апарати витіснені так званими «Web-касами» (програмними РРО). Дані йдуть не напряму в податкову, а через приватних сертифікованих операторів фіскальних даних (ОФД), які акумулюють та валідують масив інформації.

     2. Європейська модель: API та «Хмарна Хмара» (Німеччина, Австрія, Іспанія)

     У ЄС підхід ще більш технологічний. Там фіскалізацію часто вбудовують як API-сервіс прямо всередину облікових систем (ERP, CRM або POS-систем магазинів).

• · Німеччина (Закон KassenSichV): З 2020 року всі каси повинні мати модуль безпеки — TSE (Technische Sicherheitseinrichtung). Але німці дозволили робити цей модуль суто хмарним (Cloud-TSE). Великі провайдери (наприклад, fiskaly) надають API: каса магазину відправляє дані на хмарний сервер провайдера, там чек криптографічно підписується і реєструється.
• · Іспанія (Проєкти TicketBAI та Verifactu): в різних регіонах Іспанії впроваджуються вимоги, за якими будь-який продаж генерує зашифрований ланцюжок даних (аналог блокчейна), який автоматично «відлітає» в податкову через сертифікований софт.

     3. Модель Латинської Америки (Піонери цифрового контролю)

     Країни Латинської Америки (Чилі, Бразилія, Мексика, Аргентина) почали переходити на цифровий контроль ще у 2000-х роках, задовго до Європи, через величезний рівень тіньової економіки.

• · Там діє система електронного інвойсингу (E-invoicing) для B2C та B2B секторів. Кожен чек — це електронний XML-документ, який перед видачею покупцеві в магазині має пройти «авторизацію» (валідацію та підпис) на державному сервері. Фізичні касові апарати там фактично вимерли як клас, поступившись місцем смарт-терміналам та хмарним рішенням.

     В чому різниця між ПРРО в Украине та закордонними системами?

     Незважаючи на схожість, у Українського ПРРО є своя унікальна специфіка, яка відрізняє його від багатьох світових систем:

     1. Безкоштовний державний софт: Державна податкова служба України створила та підтримує безкоштовний додаток ПРРО («ПРРО ДПС»). У багатьох країнах (тій же Німеччині чи Казахстані) держава лише виставляє технічні вимоги (протокол API), а за сам софт чи послуги хмарного провайдера бізнес зобов'язаний платити приватним компаніям.

     2. Екстремальний офлайн-режим: В Україні ПРРО може працювати без інтернету до 36 годин поспіль, підписуючи чеки локально за рахунок заздалегідь виданого сервером пулу номерів. В більшості країн світу офлайн влаштований інакше: каса просто копіює чеки в локальний буфер (шифрований журнал), а при появі мережі «передає» їх на сервер (як в Австрії). Резервування номерів наперед — це специфічний українське винахід, покликаний обійти проблему частих блекаутів та перебоїв зі зв'язком. Саме офлайн режим в українському варіанті й призводить до системних маніпуляцій податкових даних.

     Резюме

     Україна із системою ПРРО перебуває на передовій цифровізації податкового контролю. Весь світ рухається в бік софту, криптографічних підписів (КЕП) та централізованих баз даних, поступово відмовляючись від локальних пристроїв із пломбами.

     Але, повертаючись до нашої минулої розмови, цей тренд автоматично масштабує і головну проблему: тепер податкова безпека бізнесу в усьому світі залежить не від надійності замка на касовому апараті, а від чесності алгоритмів та адміністраторів центрального державного сервера, а світова практика показує, що все у світі продається і купується, навіть чесність державних службовців. Тож відхід від спеціалізованого приладу обліку у вигляді класичного РРО в Україні є передчасним і не продуманим. Економічний аналіз за даними ДПС показує, що класичні РРО з розрахунку на один РРО/ПРРО збирають податку в 6-10 разів більше, ніж ПРРО.

     У зазначених країнах наявні вимоги до софту у вигляді технічних вимог з боку держави. Держава завжди висуває колосальний обсяг технічних, криптографіческіх та функціональних вимог до програмного забезпечення. Різниця між країнами полягає лише в тому, як саме перевіряється відповідність цьому регламенту. В світовій практиці існує два основні підходи до контролю софту (ПРРО): жорстка сертифікація (закритий ринок) та декларування відповідності за відкритим API (модель, близька до України).

     1. Підхід №1: Жорстка державна сертифікація (Німеччина, Іспанія)

     У цих країнах розробник ПЗ не може просто написати код за інструкцією та викотити його на ринок. Софт має пройти складну, дорогу та тривалу процедуру державної перевірки.

     Німеччина (BSI та KassenSichV)

     Німецьке Федеральне відомство з безпеки у сфері інформаційних технологій (BSI) розробило найсуворіший стандарт для хмарних та апаратних модулів безпеки (TSE).

• · Що вимагають від софту: Програма зобов'язана використовувати суворо визначені алгоритми шифрування (наприклад, ECDSA). Кожен чек повинен містити унікальний цифровий підпис модуля TSE, серійний номер цього модуля та точний таймштамп.
• · Як перевіряють: Приватні компанії-розробники (такі як fiskaly або Epson) здають свої хмарні рішення на аудит у BSI. Сертифікація триває місяцями і коштує десятки тисяч євро. Звичайний програміст не може створити своє ПРРО «з нуля» для ринку — він зобов'язаний інтегрувати у свою POS-систему вже сертифіковане державою хмарне рішення (Cloud-TSE) через готове API.

     Іспанія (Регіон Басків, система TicketBAI)

     Тут вимоги до софту доведені до автоматизму на рівні коду.

• · Що вимагають від софту: Програма повинна генерувати XML-файл суворо заданої структури. Кожен наступний чек має містити частину хешу попереднього чека (ланцюжок, схожий на блокчейн). На самому чеку софт зобов'язаний згенерувати QR-код суворо визначених розмірів (від 30х30 мм до 40х40 мм) з кодуванням UTF-8 та високим контрастом для зчитування.
• · Як перевіряють: Розробник софту реєструється у спеціальному державному реєстрі (Zuzendu) та підписує юридичну декларацію про те, що його код повністю відповідає вимогам TicketBAI і не містить прихованих функцій видалення даних. Софту присвоюється унікальний ідентифікатор, який «вшивається» в кожен чек, що надсилається.

     2. Підхід №2: Відкритий протокол API та відповідальність бізнесу (Україна, Казахстан)

     Ця модель ліберальніша для розробників, но накладає жорсткі обмеження на формат даних.

• · Як це влаштовано: Держава не сертифікує саму программу (не перевіряє кожен рядок її коду). Замість цього Податкова служба публікує відкритий протокол обміну даними (API) та технічний опис форматів (наприклад, XML або JSON-структуру чека).
• · Вимоги до софту:
• 1. Криптографія: Софт зобов'язаний вміти працювати з державними шлюзами шифрування та накладати КЕП (електронний підпис) за стандартами конкретної країни (в Україні це ДСТУ 4145, алгоритми ECDSA тощо).
• 2. Логика офлайну: Програма повинна чітко відпрацьовувати ліміти часу, блокувати продажі при перевищенні офлайн-годин та коректно синхронізувати пакети даних після відновлення зв'язку.
• 3. Валідація полів: Чек не буде прийнятий сервером, якщо в структурі даних відсутній хоча б один обов'язковий реквізит (форма податку, код УКТЗЕД/ТНЗЕД, фіскальний номер).

     При такому підході, якщо розробник напише софт некоректно, сервер податкової просто «виплюне» такий чек і видасть помилку авторизації або структури. Відповідальність за надсилання некоректних даних повністю лягає на підприємця, який обрав цей софт.

     Типові вимоги держави до фіскального софту (Світовий стандарт)

     Незалежно від країни, технічне завдання від держави до будь-якого ПРРО завжди включає три обов'язкові блоки:

     Тому «просто написати додаток для продажів» і назвати його програмною касою неможливо. Розробник ПРРО завжди затиснутий у жорсткі лещата державних специфікацій, інтерфейсів API та криптографічних стандартів, крок ліворуч від яких означає, що система просто не зможе зв'язатися з сервером податкової.

     Питання. Яка відповідальність розробників у цих країнах, якщо софт дозволяє маніпулювати податковими даними?

     Відповідь. Якщо в софті виявляється навмисна «закладка», бекдор или алгоритм, що дозволяє приховувати, змінювати або видаляти чеки в обхід податкової, відповідальність несе і сам бізнес (користувач), і розробник програмного забезпечення.

     Однак глибина покарання для розробника софту кардинально відрізняється залежно від законодавчої моделі конкретної країни. Світова практика ділить цю відповідальність на три рівні: від величезних цільових штрафів до кримінальних термінів за співучасть у шахрайстві.

     1. Модель жорсткої сертифікації (Німеччина, Іспанія)

     У країнах, де софт проходить перевірку регуляторів, відповідальність для ІТ-компаній прописана в профільних законах і є руйнівною для бізнесу.

     Іспанія (зокрема, регіон Басків, система TicketBAI)

     Тут законодавці чітко розділили: одна справа, якщо підприємець просто не видав чек, і зовсім інша — якщо софт був навмисно модифікований для приховування доходів.

• · Для розробника софту: Якщо податкова доведе, що ІТ-компанія поставила, розробила або допомогла впровадити програмне забезпечення, здатне змінювати або видаляти фіскальні дані, на неї накладається фіксований штраф у розмірі €40 000 за кожен факт порушення. При повторному порушенні з боку ІТ-компанії штраф зростає до €60 000.
• · В масштабах всієї Іспанії (система Verifactu) штраф для постачальників некоректного ПЗ може сягати до €150 000 за кожного клієнта, який використовував їхній неліцензійний або маніпулятивний продукт.

     Німеччина (Закон KassenSichV / Положення AO)

     Німецьке податкове законодавство (§ 379 AO) розглядає створення програм для ухилення від податків як грубе адміністративне праворушення.

• · Продаж або сприяння в розповсюдженні софту, який дозволяє обходити вбудовані модулі безпеки (TSE), карається штрафами до €25 000 в адміністративному порядку.
• · Якщо доведено умисел та масштабні збитки державі, справа миттєво перекваліфікується на кримінальну (податкове шахрайство). У такому разі розробники йдуть під суд как співучасники або організатори злочинної схеми за змовою.
• · В Україні, відповідно до Закону відсутня відповідальність розробника за корявий софт, всю відповідальність несе підприємець.

     2. Подхід №2: Відкритий протокол API та відповідальність бізнесу (Україна, Казахстан)

     У країнах з відкритим API (де держава не сертифікує кожен рядок коду, а лише дає протокол) притягнути розробника софту виключно за податковими статтями складніше, але механізми є.

     Україна (Закон про РРО та Кримінальний кодекс)

     Прямого штрафу в законі про РРО саме «для програмістів» за поганий код ПРРО немає — вся первинна фінансова відповідальність (100–150% від суми прихованих операцій) лягає на підприємця. Однак для розробника настає відповідальність за іншими кодексами:

     1. Внесення змін до ПЗ (Адмінштраф): Використання РРО/ПРРО, у програмне обеспечение якого внесено зміни, не передбачені документацією, тягне за собою штраф (нехай і невеликий — 300 НМДГ / 5100 грн). Але це лише верхівка айсберга.

     2. Кримінальна відповідальність (ст. 212 КК України): якщо велика мережа магазинів використовувала кастомне ПРРО для приховування мільярдних оборотів, слідчі кваліфікують дії ІТ-директора або зовнішньої ІТ-компанії за статтею «Сприяння в ухиленні від сплати податків». Розробник у цьому випадку визнається співучасником, який створив знаряддя злочину. Санкція статті передбачає конфіскацію майна та заборону займатися діяльністю.

     3. Кіберзлочини (ст. 361 КК України): Написання софту, який навмисно спотворює або знищує дані в автоматизованих системах (а ПРРО — це частина такої системи), підпадає під розділ комп'ютерних злочинів. За створення та розповсюдження шкідливого ПЗ, що змінює фіскальні масиви, розробнику загрожує реальний тюремний термін. Але справа в тому, що в Україні немає реєстру розробників ПРРО, і знайти розробника софту ПРРО неможливо, тим більше притягнути його до кримінальної відповідальності.

     Резюме

     У сучасних системах хмарної фіскалізації розробник софту більше не є «просто стороннім спостерігачем». Держава розуміє, що один недобросовісний програміст може допомогти уникнути податків тисячам бізнесів одночасно. Саме тому в ЄС штрафи для ІТ-компаний за створення «сірих» касових алгоритмів обчислюються десятками й сотнями тисяч євро за кожен інцидент, а у східноєвропейській практиці та Україні це прямий шлях до кримінального переслідування за співучасть у фінансових злочинах.