Штучний інтелект проти податкової служби та бухгалтерів

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

Незважаючи на те що я вже понад рік працюю над окремим комерційним продуктом у вигляді чат-бота-консультанта з податкового та бухгалтерського обліку, я не відчував особливого бажання заглиблюватися в цю сферу. У мене є кілька компаній під моїм опікунством, де відбувається буквально кілька операцій на місяць; цим, за інерцією, як і багато років поспіль, займалася бухгалтерка за невелику частину ставки, і поки все працювало, я нічого не чіпав. Поки бухгалтерка не сказала, що більше не хоче. Ідея шукати нового бухгалтера здавалася природною, але економічно невиправданою – грошей там мало, витрачати їх усі на те, щоб нова людина почала розбиратися й виконувала якось рутинні операції (причому спочатку вона прийде з розповіддю про те, як усе запущено, ви ж розумієте).

Загалом, неважко здогадатися, що я вирішив доручити це завдання штучному інтелекту й подивитися, що з цього вийде. Для тренувань у мене був власний ФОП (фізична особа-підприємець), причому з історією за кілька років (виписки, рахунки), а серед підопічних компаній – ТОВ на єдиному податку та акціонерне товариство на загальній системі обліку, платник ПДВ. Ну так, такий джекпот – звітність акціонерного товариства містить не тільки стандартні податкові звіти, а й звіти до Національної комісії з цінних паперів та фондових ринків. З іншого боку, це якраз та рутина з перепакуванням одних і тих самих даних, яка й має бути автоматизована, навіть якщо у вас є живий бухгалтер.

Треба зауважити, звичайно – точно так само, як я чверть століття займаюся різними інтернет-проєктами та сайтами, майже не займаючись безпосередньо розробкою, я навіть більше часу маю безпосереднє відношення до підприємництва, включаючи рутинні операції на кшталт обліку, виставлення рахунків, складання звітів, проходження податкових перевірок тощо. Певний рівень обізнаності в питаннях ведення бізнесу потрібен у будь-якому разі, і я не збирався сідати перед Claude Code з єдиним запитом «Зроби мені бухгалтерський облік і подай звіти».

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

З позитивного – реальна цифровізація процесів розвинулася непогано, велика кількість державних сервісів має API та машиночитані формати, виписки з банків завантажуються без проблем і вже є сервіси бухгалтерського обліку, які вміють працювати через API.

Перш за все, було прийнято очевидне рішення – не розробляти власний бухгалтерський облік. Це абсолютно зайва розробка – є сервіси, що реалізують власне облік із планом рахунків і проводками, до них можна звертатися через API та через інтерфейс користувача, нехай так і буде. Я обрав Dilovod.ua і навіть за пробний період встиг розібратися з основними функціями та перенести туди облік. Щоправда, API там відрізняється від UI, а документація має прогалини щодо цих відмінностей. Крім того, API нерідко мовчки не виконує операцію або її частину. Тому ми дійшли до правильного підходу, що складається з двох частин – adopt та expect. Adopt полягає в тому, що вперше операція з відображення операції (виставлення рахунку, формування акта, проводка, створення об’єкта) виконується вручну в інтерфейсі користувача, а потім агент через API отримує результат і відтворює операцію у вигляді звернення до API. Expect – тобто агент після кожної операції, що змінює стан, знає, що має вийти в результаті, заново зчитує стан об’єкта та перевіряє, чи всі поля відповідають очікуваним.

Протокол безпеки є жорстким – агент не повинен мати можливості здійснювати платежі, подавати безпосередні звіти, він може лише готувати чернетки. З цього погляду чудово підходить «Монобанк» – його API для юридичних осіб дозволяє готувати платежі, але підписувати їх має людина своїм ключем. У «Приваті» агент потенційно може й відправити платіж.

Операції зі звітністю виглядають так само – через токен API можна робити запити read-only, у деяких випадках – внутрішні операції, але подання звітів відбувається з накладенням КЕП, і доручати це агенту нерозумно.

Оскільки у мене є цілком практична необхідність, агент і розробляється саме під ці завдання. Спочатку це було завдання перенесення залишків та імпорту операцій через виписки та вивантаження з попередньої програми обліку. Потім постало питання щодо відображення поточних операцій – я вручну оплатив рахунки в онлайн-банку, і це потрібно було занести в систему. Далі постало завдання реєстрації податкових накладних та подання декларації з ПДВ. В принципі, нічого особливо складного – я вивантажив усе, що зміг знайти в кабінеті платника податків податкової адміністрації, включаючи вхідні накладні, вже подані декларації, зареєстровані вихідні накладні, і доручив агенту розібратися.

Паралельно триває звичайна робота з проєктом, ніби це проєкт з розробки – фіксуємо важливі факти в references, виявляємо операції, які треба винести в навички та виконувати субагентами (наприклад, рознесення операцій із виписок, виставлення рахунків).

І ось реальне досягнення за майже місяць роботи – агент проаналізував попередні податкові накладні, запропонував подати ще одну форму, і в результаті розв'язав проблему з блокуванням накладних, яку місяць тому бухгалтер-людина вирішити не зміг. Чому я називаю це досягненням – тому що я й гадки не мав про такий спосіб вирішення та взагалі про існування додаткової форми; агент підготував усі необхідні документи (мені залишалося лише клікати в інтерфейсі кабінету платника податків), розписав усі кроки (подати податкову накладну, оскільки вона заблокувалася, дочекатися обробки форми, після прийняття форми подати пояснення щодо накладної), регулярно аналізував квитанції та відповіді податкової, які я йому надсилав, і в підсумку накладна зареєстрована, як він і передбачав. Важливо ще й те, що тут є об’єктивний контроль – податкова адміністрація, яку не переконаєш, тим більше подаючи форми через сайт.

Повторюю – місяцем раніше в аналогічній ситуації бухгалтер із понад 30-річним досвідом отримав відмову в реєстрації накладної, і подання пояснення не допомогло.

Загалом, агенту залишилося нарахувати зарплату (розрахунок він уже зробив) і підготувати всі платежі, щоб закрити місяць, – тож я пішов керувати процесом написання контуру підготовки платежів, там і протестуємо.

Штучний інтелект проти податкової служби та бухгалтерів

Стратегія охолодження ЦОД для епохи AI