Бухгалтер открывает очередную УПД, сверяет её с заказом и накладной, переносит позиции в учётную систему. Завтра таких документов будет столько же, а к концу квартала больше. Разберём пять способов справиться с этим потоком: что каждый умеет, где ломается и кому подходит.
Сколько документов проходит через компанию и где тратится время
В оптовой торговле, логистике и производстве документы идут непрерывно: УПД и счета-фактуры, товарные и транспортные накладные, счета на оплату, акты выполненных работ, заявки клиентов. Из каждого нужно взять набор полей: номер, дату, контрагента и его ИНН, позиции, количества, суммы, НДС.
Само чтение документа занимает немного. Время уходит на три вещи вокруг него. Первая: найти, к чему документ относится, то есть к какому заказу, рейсу или договору. Вторая: сверить его с другими документами по той же сделке, например количество в накладной с количеством в УПД. Третья: разобрать расхождения, написать контрагенту, дождаться исправленного файла.
Ошибка в документе редко видна в момент ввода. Она всплывает позже: при сверке взаиморасчётов с контрагентом, при закрытии квартала, при вопросе от налоговой. Исправлять её тогда приходится уже в нескольких местах сразу, а иногда просить контрагента переоформить документ.
Ещё одна проверка до разговора об ИИ: какая часть документов уже приходит через ЭДО в формализованном виде. Данные из таких файлов можно забрать напрямую, распознавать в них нечего. Автоматизация нужна для остального: сканов, фотографий, PDF и писем от тех, кто ЭДО не пользуется.
Прежде чем выбирать способ автоматизации, полезно посчитать свой поток. Сколько документов приходит в месяц, сколько у них разных форм, сколько минут сотрудник тратит на один документ вместе со сверкой. Без этих цифр сравнивать подходы не с чем.
Готово 0 из 5
Ручной ввод и Excel
Самый распространённый вариант. Сотрудник открывает файл, переносит поля в таблицу или учётную систему, сверяет глазами. Запускать ничего не нужно, а человек справится с любой формой, даже с документом, написанным от руки.
Ограничения проявляются с ростом объёма. Время обработки растёт линейно: вдвое больше документов означает вдвое больше часов. Ошибки появляются от усталости и однообразия, и найти их можно только такой же ручной проверкой. Знание о том, как обрабатывать документы конкретного поставщика, живёт в голове одного сотрудника и уходит вместе с ним.
Ручной процесс можно заметно улучшить и без ИИ: навести порядок в справочнике контрагентов и номенклатуры, договориться с крупными поставщиками об ЭДО, завести простой чек-лист сверки. Часто это первый шаг перед любой автоматизацией, потому что грязные справочники мешают любому подходу.
Когда подходит: документов немного, формы стабильные, а ошибка в одном поле стоит недорого.
OCR: распознавание текста по шаблону
OCR, оптическое распознавание символов, превращает картинку в текст. Чтобы из текста получились поля, под каждую форму настраивают шаблон: в этой области страницы номер, в этой сумма, здесь таблица позиций.
На стабильном потоке это работает хорошо. Если почти все документы приходят от нескольких постоянных поставщиков в одной и той же форме, шаблоны окупают настройку. Сложности начинаются с разнообразием. Новый контрагент со своей вёрсткой означает новый шаблон. Поставщик обновил бланк, и старый шаблон тихо начинает брать не те значения.
Отдельная проблема: плохие сканы. OCR может прочитать «8» как «3» или «0» как «О», и такую ошибку в сумме трудно заметить без сверки. Смысла документа OCR не понимает: он не отличит сумму без НДС от суммы с НДС, если шаблон этого не задал.
Когда подходит: большой поток документов немногих стабильных форм, хорошее качество файлов.
Публичные нейросети
Многие уже пробовали загрузить счёт в ChatGPT или другой публичный чат и попросить вытащить поля. На единичном документе результат часто выглядит убедительно: модель понимает смысл, не требует шаблона и справляется с разными формами.
Для рабочего процесса у этого способа три проблемы. Первая: данные. Документы содержат реквизиты контрагентов, суммы сделок, иногда персональные данные водителей и сотрудников. Загружая их в публичный сервис, компания передаёт их третьей стороне, и условия хранения определяет не она. Вторая: нет процесса. Каждый документ нужно загрузить вручную, скопировать ответ и перенести его в систему. Сверки с другими документами и журнала, кто что исправил, нет. Третья: модель может вписать правдоподобное значение, которого в документе нет, и в чате об этом ничего не скажет.
Когда подходит: разовые задачи с обезличенными документами, проверка идеи до разговора о внедрении.
Перед загрузкой документов в любой внешний сервис проверьте его условия использования и внутренние правила компании о передаче данных.
Своя разработка
Компания с сильной ИТ-командой может собрать систему сама: распознавание, извлечение полей, проверки, интеграцию с учётной системой. Плюс в полном контроле: процесс устроен ровно так, как нужно, данные не выходят за контур компании.
Минусы в сроках и в поддержке. Нужны люди, которые разбираются и в моделях, и в учёте. Нужен набор размеченных документов для проверки качества. После запуска систему придётся сопровождать: появляются новые формы, меняются модели, ломаются интеграции. Если команда занята основным продуктом, проект рискует остановиться на прототипе.
Промежуточный вариант: собрать процесс из готовых компонентов, например распознавания и языковой модели через API, и написать своими силами только правила и интеграцию. Это быстрее, но вопрос сопровождения никуда не уходит.
Когда подходит: уникальный процесс, который не ложится на готовые решения, и своя команда, готовая вести проект годами.
ИИ-извлечение с проверкой человеком
Этот подход собирает сильные стороны предыдущих. Распознавание даёт текст, языковая модель находит поля по смыслу, без жёсткого шаблона, а правила проверяют результат. Документы, в которых что-то не сходится, уходят в очередь к сотруднику. Человек работает не со всем потоком, а с исключениями.
Правила здесь важнее модели. Модель может ошибиться правдоподобно, поэтому каждый результат проходит проверки, которые не зависят от неё.
Для сотрудника это выглядит так. Документ пришёл на почту или в общую папку, система определила тип, извлекла поля и прогнала проверки. Если всё сошлось, данные уходят в учётную систему по согласованному маршруту. Если нет, документ появляется в очереди: сомнительные поля подсвечены, рядом открыт исходный файл. Сотрудник исправляет значение или подтверждает его, а каждое действие записывается в журнал.
Для запуска нужны четыре вещи: набор реальных документов для проверки, список полей с правилами для каждого, доступ к учётной системе или формат выгрузки и человек, который будет разбирать очередь исключений. Начинать лучше с одного типа документов, например входящих УПД, и расширять охват после того, как он заработал.
- Арифметика: сумма позиций равна итогу, НДС посчитан верно
- Реквизиты: ИНН проходит проверку контрольного числа, контрагент есть в справочнике
- Сверка: количество в УПД совпадает с накладной и заказом
- Разумность: дата не в будущем, цена не отличается от прошлой в разы
- Комплектность: для сделки есть все нужные документы
Сравнение подходов
| Критерий | Ручной ввод | OCR по шаблону | Публичные нейросети | Своя разработка | ИИ-извлечение с проверкой |
|---|---|---|---|---|---|
| Скорость на документ | Минуты, растёт с потоком | Быстро на знакомых формах | Быстро, но каждый файл загружают руками | Зависит от того, что построили | Быстро, человек тратит время только на исключения |
| Нестандартные формы | Человек разберётся | Нужен новый шаблон | Обычно справляется, без гарантий | Как заложено в систему | Обычно справляется, сомнительное уходит на проверку |
| Сверка с другими документами | Вручную | Только если настроили отдельно | Нет | Если построили | Входит в правила проверки |
| Где хранятся данные | У вас | Зависит от сервиса | У внешнего сервиса | У вас | Согласуется при внедрении, возможен ваш контур |
| Срок запуска | Сразу | Настройка шаблонов | Сразу | Самый долгий | Пилот на одном типе документов, потом расширение |
| Как выглядит ошибка | Опечатка, пропуск | Неверно прочитанный символ | Правдоподобное выдуманное значение | Зависит от реализации | Ловится правилами или попадает в очередь |
| Кому подходит | Малый поток | Много документов немногих форм | Разовые задачи | Уникальный процесс и своя команда | Большой разнообразный поток, дорогие ошибки |
Таблица описывает подходы в общем виде. Качество на ваших документах проверяется только на ваших документах.
Как выбрать и что измерить на пилоте
Перед выбором соберите 50-100 реальных документов, включая плохие сканы и редких поставщиков. Сравнивайте подходы на них по точности каждого поля, а не документа целиком: ошибка в комментарии и ошибка в сумме весят по-разному.
Метрики пилота стоит записать до старта, чтобы потом не подбирать их под результат.
Итог хорошего пилота звучит не «модель умная», а так: какая доля документов теперь не требует ручной работы и сколько ошибок проскочило проверки. Если доля ручной правки не снижается, автоматизация только добавляет шаг, и пилот честнее остановить.
- Если документов несколько десятков в месяц и формы привычные, оставьте ручной ввод и наведите порядок в справочниках
- Если поток большой, но почти все документы приходят в нескольких стабильных формах, начните с OCR по шаблонам
- Если нужно разово разобрать архив обезличенных файлов, хватит публичной нейросети и выборочной проверки
- Если процесс уникален и у вас есть своя ML-команда на годы вперёд, рассмотрите разработку
- Если поток большой, форм много, а ошибка в сумме или реквизитах стоит дорого, смотрите на ИИ-извлечение с правилами и очередью исключений
Готово 0 из 4
