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

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

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

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

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

Поэтому обновлённая архитектура состоит из шести этапов:

  1. приём и подготовка файла;
  2. распознавание текста и координат;
  3. разбор структуры страницы;
  4. извлечение нужных полей;
  5. проверка на ошибки и дубли;
  6. запись в учётную систему с журналом обработки.

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

Шаг 1. Принять скан и привести его к нормальному виду

На вход обычно попадают PDF, JPEG, PNG или TIFF. Источник может быть разным: почта, личный кабинет поставщика, сканер МФУ, мобильное фото, архив за период. Для автоматической обработки качество файла влияет сильнее, чем выбор модели на поздних этапах.

Практический минимум для сканов: 300 dpi, ровная ориентация страницы, видимые края документа, отсутствие сильной компрессии. Для фото важны другие признаки: угол съёмки меньше 10–15 градусов, ровный свет, без бликов на печати и подписи. Если в потоке 1 000 документов в месяц, даже 5% плохих изображений дают 50 ручных разборов. Это уже отдельная очередь, а не мелкая погрешность.

На этапе подготовки система обычно делает четыре операции:

  • определяет тип файла и число страниц;
  • разворачивает страницу, если она лежит боком;
  • убирает шум, тени и перекос;
  • режет многостраничный PDF на логические документы.

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

Шаг 2. Распознать текст, координаты и структуру страницы

OCR больше не ограничивается строкой «вот весь текст». Для бухгалтерских документов нужны слова, координаты, блоки, таблицы и связи между ними. Координаты помогают понять, что число «125 000,00» стоит рядом с подписью «Итого к оплате», а не внутри банковских реквизитов.

На выходе после распознавания полезно хранить не один текстовый слой, а набор объектов:

  • слово или фраза;
  • координаты на странице;
  • номер страницы;
  • уверенность распознавания;
  • тип блока: заголовок, таблица, реквизиты, подпись, печать, подвал.

Для документов с табличной частью это критично. В накладной может быть 40 строк товаров, 6 колонок и итоговая сумма внизу. Если модель «сплющит» таблицу в один абзац, потом трудно отличить цену за единицу от суммы по строке.

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

Шаг 3. Извлечь сумму, дату и контрагента

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

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

Дата тоже неоднозначна. В одном счёте может быть дата договора, дата оплаты, дата выставления, дата отгрузки и дата печати формы. Для учёта чаще нужна дата документа, а не любая дата в тексте. Хороший парсер ищет связки: «Счёт № 48 от 12.06.2026», «Акт от 31 мая 2026», «Дата составления».

Контрагент извлекается по реквизитам и названию. В российских документах ИНН обычно содержит 10 или 12 цифр, КПП, 9 цифр, расчётный счёт, 20 цифр, БИК, 9 цифр. Эти признаки помогают отличить поставщика от покупателя. Название без реквизитов ненадёжно: «Ромашка» может быть ИП, ООО, филиалом или частью адреса.

Условный пример: в счёте «ООО Ромашка» указаны две суммы, 100 000,00 без НДС и 120 000,00 с НДС, а рядом стоит фраза «Итого к оплате». Система должна взять 120 000,00, связать её с датой счёта, найти ИНН продавца в блоке реквизитов и проверить, что этот контрагент есть в справочнике.

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

Шаг 4. Проверить данные до записи в учёт

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

Базовый набор проверок выглядит так:

Поле Проверка Что ловит
Сумма формат, валюта, сумма прописью, НДС 20% или 10% лишний ноль, неверный итог, путаницу с налогом
Дата допустимый период, формат, связь с номером документа дату договора вместо даты счёта
Контрагент ИНН, КПП, справочник, расчётный счёт чужие реквизиты, опечатку OCR
Номер документа связка номер + дата + контрагент повторную загрузку того же файла
Файл хеш, размер, источник, страницы дубль вложения или старую версию

Проверка ИНН по контрольным цифрам особенно полезна: если OCR заменил «8» на «3», номер часто не проходит контроль. Для расчётного счёта проверяют длину 20 цифр и связку с БИК. Для суммы можно сравнивать число и текст прописью: «Двенадцать тысяч» не должно превращаться в 120 000.

Для примера: документ распознан с уверенностью 0,94, сумма совпала с суммой прописью, ИНН прошёл контроль, контрагент найден в справочнике, дубль не обнаружен. Такой документ можно отправлять в автозапись. Если уверенность по сумме 0,72, а в файле есть две похожие строки «Итого» и «Всего с НДС», лучше показать оператору только спорный фрагмент, а не весь документ.

