Обновлено 25 июня 2026. Я переписал этот гайд: убрал устаревшие названия инструментов, добавил практическую схему распознавания документов и разобрал контроль ошибок до загрузки в учётную систему.

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

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

Что изменилось в обновлённой версии

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

Я обновил структуру под текущую практику. Вместо общего разговора про распознавание здесь есть схема: скан, предобработка, OCR, NLP-разбор, валидация, JSON, контроль человеком, импорт в ERP или бухгалтерскую программу. Для каждой стадии есть типовые ошибки. Например, у акта на 2 страницы сумма может быть на первой странице, подпись на второй, а номер договора в шапке мелким шрифтом. Если система распознаёт страницы как отдельные документы, она создаст два неполных объекта вместо одного.

Из каких документов ИИ вытаскивает сумму, дату и контрагента

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

Скан добавляет шум. Разрешение ниже 200 DPI часто портит мелкие реквизиты. Поворот на 2–5 градусов мешает таблицам. Фото с телефона даёт перспективные искажения: левая часть листа крупнее правой, строки уходят вверх, штамп становится тенью. Поэтому первый слой автоматизации занимается не бухгалтерией, а изображением.

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

Как работает OCR на бухгалтерских сканах

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

Практический минимум для OCR-контура выглядит так: изображение хранится отдельно, текст хранится послойно, координаты остаются доступными, каждая найденная сущность получает оценку уверенности. Если сумма распознана с уверенностью 0,62, а контрагент с 0,94, эти поля нельзя отправлять в учёт одинаково. Первое лучше показать бухгалтеру, второе можно пропустить через автоматическую сверку.

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

Как NLP выделяет сумму, дату и контрагента

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

Я обычно делю извлечение на 4 шага. Первый, классификация документа. Второй, поиск кандидатов на поле. Третий, выбор лучшего кандидата по контексту. Четвёртый, приведение к нормальному виду. Например, сумма «12 450,00» превращается в число 12450.00, дата «5 июня 2026 г.» превращается в ISO-формат, а контрагент сопоставляется со справочником.

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

Модельный кейс: компания из сферы оптовой торговли, ~80 сотрудников, получает 1 500 первичных документов в месяц и хранит 12 000 карточек контрагентов в справочнике. При таком объёме ручная сверка каждого названия превращается в десятки часов однотипной работы. Автоматический поиск кандидатов по реквизитам сокращает очередь ручной проверки до документов с низкой уверенностью, дублями и новыми контрагентами.

Проверка ошибок перед загрузкой

Распознавание без валидации опасно. Система может уверенно ошибиться, если скан чистый, но документ составлен необычно. Поэтому после извлечения полей нужен набор правил.

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

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

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

JSON как промежуточный слой между сканом и учётом

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

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

JSON не заменяет бухгалтерскую программу. Он работает как буфер. В нём удобно исправлять спорные поля, запускать повторные проверки и передавать данные в разные системы через API, XML, CSV или пакетный импорт. Если компания меняет учётную систему, весь конвейер распознавания не приходится переписывать с нуля. Достаточно заменить адаптер выгрузки.

Как данные попадают в учётную систему

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

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

Я не советую начинать с полного автопроведения. Безопаснее выбрать одну группу документов, например счета от 20 постоянных поставщиков, настроить правила и 2–4 недели собирать статистику ошибок. После этого видно, какие поля требуют ручного контроля, а какие стабильно распознаются.

Где бухгалтер остаётся в процессе

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

Чтобы это работало, интерфейс проверки должен быть коротким. На экране нужны скан, найденные поля, подсветка источников, причина сомнения и кнопки исправления. Если бухгалтеру приходится открывать 5 окон, искать файл в почте и вручную копировать номер договора, экономия исчезает.

Хороший показатель качества, доля документов, прошедших без ручного ввода. Но смотреть нужно на 3 числа сразу: процент автозаполнения, процент ошибок после проверки и среднее время обработки исключения. Система, которая автозаполняет 95% полей, но часто путает контрагента, хуже более осторожного конвейера с автозаполнением 80% и понятной очередью контроля.

Риски и защита данных

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

Для SaaS-сценариев нужна проверка договора обработки данных и мест хранения. Для локального контура важнее обслуживание моделей, обновление OCR, мониторинг очередей и место под архив изображений. Один PDF на 10 страниц может занимать 2–8 МБ. При 50 000 документов в год архив быстро растёт до сотен гигабайт с учётом копий и версий.

Как запустить пилот без хаоса

Я бы начинал с карты документов. Возьмите 200–500 файлов за последние месяцы, разложите их по типам и качеству. Отдельно отметьте многостраничные документы, фото с телефона, сканы с печатями, документы с таблицами и файлы от постоянных контрагентов.

Дальше задайте целевые поля. Не нужно пытаться распознать всё. Для первого пилота достаточно 8–12 полей: тип, номер, дата, контрагент, идентификатор, договор, сумма без налога, налог, итог, валюта, статус проверки, ссылка на оригинал. Затем настройте правила качества: какие документы уходят в автозагрузку, какие требуют просмотра, какие отклоняются.

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

Что считать успешным результатом

Успех пилота измеряется не количеством модных терминов, а очередью бухгалтерии. Если раньше один документ требовал 3–7 минут ручного ввода, то автоматическое заполнение большинства полей уже даёт заметный эффект. При 1 000 документов в месяц даже 2 минуты экономии на каждом документе дают больше 30 часов освобождённого времени.

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

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