Податкова звітність подана, але не прийнята, як автоматизувати контроль квитанцій ДПС

Факт відправки звіту через оператора електронного документообігу не означає, що податкова служба його прийняла. Після подання декларація чи звіт проходить два етапи технічного контролю — квитанцію №1 (підтвердження отримання) та квитанцію №2 (результат приймання або відмову з переліком помилок). Саме другий документ визначає юридичний статус звітності.

Проблема в тому, що квитанція №2 генерується не миттєво — процес може тривати від кількох хвилин до доби, залежно від навантаження на сервери ДПС. Бухгалтер, який орієнтується лише на факт відправлення, ризикує пропустити відмову в прийнятті. Типові причини відмови: невідповідність контрольних співвідношень, помилка в ЕЦП підписанта, розбіжність реєстраційних даних платника з реєстром ДПС, дублювання звіту, неправильно вказаний звітний період.

Наслідок пропущеної відмови — звіт вважається неподаним, і якщо це виявляється вже після граничного терміну, підприємству загрожує штраф за статтею 120 ПКУ та адміністративна відповідальність посадової особи.

Cценарій без автоматизації

Розглянемо типову ситуацію. Бухгалтер середнього підприємства подає щомісяця 15–20 звітів: ПДВ, ЄСВ, ПДФО, акцизні документи, статистичну звітність. Стандартний процес виглядає так:

Звіт формується в бухгалтерській програмі, експортується у форматі XML, підписується КЕП і відправляється через кабінет платника або окремого оператора ЕДО. Далі бухгалтер має вручну зайти в кабінет, знайти потрібний документ у списку, перевірити статус, і за потреби завантажити квитанцію №2 для архіву. При 15–20 звітах на місяць і кількох ключах підпису (директор, головний бухгалтер) ця операція займає години, а головне — залежить від людської пам'яті: хтось має не забути перевірити статус саме тоді, коли квитанція вже згенерована.

На практиці це призводить до типової помилки: перевірка відбувається один раз, одразу після відправки, коли квитанція №2 ще не сформована. Статус фіксується як "прийнято до обробки", і на цьому контроль завершується.

Що потрібно автоматизувати

Ефективний контроль будується на 3 елементах:

Автоматичний моніторинг статусу. Система з визначеною періодичністю (наприклад, кожні 30 хвилин) звертається до кабінету платника або API оператора ЕДО й перевіряє статус кожного відправленого документа, без участі бухгалтера.
Сповіщення про відхилення. Якщо квитанція №2 містить відмову, система негайно формує повідомлення відповідальній особі із зазначенням коду та тексту помилки, а не чекає на планову перевірку.
Централізований реєстр квитанцій. Усі квитанції №1 і №2 зберігаються в одному місці з прив'язкою до конкретного звіту, періоду та дати подання — це знімає питання при податкових перевірках, коли потрібно підтвердити факт і дату прийняття звітності.

Технічна реалізація

Більшість операторів ЕДО (M.E.Doc, Вчасно та інші) надають API або протокол SOAP/REST для інтеграції зі сторонніми системами.

Модуль відправки формує та передає звіт через API оператора, зберігаючи ідентифікатор документа. Планувальник задач (cron-подібний механізм) з визначеним інтервалом опитує статус документа за цим ідентифікатором. При отриманні квитанції №2 система парсить XML-відповідь, визначає код результату та, у разі відмови, витягує текст помилки з структурованого поля. Модуль сповіщень надсилає повідомлення в месенджер, на пошту або в корпоративну систему тикетів.

Для підприємств, які використовують M.E.Doc, аналогічний функціонал частково реалізований у вбудованому модулі контролю статусів, але він вимагає ручного відкриття програми для перегляду. Для повної автоматизації потрібна або доробка через API, або готове стороннє рішення.

Готові програмні рішення

Якщо розробка власної інтеграції нерентабельна, варто розглянути такі напрями:

• Модулі контролю статусів у складі ERP-систем (BAS ERP, BAS КУП та інші) — інтегровані рішення, які автоматично оновлюють статус документообігу в самій обліковій системі та формують звіт по незакритих квитанціях.
• Спеціалізовані сервіси моніторингу ЕДО — незалежні платформи, що підключаються до кількох операторів одночасно та консолідують статуси в єдиній панелі, зручні для підприємств з кількома юридичними особами або філіями.
• Власна інтеграція через API оператора — виправдана при великому обсязі документообігу (від 50 звітів на місяць) або специфічних вимогах до звітності перед керівництвом.
• Розширення на базі RPA (Robotic Process Automation) — імітують дії користувача в кабінеті платника без офіційного API, застосовні там, де оператор не надає програмного доступу, але менш надійні при змінах інтерфейсу.

Вибір залежить від обсягу звітності, кількості юросіб та наявності IT-ресурсу для підтримки інтеграції. Для малого й середнього бізнесу зазвичай достатньо модуля в межах наявної облікової системи; для холдингових структур виправдана окрема платформа моніторингу.