Шаг 5. Настроить пороги ручной верификации

Полная автоматизация с первого дня редко бывает разумной. Безопаснее задать пороги уверенности и постепенно расширять автозапись.

Рабочая схема может быть такой:

  • 0,97–1,00, запись без ручной проверки, если все правила пройдены;
  • 0,80–0,96, очередь верификации с подсветкой спорных полей;
  • ниже 0,80, ручной ввод или повторный запрос файла;
  • любой конфликт с дублем, всегда на проверку;
  • новый контрагент, проверка ответственным сотрудником.

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

Гипотетический пример: компания из сферы оптовой торговли, ~40 сотрудников, обрабатывает 3 000 входящих документов в месяц. Если 65% документов проходят автозапись, 25% требуют проверки одного поля, а 10% уходят в ручной разбор, оператор видит 1 050 задач вместо 3 000 полных вводов. Экономия появляется не из красивого интерфейса, а из сокращения числа полей, которые человек набирает с нуля.

Шаг 6. Передать запись в учётную систему

Когда поля извлечены и проверены, их нужно занести в систему учёта. Технически это делают через API, импорт CSV или XML, очередь сообщений либо промежуточную таблицу. Выбор зависит от того, что поддерживает конкретная учётная платформа.

Минимальная запись обычно содержит:

  • тип документа;
  • номер;
  • дату;
  • контрагента;
  • ИНН и КПП;
  • сумму;
  • ставку и сумму НДС, если есть;
  • ссылку на исходный файл;
  • статус проверки;
  • автора или сервис, который создал запись;
  • время обработки.

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

Журнал обработки хранит, кто и когда исправил поле. Это помогает при споре: видно, что OCR прочитал сумму как 58 900, оператор исправил на 58 800, а причина была в размытой копейке на скане. Без такого журнала автоматизация быстро превращается в чёрный ящик.

Какие инструменты нужны для такой схемы

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

Не стоит заставлять одну модель делать всё. Распознавание изображения, поиск таблиц, проверка ИНН и запись через API решают разные задачи. Чем яснее границы модулей, тем проще тестировать качество. Если поменялся OCR, не нужно переписывать правила дублей. Если обновили справочник контрагентов, не нужно трогать извлечение дат.

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

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

План внедрения на 14 дней

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

День 1–2: собрать 200–500 типовых документов за последние месяцы. Нужны хорошие и плохие сканы, разные поставщики, документы с НДС и без НДС, многостраничные PDF, дубли.

День 3–4: описать целевую схему данных. Например: тип, номер, дата, контрагент, ИНН, сумма, НДС, уверенность, статус, ссылка_на_файл.

День 5–7: настроить OCR и извлечение полей. На этом этапе не гонитесь за идеальным качеством. Цель, получить первую выборку ошибок.

День 8–9: добавить проверки. ИНН, формат дат, суммы, дубли, новый контрагент, расхождение с суммой прописью.

День 10–11: сделать очередь верификации. Оператор должен видеть не весь хаос, а спорное поле, фрагмент страницы и предложенное значение.

День 12–13: подключить тестовый импорт в учётную систему. Без записи в боевую базу. Проверьте 50–100 документов руками и сравните поля.

День 14: принять решение по порогам. Какие документы идут автоматически, какие требуют проверки, какие пока остаются на ручном вводе.

Для примера: если ручной ввод одного документа занимает 3–5 минут, поток в 2 000 документов в месяц даёт 100–167 часов операционной работы. Даже частичная автоматизация, которая убирает ввод половины полей, заметно меняет нагрузку на бухгалтерию и бэк-офис.

Типичные ошибки при запуске

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

Вторая ошибка, не разделять поставщика и покупателя. В счёте есть две стороны, и система должна понимать, кто выставил документ, а кто его получил. Одного названия компании мало.

Третья ошибка, сразу писать в боевую базу. Сначала нужен режим «только чтение» или тестовый импорт. Иначе вы будете искать ошибку уже в проводках, отчётах и сверках.

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

Пятая ошибка, не считать качество по полям. Общая точность «документ обработан» мало что говорит. Нужно отдельно мерить сумму, дату, контрагента, ИНН, номер, НДС. Ошибка в комментарии и ошибка в сумме имеют разную цену.

Заключение: что должно получиться после обновления процесса

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

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