«Распознать текст» и «провести документ» — две разные задачи, и между ними лежит основная часть работы. Скан чека, накладной или акта нужно превратить в набор реквизитов, сверить со справочниками, проверить арифметику и только потом записать в 1С. Ниже — разбор конвейера, который в российской практике реально работает на потоке, а не в демо.

Почему обычный OCR не решает задачу

Движки вроде Tesseract или PaddleOCR выдают текст, но не отвечают на вопрос «где здесь номер УПД и сумма НДС». На сканах с печатями, факсимиле, рукописными подписями и поворотом на 1–3 градуса качество падает, а табличные формы вроде ТОРГ-12 распознаются построчно без привязки к колонкам. В итоге оператор всё равно перебирает результат руками, и экономия времени стремится к нулю.

Предобработка: дешёвый шаг с высокой отдачей

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

Извлечение реквизитов: гибридный подход

На практике лучше всего работает связка: детекция зон layout-моделью, OCR по ним и извлечение полей моделью, дообученной на ваших документах. Шаблоны по координатам дают высокую точность на типовых формах конкретных поставщиков, но ломаются при малейшем сдвиге макета. Приватная LLM поверх OCR-текста хорошо вытягивает реквизиты из нестандартных актов и писем, а RAG по внутренней базе помогает корректно интерпретировать формулировки.

Сопоставление со справочниками 1С

Самая недооценённая часть — матчинг. «ООО "Ромашка"», «Ромашка ООО» и «ООО Ромашка ТД» должны сойтись в один элемент справочника контрагентов, а «Болт М8х40 оцинк.» — в нужную позицию номенклатуры. Здесь работают нормализация строк, ИНН и КПП как жёсткий ключ, нечёткое сравнение и эмбеддинги, а спорные случаи уходят на подтверждение человеку. Без этого этапа автоматизация даёт дубли и мусор в справочниках, который потом чистится месяцами.

Контроль перед загрузкой

Перед записью в 1С документ должен пройти проверки: суммы по строкам против итога, НДС по ставкам, дата в пределах периода, соответствие договору и статусу контрагента. Расхождения — не сбой системы, а сигнал: их логируют и показывают оператору вместе с фрагментом скана. Такой контроль ловит и ошибки распознавания, и реальные проблемы в документе поставщика.

Как это попадает в 1С

Вариантов три: прямая загрузка через HTTP- или OData-сервисы, обмен JSON/XML с внешней обработкой и запись через API типовых интеграций в 1С:Бухгалтерии, 1С:УТ или 1С:ERP. Для чеков есть отдельная ветка — данные из ОФД по QR-коду и номеру фискального документа часто надёжнее, чем распознавание бумажной копии. Если поставщик уже отправляет УПД через ЭДО (Диадок, СБИС), OCR вообще не нужен: берите структурированный XML.

Что считать результатом

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

Практические шаги

Начните с одного типа документа и одного участка — например, входящие накладные в конкретном филиале. Соберите 300–500 реальных сканов, разметьте поля и посчитайте baseline по ручной обработке. Дальше — пилот с замером метрик, и только затем расширение на акты, счета и чеки.

Как мы можем помочь

Мы в АПС проектируем и внедряем такие конвейеры целиком: приватные LLM и OCR-модели на вашем контуре, матчинг со справочниками, валидацию и интеграцию с 1С и CRM. Начинаем с аудита документопотока и расчёта экономики, затем собираем пилот на ваших сканах. Обсудить проект