ИИ в бухгалтерии: что отдать модели, а что нет

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

Ответственность за отчётность при этом никуда не переезжает. Модель не должностное лицо, оштрафовать её нельзя, и «так распознала нейросеть» не объяснение ни для руководителя, ни для проверяющего.

Первичка: модель читает, код проверяет

Самая понятная задача — документы, которые приходят не через ЭДО (электронный документооборот): сканы, фотографии, файлы из почты. Сейчас их кто-то перебивает руками, и выигрыш здесь заметнее всего: время ручного ввода легко замерить до и после.

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

Отдельно полезна проверка на полноту. Закон о бухгалтерском учёте перечисляет обязательные реквизиты первичного документа (здесь и дальше — моё прочтение норм, не юридическая консультация): наименование документа, дату составления, наименование организации, составившей документ, содержание факта хозяйственной жизни, натуральное и (или) денежное измерение с единицами измерения, должности и подписи ответственных лиц с фамилиями и инициалами (часть 2 статьи 9 закона № 402-ФЗ). Вопрос «каких из этих реквизитов в документе нет» модели по силам: ответ проверяется взглядом, а пропуск ловится до того, как документ ушёл в учёт.

Теперь граница. Модель извлекает суммы, но не складывает их. Разница принципиальная: извлечённое число можно сверить с картинкой, вычисленное сверить не с чем — почему так, разбирал отдельно.

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

Последнее не формальность. С 1 января 2026 года основная ставка НДС — 22 процента, а модель, обученная на текстах прошлых лет, чаще видела двадцать. Пока она только читает, это почти не страшно: на нечётком скане она может прочесть привычную цифру, но код сверит ставку с суммами и не пропустит. Опасно, когда ей разрешают «поправить очевидную опечатку» — тогда она аккуратно приведёт документ к тому, что считает нормой. У кода нет представлений о норме, только таблица.

Все документы приходят бухгалтеру; если хоть одна проверка не прошла — с пометкой, что именно не сошлось. Не «модель исправила», а «вот расхождение». Часть таких расхождений окажется ошибкой распознавания, часть — ошибкой в самом документе поставщика, и вторые нельзя терять, маскируя их под первые.

Про ЭДО отдельно. Электронный УПД в формате, утверждённом ФНС, приходит уже размеченным: поля на своих местах, суммы в своих полях. Модель там не нужна, и прогонять такой документ через неё — значит добавить шаг, который способен только испортить данные. Место для модели — всё, что пришло вне этого формата.

Сверка с контрагентом

Здесь, на мой взгляд, выигрыш больше, чем обычно ждут: сверка просто не выглядит задачей для нейросети.

Акт сверки от контрагента написан его словами. У него «Реализация (акт, накладная) № 418», у вас «Поступление услуг 418»; у него платёж одной строкой, у вас двумя; у него документ последнего дня месяца, у вас тот же документ первым числом следующего. Сопоставление по точному совпадению закрывает простые строки, а всё остальное бухгалтер разбирает глазами, строку за строкой.

Модель сильна именно в этом остатке. Понять, что «акт 418» и «УПД 418» один документ, что две ваши оплаты соответствуют одной строке контрагента, что расхождение объясняется периодом, а не суммой, — это сопоставление по смыслу, а не по символам. И проверяется оно быстро: пара либо та, либо нет, и для этого достаточно открыть два документа.

Суммы расхождений модель при этом не считает. Её выход — список пар с пометкой: совпало, нет у нас, нет у них, разные периоды, разные суммы. Разницу по каждой паре и итоговое сальдо код считает по исходным числам из обеих таблиц. Бухгалтер получает не одну цифру расхождения, а короткий список причин, каждая из которых проверяется за минуту.

Главный риск здесь другой. Не найти пару — нормальный ответ; хуже, когда модель находит пару для всего и подбирает похожий документ, лишь бы строка не осталась одинокой. Проверяется это просто: добавьте в тестовый акт строку, которой у вас точно нет. Хорошо настроенный разбор оставит её без пары, плохой — пристроит к ближайшей по сумме.

Классификация операций и учётная политика

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

Рабочая схема: модель выбирает из закрытого списка статей вашего справочника, называет слово в назначении платежа, на котором держится выбор, и имеет право ответить «не знаю». Бухгалтер принимает или меняет. Всё, что повторяется — один контрагент, всегда одна статья, — лучше вынести в обычные правила сопоставления в учётной системе: они дешевле, предсказуемее и не меняют поведение после обновления модели. Модели остаётся хвост нетиповых платежей.

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

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

«Как правильно по закону» — вопрос другого рода. Учётную политику экономический субъект формирует самостоятельно, руководствуясь законодательством, федеральными и отраслевыми стандартами (часть 2 статьи 8 того же закона), и выбор способа учёта опирается на действующую редакцию стандарта. Модель ответит на такой вопрос уверенно и по памяти, а память у неё заканчивается на дате обучения. Это вопрос к правовой базе с датой редакции.

Кто отвечает, если ошибся не человек

Тот же, кто отвечал до модели.

Ведение бухгалтерского учёта и хранение документов организует руководитель; ведение учёта он возлагает на главного бухгалтера или другое должностное лицо либо заключает договор об оказании услуг по ведению учёта, а в случаях, которые закон допускает, ведёт сам (части 1 и 3 статьи 7 закона № 402-ФЗ). Если главный бухгалтер или тот, на кого возложен учёт, отказался принимать документ, разобранный моделью, а руководитель настоял, данные принимаются к регистрации в учётных регистрах по его письменному распоряжению, и за созданную так информацию он отвечает единолично (часть 8 той же статьи).

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

Ни в одной из этих конструкций нет места для инструмента. Отвечает тот, кто принял результат, и вопрос только в том, мог ли он на самом деле его проверить.

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

Это моё прочтение норм, а не юридическая консультация. Для конкретной ситуации нужен юрист или аудитор.

Условие несогласия

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

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

Чего я делать не стал бы

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

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

Не стал бы пускать зарплатные и кадровые документы в тот же контур, что и счета поставщиков: там персональные данные в каждой строке, и маршрут для них решается отдельно — с обезличиванием до отправки.

Открытый вопрос

Весь контур держится на том, что человек в точке принятия действительно смотрит. Первые недели так и есть. Через несколько месяцев модель ошибается редко, бухгалтер привыкает, и кнопка «принять» нажимается быстрее, чем открывается документ.

Формально ответственность на месте, фактически проверки уже нет. Как измерить эту разницу, я не знаю. Очевидный способ — подмешивать заведомо неверные предложения и смотреть, сколько пропущено, — в живом учёте неприемлем: пропущенная учебная ошибка становится настоящей. Выборочная проверка принятых документов задним числом работает, но возвращает ту ручную работу, от которой уходили, и при каком её объёме контур ещё имеет смысл, я пока не понял.