ИИ для распознавания сканов первичных документов в 2026

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

Бухгалтерская первичка редко приходит в идеальном виде. Один поставщик присылает УПД в PDF, другой фотографирует акт на телефон, третий сканирует счёт-фактуру под углом. Внутри каждого файла нужно найти дату, номер, ИНН, КПП, контрагента, сумму без налога, НДС, итоговую сумму и иногда десятки строк номенклатуры. Если делать это руками, человек тратит внимание на повторяемые действия: открыть файл, приблизить печать, сверить сумму, перенести реквизиты, проверить арифметику.

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

Что именно нужно извлечь из скана

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

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

Главная сложность не в том, чтобы «увидеть текст». OCR уже много лет справляется с печатными документами лучше, чем с рукописными пометками. Сложность в контексте. Число «12.03.2026» может быть датой документа, датой договора или сроком оплаты. Сумма «118 000,00» может быть итогом, авансом или ценой одной позиции. Поэтому я не закладываю логику «нашли первое похожее поле и сохранили». Нужна карта документа и правила выбора.

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

Как работает цепочка OCR плюс ИИ

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

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

Дальше запускаются проверки. ИНН проверяется по длине и контрольным цифрам, КПП по формату, БИК по справочнику банка, дата по допустимому диапазону, суммы по арифметике. Для НДС простая проверка выглядит так: сумма без НДС плюс налог должна совпадать с итогом с учётом округления до копеек. Если в документе 100 000,00 без НДС и 20 000,00 НДС, итог должен быть 120 000,00. Если OCR выдал 128 000,00, запись нельзя отправлять в учёт без ручной проверки.

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

Где ИИ ошибается чаще всего

Ошибки обычно появляются в одних и тех же местах. Первая группа, качество изображения. Фото с бликом на итоговой строке может превратить «8» в «3», а косой скан сжимает таблицу так, что OCR склеивает соседние колонки. Вторая группа, похожие реквизиты. В УПД есть продавец, покупатель, грузоотправитель и грузополучатель. Если модель не понимает роль блока, она может взять ИНН покупателя вместо ИНН поставщика.

Третья группа, суммы с несколькими налоговыми ставками. В одном документе могут быть строки со ставкой 20% и строки без НДС. Тогда простой расчёт «итог делим на 1,2» уже не работает. Нужна строковая детализация или хотя бы сверка сумм по ставкам.

Четвёртая группа, повторные документы. Один и тот же акт может прийти на почту дважды: сначала как скан, потом как нормальный PDF. Если автоматизация не проверяет номер, дату, ИНН контрагента и сумму вместе, в учёте появится дубль. Я обычно считаю дублем совпадение по четырём признакам, но оставляю ручное подтверждение, когда совпали три из четырёх. Например, номер и сумма совпали, а дата отличается на один день из-за ошибки распознавания.

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

Таблица: четыре подхода к обработке первички

Для примера: если в день приходит 50 сканов по 2 страницы, бухгалтеру приходится просмотреть около 100 страниц и перенести минимум 300–500 полей, если считать дату, номер, две стороны, суммы и налог. Даже при темпе 1–2 минуты на документ это превращается в заметный кусок рабочего дня. Автоматизация снимает набор полей, но не должна убирать контроль на спорных местах.

Как настроить проверку перед записью в учёт

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

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

Условный пример: в документе «УПД № 145» модель извлекла итог 236 000,00, НДС 39 333,33 и сумму без НДС 196 666,67. Арифметика сходится до копейки, ИНН поставщика проходит контрольную проверку, а контрагент найден в справочнике по ИНН и КПП. Такой документ можно отправить в очередь «готово к загрузке». Если тот же номер, дата и сумма уже есть в базе, статус меняется на «возможный дубль».

Условный пример: в акте «Услуги за март» распознана дата 31.13.2026. Формат похож на дату, но месяца 13 не существует. Хорошая система не пытается угадать «31.03.2026», а показывает оператору исходный фрагмент изображения и просит подтвердить значение.

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

Как заносить данные без ручного ввода

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

Для интеграции есть несколько обычных путей. API подходит, когда учётная система разрешает создавать документы программно и возвращает понятные ошибки. Файловый обмен удобен, если система принимает XML, CSV или другой регламентированный формат. Промежуточная таблица годится для пилота, но её легко превратить в новое место ручного труда, если не назначить владельца процесса.

Я предпочитаю запускать пилот на одном типе документа. Например, только входящие акты от постоянных поставщиков. Там меньше вариантов макета, проще собрать тестовую выборку и быстрее видно, где модель путает исполнителя и заказчика. После этого можно добавлять УПД, счета-фактуры и документы с многострочной номенклатурой.

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

Что я проверил бы перед запуском

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

Дальше я смотрю не на красивую среднюю точность, а на ошибки по классам. Отдельно даты, отдельно контрагенты, отдельно деньги. Ошибка в номере договора неприятна, но ошибка в сумме НДС опаснее. Поэтому денежные поля должны иметь самый строгий маршрут проверки.

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

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

Как бы я выстроил процесс на вашем месте

Я начал бы не с покупки инструмента, а с карты документов. Какие типы первички приходят за месяц, в каком виде, от каких контрагентов, какие поля реально нужны для учёта. Затем взял бы 30–50 обезличенных файлов для теста и разметил эталонные значения. После этого можно проверять OCR, промпты, правила валидации и способ загрузки.

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

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