Один акт, одна счёт-фактура и одна таблица расхождений, которую можно проверить глазами за несколько минут.

Я часто вижу одну и ту же бухгалтерскую рутину: исполнитель прислал акт, внутри 18 строк услуг, сумма почти совпадает, но где-то уехал период, ставка НДС или формулировка позиции. Человек открывает два файла рядом, сверяет реквизиты, даты, номера договоров, суммы по строкам, потом переносит замечания в письмо. На коротком акте это терпимо. На пакете из 20 документов работа растягивается на полдня.

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

Что именно нужно сверять в актах

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

Проблема в том, что ошибки редко выглядят как крупное расхождение на 100 000 рублей. Намного чаще встречаются мелкие сдвиги. В одном документе период «01.03–31.03», в другом «01.03–30.03». В акте написано «консультационные услуги», а в договоре «сопровождение сервиса». В счёте указана ставка НДС 20%, в акте сумма выглядит так, будто НДС не выделяли. Человек замечает такие вещи, но платит временем и вниманием.

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

Где появляется экономия: разбор процесса по минутам

Условный пример: бухгалтер сверяет акт на 24 строки с договором и счётом, вручную это занимает около 2 часов, потому что приходится открыть 3 файла, сверить реквизиты, пройтись по каждой позиции, пересчитать НДС и оформить замечания. В ИИ-процессе первые 6–8 минут уходят на загрузку файлов, распознавание текста, сравнение и выдачу таблицы. Ещё 2–5 минут нужны человеку, чтобы проверить спорные строки и решить, отправлять ли документ на исправление.

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

Подход Когда подходит Что получает бухгалтер Ограничение
Ручная сверка 1–2 документа в неделю, нестандартные договоры Полный контроль глазами Высокая нагрузка на внимание, легко пропустить мелкое поле
Разовая сверка в ИИ-чате Нужна быстрая проверка конкретного акта Таблица расхождений, список вопросов контрагенту Нужна финальная проверка человеком
Автоматизация через сценарий Поток однотипных актов каждый день Регулярный отчёт по расхождениям Требуется настройка маршрута файлов и правил
Гибридный процесс Разные контрагенты и разные форматы ИИ делает первый проход, бухгалтер принимает решение Нужно поддерживать шаблон проверки

Вариант 1: разовая сверка в чате

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

Мой базовый запрос выглядит так:

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

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

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

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

Вариант 2: автоматизация через no-code-сценарий

Когда актов много, чат становится узким местом. Тогда процесс выносят в сценарий: файл попадает в папку, почту или форму, затем запускается распознавание текста, сравнение с эталонными данными и отправка отчёта бухгалтеру. В no-code-автоматизаторе это обычно собирается из блоков: входящий файл, извлечение текста, запрос к языковой модели, запись результата в таблицу, уведомление ответственному.

Для такого сценария я не советую начинать с интеграций. Сначала нужен эталон правил. Какие расхождения критичны? Какая разница в копейках допустима из-за округления? Нужно ли проверять формулировки услуг дословно или достаточно совпадения смысла? Кто получает отчёт, если найдено 0 ошибок? Кто решает спор, если ИИ отметил строку как рискованную?

Условный пример: компания из сферы бухгалтерского аутсорсинга, ~30 сотрудников, получает 80–120 актов в неделю от подрядчиков. Для такого потока полезен гибридный сценарий: модель извлекает поля и собирает таблицу расхождений, младший бухгалтер проверяет только строки со статусом «требует внимания», старший бухгалтер смотрит документы с риском по сумме, НДС и реквизитам. Цифра «10 минут» достижима именно для первого прохода по одному типу документов, а не для юридического принятия всех актов пачкой.

Про внедрение без хаоса у меня есть отдельный разбор, где полезно начать с карты повторяемых операций, а не с выбора инструмента: как внедрить нейросети в рабочие процессы. Для актов это особенно заметно. Если регламент проверки не описан человеком, модель будет угадывать критерии.

Как подготовить документы, чтобы ИИ не ошибался на входе

Качество сверки начинается до запроса. Скан на 150 точек на дюйм, тень от сгиба и повернутая таблица повышают риск неправильного OCR. Лучше загрузить исходный PDF с текстовым слоем. Если доступен только скан, стоит проверить, читаются ли номера, даты и суммы при увеличении до 150–200%.

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

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

Какие ошибки ИИ должен искать в первую очередь

Я делю расхождения на финансовые, юридические и операционные. Финансовые требуют самой быстрой реакции: итоговая сумма, НДС, количество, цена за единицу, валюта. Юридические касаются реквизитов, договора, сторон, периода и подписантов. Операционные ошибки мешают обработке: неверный номер заказа, не тот проект, нет приложения, лишняя строка услуги.

Для промпта полезно задать шкалу риска:

  • высокий риск: сумма, НДС, контрагент, ИНН, номер договора, период;
  • средний риск: название услуги, количество, дата акта, номер счёта;
  • низкий риск: опечатки в описании, формат даты, лишние пробелы.

Такой список убирает лишние споры. Если модель нашла разницу между «услуги сопровождения» и «сопровождение сервиса», она не должна ставить максимальную тревогу автоматически. А вот расхождение в ИНН или ставке НДС нельзя прятать в общий комментарий.

Контроль качества: где нужен человек

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

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

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

В командах, где сотрудники только учатся работать с ИИ, помогает короткое обучение на 5–7 типовых актах. Здесь пригоден подход из статьи про нейросети в образовании и саморазвитии: модель лучше использовать как тренажёр мышления. Пусть бухгалтер сначала сам отметит расхождения, затем сравнит свой список с результатом ИИ и поправит шаблон запроса.

Что бы я настроил первым

Я бы начал не с полной автоматизации, а с одного устойчивого сценария. Взял бы 10 уже закрытых актов, где известен результат проверки, и прогнал их через один шаблон. После этого посмотрел бы, где модель промахивается: суммы, периоды, номенклатура, реквизиты или OCR. Только затем имеет смысл подключать автоматический маршрут файлов.

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