Распознавание первичных документов: автоввод данных с накладных и счетов (vs ABBYY и 1С)

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

Распознавание первичных документов забирает эту рутину: документ попадает в систему сканом или фото, алгоритм вытаскивает поля и отдаёт их в учётную систему на проверку. Человек не вбивает, а сверяет. Звучит просто, но дьявол, как обычно, в деталях — в точности по конкретным полям и в том, куда при этом уходят ваши данные.

Что вообще такое первичка для OCR

Первичные документы — это накладные ТОРГ-12, универсальные передаточные документы, счета на оплату, счета-фактуры, акты выполненных работ. Для распознавания у них есть приятное свойство: структура полуформализованная. Это в основе своей задача OCR — оптического распознавания, одного из базовых сценариев машинного зрения, только заточенного под деловой документ.

Есть устойчивый набор полей, которые надо вытащить:

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

Сложность в том, что форма у каждого поставщика своя. Один шлёт аккуратный PDF из 1С, другой — мятый скан факсового качества, третий — фото со смартфона под углом и с бликом. Хорошее распознавание первички — это не «прочитать буквы», это понять структуру конкретного документа и разложить текст по смыслу полей, даже когда вёрстка нестандартная.

Точность считают по полям, а не «в среднем»

Когда вендор говорит «точность 98 процентов», спросите — по чему. Усреднённая цифра обманчива, потому что поля очень разные по сложности.

Реалистичная картина по типам полей выглядит примерно так:

• ИНН, КПП, номер и дата документа, итоговые суммы. Самые надёжные. Это короткие структурированные поля, часто с проверяемым форматом — ИНН можно валидировать по контрольной цифре, дату по формату. Здесь точность высокая, и ошибки почти всегда отлавливаются автоматически.
• Числовая табличная часть — количество, цена, сумма. Здесь сложнее: длинные таблицы, мелкий шрифт, сливающиеся строки. Но числа спасает арифметика — количество умножить на цену должно дать сумму, строки должны складываться в итог. Несходящуюся строку система сама подсвечивает на проверку.
• Наименования товаров. Самое тяжёлое поле. Длинные, нестандартные, с сокращениями, артикулами, латиницей вперемешку с кириллицей. Тут больше всего ручных правок, и честный вендор это не прячет.

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

On-premise против облака и встроенного в 1С

Дальше — развилка, которая для многих важнее точности. Где физически обрабатывается документ.

Облачные сервисы распознавания удобны: загрузил документ через API, получил структуру. Но накладная — это коммерческая тайна: ваши поставщики, цены закупки, объёмы, контрагенты. При облачной обработке всё это уходит на чужие серверы, нередко за пределы контура и иногда за пределы страны. Для многих компаний и госзаказчиков это само по себе стоп-фактор, помимо вопроса 152-ФЗ по персональным данным в документах.

Встроенное в 1С распознавание есть, и для типовых аккуратных документов его хватает. Но оно заточено под свои форматы, тяжелее даёт мятые сканы и фото «как есть», и его сложно настроить под нестандартную вёрстку конкретного поставщика. Это удобная базовая опция, а не универсальный движок.

On-premise распознавание — когда движок стоит на вашем сервере внутри контура. Документ не покидает периметр компании. Это главный аргумент для тех, у кого договоры с условием неразглашения, гостайна по соседству или просто принципиальная позиция «закупочные цены наружу не уходят». Минус честный — это ваш сервер, ваше обновление, ваша поддержка, а не «оплатил подписку и забыл». Логика та же, что и в споре про облачное хранилище для видео: удобство облака против контроля над данными в своём контуре.

Выбор тут не «что лучше вообще», а «что важнее для вас» — простота облака или то, что данные не уходят наружу.

Интеграция с учётной системой — где живёт реальная польза

Распознавание само по себе бесполезно, если результат снова вбивают руками. Вся ценность — в том, что распознанные поля попадают прямо в учётную систему как черновик документа.

Сценарий, к которому стоит стремиться:

1. Документ приходит — скан с МФУ, PDF из почты, фото с телефона кладовщика.
2. Движок распознаёт поля и сопоставляет позиции с номенклатурой в базе: «Болт М8х40 оц.» из накладной находит ту же позицию в справочнике.
3. В учётной системе создаётся черновик поступления с подставленными полями.
4. Бухгалтер открывает черновик, глазами сверяет подсвеченные сомнительные места, проводит документ.

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

Где первичка пересекается с остальной видеоаналитикой

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

Честно: где OCR первички буксует

Никакого волшебства. Границы у метода вполне конкретные.

Работает хорошо:

• Типовые формы ТОРГ-12, УПД, счёт-фактура нормального качества — скан или ровный PDF.
• Структурированные поля с возможностью проверки: ИНН, даты, суммы, арифметика таблицы.
• Большой однородный поток документов, где окупается настройка под частых поставщиков.

Работает плохо или требует ручной доводки:

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

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

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