ИИ для сверки актов: сравнение документов и ошибки в 2026

ИИ берёт на себя первый проход по актам: вытаскивает реквизиты, сравнивает суммы, подсвечивает расхождения и готовит список вопросов для бухгалтера.
Сверка актов редко выглядит как сложная аналитика. На практике это монотонная работа: открыть два документа, проверить номер, дату, контрагента, ИНН, период, услуги, количество, цену, НДС, итоговую сумму, подписи и приложения. Ошибка на 1 копейку может остановить закрытие месяца, а пропущенная строка в акте на 20 позиций потом превращается в переписку с поставщиком.
Я отношусь к ИИ в бухгалтерских задачах как к внимательному младшему помощнику. Он быстро сравнивает документы и не устаёт на двадцатой строке. Но финальное решение остаётся за человеком: нейросеть не знает внутренних договорённостей, не видит контекст сделки и может неверно прочитать плохо отсканированный файл. Хорошая схема такая: модель делает черновую сверку, бухгалтер проверяет спорные места, затем фиксирует результат в учётной системе.
Если вы уже используете нейросети для рабочих задач, сверка актов хорошо ложится в тот же подход, что описан в материале про внедрение нейросетей в рабочие процессы: начинать надо не с магии, а с повторяемого сценария, критериев качества и понятного формата ответа.
Что именно ИИ сравнивает в актах
В типовой сверке есть два уровня: реквизиты и содержательная часть. Реквизиты проверяются быстро, но именно там часто прячутся неприятные мелочи. В акте может быть верный контрагент, но старый КПП. Может совпадать сумма, но отличаться период оказания услуг. Бывает, что номер договора указан в одном документе, а во втором стоит приложение или спецификация.
Я обычно прошу модель разобрать документ на поля:
- номер и дата акта;
- поставщик, покупатель, ИНН, КПП;
- договор, заказ, приложение;
- период услуг или поставки;
- строки номенклатуры;
- количество, цена, сумма без НДС, ставка НДС, сумма НДС, итог;
- подписи, печати, комментарии, приложения.
После этого ИИ сравнивает поля между двумя актами или между актом и счётом. Для документов на 1–3 страницы человек часто тратит 10–20 минут на аккуратную проверку. Если в акте 30–80 строк, ручная сверка легко растягивается до часа, особенно когда нужно переносить данные в таблицу. Нейросеть сокращает первый проход до минут, но экономия появляется только при хорошем промпте и чистом входном файле.
Подробный подход к качеству текста запроса я разбирал в статье про нейросеть для генерации текста и проверку результата. Для актов принцип тот же: чем точнее задан формат ответа, тем меньше ручной расшифровки после модели.
Где ИИ полезен, а где бухгалтер всё равно нужен
ИИ хорошо справляется с задачами, где есть структура. Акт, счёт, УПД, накладная, договорная спецификация, таблица услуг, список закрывающих документов. Всё это можно привести к полям и сравнить.
| Задача | Что делает ИИ | Что проверяет бухгалтер | Риск ошибки |
|---|---|---|---|
| Сверка реквизитов | Находит ИНН, КПП, номер договора, дату | Проверяет актуальность данных по карточке контрагента | Старые реквизиты могут выглядеть формально корректно |
| Сравнение строк | Сводит позиции в таблицу, ищет расхождения | Уточняет допустимые замены названий услуг | «Техподдержка» и «сопровождение» могут быть одной услугой |
| Проверка сумм | Пересчитывает итоги, НДС, копейки | Сверяет правила округления по договору | Разные правила округления дают расхождение в 0,01–0,03 ₽ |
| Поиск пропусков | Показывает строки, найденные только в одном документе | Решает, это ошибка или перенос в другой период | Модель не знает график закрытия |
| Подготовка письма | Формулирует список вопросов поставщику | Убирает лишнее и добавляет контекст | Черновик может быть слишком резким или неполным |
Мне нравится начинать не с полной автоматизации, а с «красного списка»: модель должна вернуть только расхождения и степень уверенности. Если расхождений нет, она пишет коротко: «Критичных расхождений не найдено, проверьте подписи и приложения вручную». Это снижает шум.
В SoftChat для такой работы можно использовать чат с историей диалогов, переключать модель в рамках разговора, хранить многоразовые шаблоны запросов и прикреплять документы к сообщениям, когда выбранная модель поддерживает нужный формат. Я бы не превращал один чат в свалку всех контрагентов. Удобнее держать отдельные рабочие ветки по типам задач: «сверка актов», «проверка договора», «письмо контрагенту». Так проще вернуться к логике предыдущей проверки.
Рабочий процесс сверки: от файла до списка ошибок
Сверка через ИИ ломается в двух местах: на плохом распознавании и на расплывчатом задании. Если скан перекошен, таблица разорвана на две страницы, а печать перекрывает сумму, модель может уверенно написать неверный вывод. Поэтому я делю процесс на короткие шаги.
- Подготовить файлы. Лучше давать текстовый PDF, таблицу или хорошо читаемый скан. Если документ сфотографирован под углом, сначала привести его в нормальный вид.
- Назвать документы. Не «файл 1» и «файл 2», а «акт поставщика» и «акт в учётной системе». Модель должна понимать, что с чем сравнивает.
- Попросить извлечь данные в таблицу. До анализа полезно увидеть, как нейросеть прочитала поля.
- Запустить сравнение. Отдельно по реквизитам, строкам, суммам и НДС.
- Попросить финальный отчёт. В отчёте нужны расхождения, источник, сумма влияния и рекомендация.
Если задача повторяется каждую неделю, промпт стоит сохранить как шаблон. В SoftChat для повторяемых стартов диалога есть шаблоны промптов, а черновик запроса можно улучшить перед отправкой через отдельную кнопку. Это удобно, когда бухгалтер набросал мысль коротко, а системе нужен строгий формат ответа.
Готовый промпт для первого сравнения актов
Ниже шаблон для публичной чат-модели или любой языковой модели, которая умеет читать прикреплённые документы. Он не привязан к конкретному бренду.
Ты работаешь как помощник бухгалтера по сверке закрывающих документов.
Сравни два документа:
1. «Акт поставщика».
2. «Акт из учётной системы».
Задача:
- извлеки реквизиты из каждого документа;
- сравни номер, дату, контрагента, ИНН, КПП, договор, период;
- сравни строки услуг или товаров;
- проверь количество, цену, сумму без НДС, ставку НДС, сумму НДС и итог;
- найди пропущенные, лишние и изменённые строки;
- отдельно проверь расхождения в копейках.
Формат ответа:
1. Краткий вывод: есть ли критичные расхождения.
2. Таблица расхождений: поле, документ 1, документ 2, влияние, рекомендация.
3. Список мест, которые нужно проверить вручную.
4. Черновик письма контрагенту, если найдены ошибки.
Не делай вывод «документы совпадают», если не смог прочитать хотя бы одно поле. В таком случае напиши «поле не распознано».
Для примера: если в одном акте строка называется «Абонентское сопровождение за март», а во втором «Техническая поддержка, март», модель должна не сразу считать это ошибкой, а пометить как «похоже на одну услугу, нужна проверка договора». Такая формулировка полезнее, чем сухое «наименования не совпадают».
Промпт для извлечения таблицы перед сверкой
Иногда лучше не просить модель сразу сравнивать документы. Сначала пусть покажет, что она прочитала. Это особенно помогает при сканах, многострочных позициях и актах с приложениями.
Извлеки данные из акта в структурированную таблицу.
Поля шапки:
- номер акта;
- дата;
- поставщик;
- покупатель;
- ИНН и КПП сторон;
- договор;
- период;
- итог без НДС;
- НДС;
- итог с НДС.
Таблица строк:
номер строки | наименование | количество | единица | цена | сумма без НДС | ставка НДС | НДС | сумма с НДС
Правила:
- если поле не найдено, пиши «нет данных»;
- не додумывай значения;
- суммы выводи в рублях с двумя знаками после запятой;
- после таблицы перечисли места с низкой уверенностью чтения.
Затем можно дать второй запрос: «Сравни две извлечённые таблицы и верни только расхождения». Такой двухшаговый процесс медленнее на один запрос, зато проще отловить ошибку чтения до финального вывода.
Промпт для локальной модели
Локальные модели часто используют там, где документы нельзя отправлять во внешний сервис: персональные данные, коммерческие условия, закрытые контракты. Но у локального запуска есть цена: нужно следить за качеством распознавания, контекстным окном, скоростью и настройками безопасности. Для бухгалтерии это не вопрос моды, а вопрос регламента.
Ты анализируешь текст, извлечённый из бухгалтерских документов.
Не используй внешние знания. Работай только с данными ниже.
Документ А:
[вставить текст первого акта]
Документ Б:
[вставить текст второго акта]
Сравни документы по правилам:
1. Сначала выпиши реквизиты каждого документа.
2. Затем сравни табличные строки.
3. Сгруппируй расхождения по типам: реквизиты, период, номенклатура, количество, цена, НДС, итог.
4. Для каждого расхождения укажи уровень уверенности: высокий, средний, низкий.
5. Если текста недостаточно, не делай вывод, а запроси недостающий фрагмент.
Ответ дай в таблице и отдельным блоком «Что проверить вручную».
Условный пример: компания из сферы услуг, ~50 сотрудников, получает 60 актов в месяц. Если бухгалтер тратит в среднем 12 минут на первичный просмотр одного акта, это 12 часов ручной проверки до переписки и исправлений. Даже частичная автоматизация первого прохода освобождает время на спорные документы, где действительно нужен профессиональный взгляд.
Как снижать количество ложных ошибок
Нейросеть может найти лишние расхождения там, где человек видит нормальную вариативность. Например, «услуги связи» и «телекоммуникационные услуги» в двух документах. Или «31.03» и «март», если период задан разными способами. Поэтому я добавляю в промпт правила нормализации.
Полезные правила:
- считать пробелы, переносы строк и регистр техническими отличиями;
- сравнивать ИНН как точную строку, без «похожести»;
- суммы сравнивать с допуском 0,01 ₽ только после пересчёта;
- даты приводить к формату ДД.ММ.ГГГГ;
- наименования услуг считать похожими только при совпадении периода, суммы и договора;
- не объединять строки, если различается ставка НДС.
Если нужна более широкая картина по бытовым и офисным сценариям, полезно свериться с материалом про использование нейросетей и чат-ботов в повседневных задачах. Там хорошо видно, какие задачи лучше отдавать модели, а какие оставлять человеку.
Критерии приёмки результата
Я бы не внедрял сверку актов без короткого набора проверок. Он нужен, чтобы не спорить каждый раз, «нормально модель ответила или нет».
Минимальный критерий качества такой:
- модель вернула все реквизиты или явно написала «нет данных»;
- каждая сумма в выводе имеет источник;
- расхождения сгруппированы по типам;
- есть отдельный список ручной проверки;
- нет финального вывода о совпадении, если часть документа не прочитана;
- письмо контрагенту не содержит утверждений, которых нет в таблице расхождений.
Для контроля можно прогнать 10 старых актов, где ошибки уже известны. Это не полноценная статистика, но быстрый тест покажет слабые места: плохое чтение таблиц, путаницу с НДС, склонность объединять похожие строки. Если модель пропускает критичные расхождения на тестовых документах, процесс нельзя выпускать в работу без дополнительной проверки человеком.
В образовательных сценариях похожая логика применяется к разбору учебных материалов: модель помогает структурировать данные, но студент проверяет выводы. Об этом подробнее написано в статье про нейросети в образовании и саморазвитии. В бухгалтерии цена ошибки выше, зато сам принцип контроля тот же.
Частые ошибки в промптах бухгалтерии
Первая ошибка, просить «проверь документы» без формата. Модель отвечает общими словами, а бухгалтер всё равно вручную ищет строки. Лучше сразу требовать таблицу расхождений.
Вторая ошибка, смешивать сверку и исправление. Если попросить «найди ошибки и подготовь правильный акт», модель может начать додумывать недостающие данные. В бухгалтерии безопаснее разделять: сначала извлечение, затем сравнение, затем рекомендации.
Третья ошибка, не указывать, что делать с нераспознанными полями. Модель иногда стесняется признаться, что не видит часть документа. Формулировка «если поле не найдено, пиши “нет данных”» резко повышает прозрачность.
Четвёртая ошибка, забывать про приложения. В акте может быть одна итоговая строка, а детализация лежит во вложении. Если приложение не передать модели, она сравнит только верхний слой и пропустит расхождения по деталям.
Что бы я сделал на вашем месте
Я бы начал с одного типа документов, например актов по регулярным услугам. Взял бы 10–15 уже закрытых пар, где результат сверки известен, и прогнал через два промпта: извлечение таблицы и сравнение. После этого поправил бы правила нормализации под вашу практику: как называются услуги, какой допуск по копейкам допустим, какие поля критичны всегда.
Если тест проходит нормально, можно сохранять промпт как рабочий шаблон и использовать его на новых актах. Не надо сразу отдавать ИИ всё закрытие месяца. Достаточно начать с первого прохода: подсветить расхождения, собрать вопросы поставщику, отделить чистые документы от спорных. Так бухгалтер остаётся владельцем решения, а нейросеть снимает самую механическую часть работы.