AI против налоговой и бухгалтеров

Я как-то на стриме упоминал, что пошел применять AI в еще одну сферу, где, как и в разработке, принято считать, что это сложно, настоящего специалиста заменить нельзя, модель просто не разберется, как надо, вы еще придете просить, чтобы мы разобрались, что вы там с AI наворотили — короче, вы знаете. Речь идет о бухучете.

Несмотря на то, что я уже год с лишним вожусь с отдельным коммерческим продуктом в виде чатбота-консультанта по налоговому и бухгалтерскому учёту, я никакого особого желания лезть в эту сферу не испытывал — у меня есть несколько подшефных компаний, где есть буквально несколько операций в месяц, этим по инерции, как много лет подряд, занималась бухгалтер за небольшую часть ставки и пока всё работало, я ничего не трогал. Пока бухгалтер не сказала, что больше не хочет. Идея искать нового бухгалтера выглядела естественной, но экономически неоправданной — денег там мало, тратить их все на то, чтобы новый человек начал разбираться и делал как-то рутинные операции (причем сначала он придет с рассказом, как всё запущено, вы же понимаете).

В общем, нетрудно догадаться, что я решил натравить на задачу AI и посмотреть, что получится. Для тренировок у меня был собственный ФОП (физлицо-предприниматель), причем с историей за несколько лет (выписки, счета), а среди подшефных компаний — ООО на едином налоге и акционерное общество на общей системе учета, плательщик НДС. Ну да, такой джекпот — отчетность акционерного общества включает в себя не только стандартные налоговые отчеты, но и отчеты в национальную комиссию по ценным бумагам и фондовым рынкам. С другой стороны, это как раз та рутина с переупаковкой одних и тех же данных, которая и должна автоматизироваться, даже если у вас есть живой бухгалтер.

Надо оговориться, конечно — точно так же, как я четверть века занимаюсь различными интернет-проектами и сайтами, почти не занимаясь непосредственно разработкой, я даже больше времени имею самое непосредственное отношение к предпринимательству, включая рутинные операции типа учета, выставления счетов, составления отчетов, прохождения налоговых проверок и так далее. Определенный уровень эрудиции в части ведения бизнеса нужен в любом случае и я не собирался садиться перед Claude Code с единственным промптом “Сделай мне бухучет и сдай отчеты”.

В автоматизации бухучета есть и хорошие стороны, и не очень. Из “не очень” — большое количество существующих решений начинали писаться в 90-х, содержат огромное количество нелогичных и недружественных моментов, так, что даже сложно разобраться — это результат напластований за десятилетия или сознательный хаос для поддержания всякого сопутствующего бизнеса для подачи отчетов и прочих автоматизаций. При этом большая часть софта пишется под Windows и требует оплаты за каждую дополнительную функцию.

Из хорошего — реальная цифровизация процессов развилась неплохо, большое количество государственных сервисов имеют API и машиночитаемые форматы, выписки из банков выгружаются без проблем и уже есть сервисы бухучета, умеющие работать по API.

Прежде всего, было принято очевидное решение — не писать собственно бухучет. Это совершенно лишняя разработка — есть сервисы, реализующие собственно учет с планом счетов и проводками, к ним можно ходить по API и через UI, пусть так и будет. В качестве такого я выбрал Dilovod.ua и даже за пробный период успел разобраться с основными функциями и перенести туда учет. Правда, API там отличается от UI, а документация страдает пробелами в части этих отличий. Кроме того, сплошь и рядом API молча не выполняет операцию или ее часть. Поэтому мы пришли к правильному способу, состоящему из двух частей — adopt и expect. Adopt заключается в том, что первый раз операция по отражению операции (выставление счета, формирование акта, проводка, создание объекта) выполняется вручную в UI, а затем агент через API получает результат и воссоздает операцию в виде обращения к API. Expect — то есть агент после каждой мутирующей операции знает, что должно получиться в результате, читает заново состояние объекта и сверяет, что все поля соответствуют ожидаемым.

Протокол безопасности принят жесткий — агент не должен иметь возможности осуществлять платежи, подавать непосредственные отчеты, он может лишь готовить черновики. С этой точки зрения прекрасно подходит Монобанк — его API для юрлиц позволяет готовить платежи, но подписывать должен человек своим ключом. В Привате потенциально агент может и отправить платеж.

Операции по отчетности выглядят так же — через токен API можно делать read-only запросы, в ряде случаев — внутренние операции, но подача отчетов происходит с наложением КЭП и закладывать такое агенту неразумно.

Поскольку у меня есть совершенно практическая необходимость, под эти задачи агент и строится. Сначала это была задача переноса остатков и импорт операций через выписки и выгрузки из предыдущей программы учета. Затем возник вопрос отражения текущих операций — оплату счетов я сделал вручную в онлайн-банке и это надо было провести. Далее выросла задача регистрации налоговых накладных и подачи декларации по НДС. В принципе, ничего особо сложного — я выгрузил всё, что мог найти в кабинете плательщика налогов налоговой администрации, включая входящие накладные, уже поданные декларации, зарегистрированные исходящие накладные, и отправил агента разбираться.

Параллельно идет обычная работа с проектом, как если бы это был проект по разработке — фиксируем важные факты в references, выявляем операции, которые надо вынести в скиллы и выполнять субагентами (например, разнос операций из выписок, выставление счетов).

И вот реальное достижение за почти месяц работы — агент проанализировал предыдущие налоговые накладные, предложил подать еще одну форму, и в результате решил проблему с блокировкой накладных, которую месяц назад бухгалтер-человек решить не смог. Почему я называю это достижением — потому что я понятия не имел о таком способе решения и вообще существования дополнительной формы, агент подготовил все необходимые документы (мне оставалось только кликать в интерфейсе кабинета налогоплательщика), расписал все шаги (подать налоговую накладную, раз она заблокировалась, дождаться обработки формы, после принятия формы подать объяснение по накладной), регулярно анализировал квитанции и ответы налоговой, которые я ему выгружал, и в итоге накладная зарегистрирована, как он и предсказывал. Важно еще и то, что тут есть объективный контроль — налоговая администрация, которую не уговоришь, тем более подавая формы через сайт.

Повторяю — месяцем ранее в аналогичной ситуации бухгалтер-человек с 30+ годами опыта получил отказ в регистрации накладной и подача объяснения не помогла.

В общем, до конца недели агенту осталось начислить зарплату (расчет он уже сделал) и подготовить все платежи, чтобы закрыть июль, — так что пошел я руководить процессом написания контура подготовки платежей, там и потестируем.