Извлечение данных из сканов с помощью ИИ в 2026
Стендфирст: пошаговый разбор, как превратить сканы актов, счетов и накладных в проверяемую таблицу для бухгалтерии и логистики.
Сканы первички редко выглядят как аккуратная база данных. В одном письме лежит счёт в PDF, в другом, фотография накладной с телефона, в третьем, акт с печатью, который повернули на 90 градусов. Бухгалтеру нужны дата, сумма, ИНН, номер документа, контрагент и НДС. Логисту нужны номер рейса, дата отгрузки, грузополучатель, вес, маршрут и стоимость перевозки. Ручной перенос этих полей в таблицу выглядит простым, пока документов 20. На 300 сканах в месяц это уже отдельный процесс с ошибками, сверками и повторными запросами.
Я бы не строил такой процесс вокруг обещания «ИИ всё сам разберёт». Надёжнее схема с двумя слоями: нейросеть извлекает данные, человек или автоматические правила проверяют рискованные поля. В SoftChat можно прикреплять изображения и документы к сообщениям, если выбранная модель поддерживает такие вложения, а ответы удобно получать в Markdown, включая таблицы. Для регулярной работы полезны шаблоны промптов, чтобы не писать инструкцию заново для каждой пачки документов. Дальше расскажу, как собрать процесс без лишней магии: от подготовки сканов до контрольной сверки.
Где ИИ помогает в бухгалтерии и логистике
Нейросети хорошо справляются с документами, где есть повторяемые поля: счета, акты, УПД, транспортные накладные, заявки на перевозку, счета-фактуры, квитанции, спецификации. Задача не в том, чтобы «прочитать весь документ», а в том, чтобы вытащить 8–15 нужных реквизитов и сохранить их в одинаковой структуре.
Для бухгалтерии обычно нужны такие поля: номер документа, дата, контрагент, ИНН, КПП, сумма без НДС, сумма НДС, итоговая сумма, валюта, назначение платежа. Для логистики набор другой: дата погрузки, дата выгрузки, перевозчик, заказчик, маршрут, вес, количество мест, номер автомобиля, номер прицепа, ставка, номер заявки. Если смешать эти наборы в одном запросе, модель начнёт угадывать лишнее. Поэтому я разделяю сценарии по типам документов.
Если команда только начинает внедрение, сначала полезно разобраться, где нейросети экономят время в рутине, а где создают риск. Я подробно разбирал это в статье про внедрение нейросетей в рабочие процессы. Для документов главный риск простой: красиво оформленная таблица может содержать неверную дату или перепутанную сумму. Значит, проверка нужна до загрузки в учётную систему.
Модельный кейс: компания из сферы логистики, ~200 сотрудников, получает 450 сканов актов и заявок в месяц, а оператор вручную переносит 12 полей из каждого документа. Если на один документ уходит 2 минуты, получается около 15 часов чистого ввода без учёта исправлений. ИИ-первичный разбор может сократить ручную часть до выборочной проверки, но только после настройки формата, правил сверки и списка типовых ошибок.
Пошаговый процесс извлечения данных из сканов
Ниже схема, которую я использую как рабочий каркас. Она подходит и для бухгалтерии, и для логистики, меняется только список полей.
| Шаг | Что делаем | Что получаем | Где чаще всего ошибка |
|---|---|---|---|
| 1 | Сортируем документы по типам | Пачки «счета», «акты», «накладные» | В одну пачку попадают разные формы |
| 2 | Улучшаем качество сканов | Читаемые файлы без поворота и обрезки | Потерян нижний блок с суммой |
| 3 | Даём модели точную схему полей | Таблицу с фиксированными колонками | Модель добавляет лишние столбцы |
| 4 | Просим указать уверенность и спорные места | Список полей для ручной проверки | Неверная уверенность при плохом скане |
| 5 | Сверяем арифметику и справочники | Ошибки видны до импорта | ИНН похож на номер счёта |
| 6 | Загружаем в таблицу или учётный контур | Подготовленный набор строк | Дубли документов без проверки номера |
Первый шаг скучный, но он сильнее влияет на точность, чем длинный промпт. Счёт и транспортная накладная похожи только внешне: у них разные смысловые поля. Если отправить модели смешанную папку и попросить «извлечь всё важное», результат будет похож на пересказ, а не на таблицу для учёта.
Второй шаг, качество сканов. Нужны ровная ориентация, читаемые цифры, видимые края, без бликов на печати и подписи. Для фотографий с телефона нормальная практика, переснять документ при дневном свете, положить лист на контрастную поверхность, держать камеру строго сверху. Разрешение 150–300 точек на дюйм обычно достаточно для машинного чтения печатного текста. Если документ многостраничный, страницы лучше не перемешивать: имя файла «акт_123_стр1» снижает риск путаницы.
Третий шаг, схема ответа. Я почти никогда не прошу «найди данные». Я прошу вернуть таблицу с конкретными колонками. Например: «тип документа», «номер», «дата», «контрагент», «ИНН», «сумма с НДС», «НДС», «валюта», «поля с низкой уверенностью», «комментарий». Если поле не найдено, модель должна писать «не найдено», а не придумывать значение из соседнего текста.
Подробнее о том, как получать не красивый черновик, а проверяемый результат, я писал в материале про нейросеть для генерации текста и проверку ответа. С документами логика такая же: хороший запрос задаёт формат, критерии качества и запрет на догадки.
Пример промпта для сканов счетов и актов
Ниже промпт можно сохранить как шаблон и менять список полей под тип документа. В SoftChat для таких повторяемых инструкций доступны шаблоны промптов, поэтому бухгалтеру не придётся каждый раз собирать длинное ТЗ с нуля.
Ты работаешь с прикреплёнными сканами первичных документов.
Извлеки данные только из видимого текста документа.
Не угадывай значения. Если поле не читается или отсутствует, напиши «не найдено».
Верни результат таблицей Markdown со столбцами:
1. Имя файла
2. Тип документа
3. Номер документа
4. Дата документа в формате ДД.ММ.ГГГГ
5. Контрагент
6. ИНН контрагента
7. Сумма без НДС
8. НДС
9. Сумма с НДС
10. Валюта
11. Поля для ручной проверки
12. Комментарий
После таблицы проверь:
, сумма без НДС + НДС = сумма с НДС;
, дата похожа на дату документа, а не на дату договора;
, ИНН состоит из 10 или 12 цифр;
, нет ли дублей по номеру документа и сумме.
Для логистики я меняю середину запроса. Вместо НДС и валюты прошу маршрут, дату погрузки, дату выгрузки, перевозчика, заказчика, вес, ставку, номер автомобиля и номер заявки. Отдельным столбцом оставляю «сомнение модели». Это дисциплинирует проверку: оператор смотрит сначала на строки, где есть проблемы, а не перечитывает всё подряд.
Как проверять ошибки до импорта
ИИ-извлечение нельзя считать финальным бухгалтерским действием. Его роль, подготовить черновую структуру. Дальше нужны проверки, часть из них можно сделать простыми формулами в таблице.
Самые полезные проверки для бухгалтерии:
- Арифметика: сумма без НДС плюс НДС равна сумме с НДС. Допуск в 1 копейку иногда нужен из-за округлений.
- Формат ИНН: 10 цифр для организации, 12 цифр для физлица или ИП.
- Дата: не должна быть в будущем, если речь о закрывающих документах за прошлый период.
- Дубли: совпадают номер документа, контрагент и сумма.
- Валюта: если договор в рублях, а модель вернула «USD», строку надо проверить вручную.
Для логистики проверки другие. Дата выгрузки не должна быть раньше даты погрузки. Вес не должен прыгать с 20 тонн до 200 тонн из-за ошибочного нуля. Номер машины имеет ожидаемый формат, хотя региональные и международные варианты могут отличаться. Ставка по маршруту должна попадать в нормальный диапазон, который знает отдел перевозок.
Условный пример: в пачке «заявки_май» из 120 документов модель вернула 9 строк с пометкой «дата не читается» и 4 строки, где ставка похожа на номер заявки. Такие строки не надо импортировать автоматически. Их проще отдать оператору отдельным списком, чем потом искать ошибку в закрытии месяца.
Практика похожа на любую автоматизацию офисной рутины: сначала фиксируем повторяемый сценарий, потом добавляем контрольные точки. Если хочется шире посмотреть на бытовые и рабочие сценарии, пригодится разбор нейросетей и чат-ботов для повседневных задач.
Что делать с плохими сканами
Плохой скан не всегда надо отправлять в работу. Если половина суммы закрыта печатью, а дата смазана, модель может честно написать «не найдено». Это нормальный результат. Хуже, когда система пытается заполнить пустоту правдоподобным числом.
Я использую простое правило: если критичное поле не читается глазами за 3–5 секунд, документ идёт на пересканирование или ручной ввод. К критичным полям относятся сумма, дата, контрагент, ИНН, номер документа. Для логистики сюда добавляются маршрут, дата погрузки, дата выгрузки, ставка и вес.
Для примера: фотография накладной под углом может дать верный контрагент и неверную сумму, потому что нижняя строка «Итого» обрезана на 2–3 миллиметра. В таком случае лучше не усиливать промпт, а получить нормальный файл. Нейросеть не должна восстанавливать бухгалтерский документ по догадке.
В SoftChat можно вести разговор с потоковой выдачей ответа, поэтому удобно сначала попросить модель разобрать 3–5 тестовых файлов и посмотреть, какие поля вызывают сомнения. Если формат подходит, тот же шаблон запроса применяют к следующей пачке. Для более устойчивой роли можно использовать сохранённого ассистента в текущем чате: например, настроить его как помощника по извлечению реквизитов, без привязки к конкретному контрагенту.
Таблица для контроля результата
После извлечения я советую держать отдельный столбец «статус проверки». Он нужен даже в маленькой команде. Без статуса быстро непонятно, какие строки уже просмотрены бухгалтером, какие ждут пересканирования, а какие готовы к загрузке.
| Статус | Когда ставить | Действие |
|---|---|---|
| Готово | Все поля читаются, арифметика сходится | Можно передавать дальше |
| Проверить | Есть сомнение по 1–2 полям | Оператор сверяет со сканом |
| Пересканировать | Не видно сумму, дату или номер | Запросить новый файл |
| Дубль | Совпали номер, сумма и контрагент | Сравнить с уже внесённой строкой |
| Ручной ввод | Документ нестандартный или рукописный | Обработать без автоматизации |
Такая таблица кажется избыточной на первых 30 документах. На первых 300 она спасает от хаоса. Особенно когда сканы приходят из разных каналов, от водителей, менеджеров, подрядчиков и бухгалтерии контрагента.
Как внедрять без риска для учёта
Я бы начинал с пилота на одном типе документов. Например, только счета от поставщиков или только транспортные заявки за последний месяц. Берём 50–100 файлов, вручную знаем правильный результат, прогоняем через один шаблон, считаем ошибки по полям. Не общую «точность», а отдельно: дата, сумма, ИНН, контрагент, номер документа. Так видно, где модель полезна, а где нужен человек.
Условный пример: на 80 счетах дата и номер читаются почти всегда, а ИНН часто путается с КПП из-за плотной шапки документа. Значит, в промпт добавляем правило «ИНН ищи рядом с подписью ИНН, КПП не записывай в колонку ИНН», а в проверку добавляем длину 10 или 12 цифр. Это лучше, чем менять весь процесс.
В обучении сотрудников помогает тот же подход, что и в саморазвитии: не давать нейросети роль «автора истины», а использовать её как тренажёр и ускоритель проверки. Об этом я отдельно писал в статье про нейросети в образовании и саморазвитии. Для бухгалтерии эта мысль особенно полезна: человек остаётся владельцем решения, модель готовит материал для проверки.
Если выбирать между голосовым помощником, браузерной нейросетью и рабочим чатом, смотрите на формат задачи. Разовые вопросы можно решить почти где угодно. Пачки документов требуют вложений, истории, шаблонов и повторяемого формата ответа. Близкий принцип выбора я разбирал в сравнении голосового помощника и нейросети в браузере.
Заключение
На вашем месте я бы не начинал с полной автоматизации первички. Я бы взял один тип документа, описал 10–12 полей, подготовил 50 проверенных сканов и сделал эталонную таблицу. Потом прогнал бы пачку через ИИ, отметил ошибки по каждому полю и настроил правила проверки: арифметика, формат ИНН, даты, дубли, диапазоны сумм или ставок.
Если после пилота видно, что оператор исправляет отдельные поля, а не перепечатывает документ целиком, процесс можно расширять. Если половина файлов уходит на пересканирование, проблема не в промпте, а во входящем потоке документов. ИИ хорошо ускоряет понятную рутину. Он плохо лечит хаос, где никто не договорился, какие поля нужны и кто отвечает за финальную проверку.