Серебряная пуля для бухгалтерского учёта

История Сделочного учёта началась в Кнопке ещё в 2021 году. Тогда мы старались осознать новую технологию и понять, куда двигаться дальше. Но уже в тот момент почувствовали, что это реальный прорыв. То, чего мы так долго ждали. И рынок, как оказалось, тоже.

Для самого предпринимателя мир перевернулся не сразу. Ведь в бизнесе имеет значение факт: сдали отчётность или нет, вовремя или напоролись на штраф. А как это сделает твоя бухгалтерия не так уж важно. В то же время под капотом сервиса развернулась целая экосистема, которая не только позволила автоматизировать тысячи типовых операций, но и в разы уменьшила затраты на обслуживание, а вместе с тем и стоимость для самого клиента.

Как мы изменили бухгалтерию и перевели тысячу клиентов на технологию, аналогов которой нет в России, рассказал сооснователь Кнопки Евгений Кобзев.

В эффективном обслуживании большого числа организаций меньшими силами бухгалтеры не специалисты. Скорее наоборот, они специалисты в неэффективном обслуживании одной организации бóльшими силами. И они в этом не виноваты, их жизнь толкает.

Бухгалтеров хвалят и ругают не за наращивание эффективности, а, условно, за правильный выбор полей в документе. При этом бывает так, что выбор вообще ни на что не влияет.

На старте было ложное ожидание, что бухгалтеры помогут сделать процесс значительно эффективнее, при этом оно ни на чём не основывалось. А ведь это то же самое, что ждать от водителя создания более совершенного автомобиля. Водитель — не специалист в конструировании, а бухгалтер — не специалист в создании эффективных процессов для IT-решений.

Стало понятно, что user-centered design для нашей ситуации плохо подходит. Так возникла цель: научить разработчиков бухгалтерии, а бухгалтеров — конструированию эффективных процессов и автоматизации. Чтобы все заговорили на одном языке.

И вот вопрос: как научить разработчиков бухгалтерии? Этому люди учатся сначала четыре года в вузе, а потом несколько лет на практике. То же самое и с обучением бухгалтеров технологиям. У нас столько времени, конечно, не было. Нужно было как-то сузиться: кого и чему учить.

Процесс сильно усложнялся необходимостью продолжать обслуживать набранную за годы базу по старой схеме, которая уже не выглядела эффективной. К тому же была сильно завязана на закреплённом за организацией бухгалтере. У нас не было лишних денег, лишних разработчиков и лишних бухгалтеров. Этот корабль плыл, протекал, ломался, и чинить его мы могли только на ходу.

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

Например, если в банковской выписке написано «оплата аренды», то сразу понятно что это, и проводить операцию нужно как оплату услуг.

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

Поначалу он был очень простой. Там не нужно было программировать математику, правила вывода, транслятор. Мы просто писали на С# очень простые конструкции вроде «если в поле документа есть вот такая подстрока, то счета учёта в бухгалтерской системе у этого документа должны быть вот такие, а контрагента взять из документа, а договор повесить вот такой».

И мы начали постепенно описывать учёт клиентов и переводить их на новые рельсы. Бухгалтеры участвовали в описании прямо на С#, по образцу это было несложно. У клиентов постоянно возникали новые ситуации и для их поддержки разработчики расширяли язык. Впервые бухгалтеры и разработчики начали не ставить друг другу задачи, а работать вместе. И начали говорить на одном языке — нашем языке описания.

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

Мы ожидали от искусственного интеллекта, что он будет решать сразу несколько задач: и классификацию жизненных ситуаций клиентов, и корректное отображения ситуаций в учёте. Он, конечно, решал, но не всегда правильно. А где ошибался — неизвестно.

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

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

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

Обычная система управления трудом аутсорсеров совершенно не такая. Невозможно отслеживать, что и с каким качеством происходит каждый день. Можно только отслеживать результат работы за 3 месяца (отчётность) и как-то судить о качестве отчётности (были ли корректировки и требования). Но качество учёта для масштабирования намного важнее.

Приведу метафорический пример. У вас есть в Excel две колонки цифр. В третью колонку нужно записать их сумму — её будем считать результатом работы, отчётом. Можно сложить на калькуляторе числа в каждой строчке и записать сумму. И это будет правильный результат, но немасштабируемый. Ещё 100 новых строчек вас полностью высадят. Это плохой учёт и хорошая отчётность.

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

Система описания сделок позволила нам получить формальный to-do лист действий, необходимый и достаточный для корректного учёта.

Мы взяли и описали всех клиентов одного бухгалтера. Точнее, всех мы описать не смогли. Где-то языка не хватало и расширение было слишком большой задачей. А где-то описание не давало эффекта (условно, каждый платёж требовал отдельного описания, не было повторяемости). Но процентов 80 мы описали.

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

А ещё оказалось, что если описать сделки, то не потребуется закреплять бухгалтера за клиентом. Есть такой стандарт в индустрии. На самом деле, как теперь стало понятно, это происходит потому, что из учёта суть сделок непонятна бухгалтеру-аутсорсеру на 100%, особенно в малом бизнесе. Оплатил клиент куда-то с назначением: «оплата счёта номер 2». А на самом деле это был возврат займа, о котором вы даже не знали. Но вы разобрались с клиентом и это запомнили у себя в голове. А потом пошли в отпуск, а ваш сменщик продолжает почему-то думать, что «оплата счёта номер 2» — это оплата поставщику. А в описании сделок это всё, конечно, оседает, когда ты один раз разобрался. И это мотивирует, даже если разборки долгие.

А ещё оказалось, что для описания большинства сделок вообще не надо быть бухгалтером. Это про учёт ты можешь не знать, а понять и выбрать в интерфейсе, что «оплата аренды» = «оплата услуг» не так уж сложно. И это позволило ещё лучше масштабироваться.

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

Думаю, вы теперь поняли. В первом квартале 2025 года мы сдаём отчётность за 2024 год. А весь 2024 год у нас сведён уже в первый рабочий день 2025 года. Остаётся только нажать кнопку и отправить отчёт.

На самом деле, всё не так просто. Клиент, увидев расчёт, может прислать ещё данные, которые до этого не присылал. И эти данные прекрасно прожуются уже имеющимися правилами. Ну, может, немного донастроить придётся. И всё, профит. В последние дни отчётности ты просто ждёшь недостающие данные, кормишь ими систему и идёшь домой, как только рабочий день закончен.

Это организационно и технически определённо самый крутой проект, в котором я принимал участие. Думаю, никто в мире не умеет закрывать учёт тысяч юрлиц каждый день, да ещё и без закрепления за ними бухгалтеров.

Женя Кобзев, сооснователь Кнопки