ИИ читает счета: распознавание и ввод в учёт в 2026
Обновлено в июне 2026: я переработал статью под свежую практику обработки документов, добавил этапы контроля качества, разбор моделей и схему интеграции с учётными системами.
Автоматическое чтение счетов выглядит просто только на демонстрации: загрузили скан, получили сумму, дату и контрагента, запись появилась в учёте. В реальном процессе между этими точками лежат качество изображения, распознавание текста, извлечение реквизитов, проверка против справочников, журнал ошибок и безопасная передача в ERP или бухгалтерскую систему. Я обновил материал именно с этой оптикой: меньше общих слов про «нейросеть всё поймёт», больше инженерных шагов, по которым можно оценить проект до закупки сервиса или разработки своего контура.
Что изменилось в обновлённой версии
В старых описаниях автоматизации счетов часто смешивали три разных задачи: OCR, извлечение полей и бухгалтерскую проверку. Сейчас я разделяю их жёстче. OCR превращает картинку в текстовые фрагменты с координатами. Модель извлечения связывает фрагменты со смыслом: где дата, где сумма, где ИНН, где номер счёта. Правила контроля проверяют результат: сумма без НДС сходится с НДС и итогом, контрагент есть в справочнике, дата попадает в допустимый период.
В 2026 году типовой поток уже редко строят на одном алгоритме. Обычно используют связку: предобработка изображения, OCR, классификация документа, извлечение сущностей, постпроверка, отправка результата через API или файл обмена. Для сканов с печатями и перекосом хватает классического OCR с хорошей предобработкой. Для фото с телефона, многостраничных PDF и нестандартных шаблонов подключают современные ИИ-модели, которые умеют сопоставлять текст, расположение блоков и контекст.
Если вы только начинаете внедрение, советую сначала прочитать материал о том, как внедрять нейросети в рабочие процессы без хаоса. Автоматизация счетов ломается не на модели, а на границе между бухгалтерией, ИТ и владельцем процесса.
Как выглядит полный конвейер обработки счёта
Рабочий конвейер я делю на семь этапов.
- Получение документа. Счёт приходит из почты, личного кабинета поставщика, сканера, папки обмена или формы загрузки.
- Нормализация файла. PDF разбирается на страницы, изображения приводятся к единому формату, проверяется размер, ориентация и читаемость.
- Предобработка. Убирается шум, выравнивается наклон, повышается контраст, страницы режутся на области.
- OCR. Система получает текст, координаты слов и уверенность распознавания.
- Извлечение полей. Модель ищет дату, номер счёта, сумму, валюту, контрагента, ИНН, КПП, НДС, назначение платежа.
- Валидация. Результат сверяется с арифметикой, справочниками, договором, дублями и периодом учёта.
- Запись в учёт. Подготовленная структура уходит в ERP, бухгалтерскую систему или очередь ручной проверки.
Для примера: если на счёте указаны сумма 120 000 рублей, НДС 20 000 рублей и сумма без НДС 100 000 рублей, арифметическая проверка проходит. Если OCR прочитал «120 000» как «12 000», контроль НДС сразу покажет расхождение. Такая проверка стоит дешевле, чем поиск ошибки после оплаты.
OCR: почему качество скана решает половину задачи
OCR хорошо работает на документах с разрешением около 300 DPI, ровным фоном и контрастным текстом. Проблемы начинаются с фото под углом, серых копий, штампов поверх реквизитов, таблиц с тонкими линиями и сжатых изображений из мессенджеров. На этом этапе нейросеть ещё не «понимает бухгалтерию», она получает сырьё.
Я обычно смотрю на четыре показателя: долю нечитаемых символов, среднюю уверенность OCR, число найденных строк и сохранение координат. Если координаты потеряны, модель хуже понимает, что «Итого» относится к сумме справа, а не к произвольному числу внизу страницы.
Алгоритмы компьютерного зрения помогают до OCR. CNN-подходы применяют для улучшения изображения и классификации областей. YOLO-подобные детекторы подходят для поиска таблиц, печатей, подписей, QR-кодов и блоков реквизитов. LSTM-подходы исторически часто встречались в распознавании последовательностей символов, особенно там, где важен порядок текста. Сейчас эти методы нередко работают внутри готовых OCR-движков, а пользователь видит только итоговый текст и оценку уверенности.
Извлечение суммы, даты и контрагента
После OCR остаётся самая интересная часть: понять, какие фрагменты текста являются реквизитами. Регулярные выражения помогают найти дату по шаблонам вроде «25.06.2026» или «25 июня 2026». Но контрагент редко живёт в таком аккуратном виде. Он может быть написан как полное юридическое лицо, сокращённое название, бренд в шапке или строка в банковских реквизитах.
Для извлечения используют несколько слоёв:
| Поле | Как ищется | Типичная проверка |
|---|---|---|
| Дата счёта | шаблон даты, близость к словам «счёт», «от» | не позже текущей даты, не за закрытый период |
| Сумма | числа рядом с «итого», «к оплате», «всего» | сверка с НДС и суммой строк |
| Контрагент | ИНН, КПП, название, банковские реквизиты | сверка со справочником поставщиков |
| Номер счёта | шаблон после «№» или «номер» | проверка дублей по контрагенту и дате |
| Валюта | знак, код, текстовое обозначение | соответствие договору или настройкам учёта |
Современные ИИ-модели полезны там, где документ отличается от шаблона. Например, слово «Итого» может относиться к промежуточному блоку, а финальная сумма будет рядом с «Всего к оплате». Модель учитывает соседние слова и расположение на странице. Но я не оставляю такие решения без правил: сумма, контрагент и дата должны проходить отдельную проверку.
Если команда пишет промпты для проверки извлечённых данных, полезна статья про точные запросы к нейросетям и промптинг. В этой задаче плохой запрос часто звучит как «найди сумму», а рабочий запрос задаёт формат ответа, признаки поля, порядок проверки и сценарий отказа.
Проверка ошибок: где автоматизация экономит больше всего времени
Главная ценность проекта не в том, что OCR перепечатал текст. Экономия появляется, когда система сама отсекает типовые ошибки и оставляет человеку только спорные случаи. Проверки обычно делятся на арифметические, справочные и процессные.
Арифметика проста: итог равен сумме строк, НДС соответствует ставке, копейки не потеряны при округлении. Справочные проверки сложнее: контрагент должен существовать в базе, ИНН не должен конфликтовать с названием, банковский счёт должен совпадать с карточкой поставщика. Процессные проверки зависят от регламента: нельзя провести счёт за закрытый месяц, нельзя принять дубль с тем же номером и контрагентом, нельзя отправить счёт на оплату без договора или заявки.
Условный пример: компания из сферы оптовой торговли, ~80 сотрудников, получает 1 500 входящих счетов в месяц. Если вручную на первичную проверку одного счёта уходит 3 минуты, это 75 часов бухгалтерского времени в месяц. Автоматизация не убирает контроль полностью, но может перенести большую часть времени с перепечатки реквизитов на разбор исключений.
Мне нравится правило «двух порогов». Если уверенность извлечения выше 95 процентов и все проверки пройдены, запись уходит дальше автоматически. Если уверенность ниже 80 процентов или есть расхождение по справочнику, документ попадает в очередь проверки. Зона между этими значениями зависит от риска: для внутренней аналитики можно быть смелее, для платежей нужен более строгий режим.
Как данные попадают в учётную систему
Запись в учёт обычно делается одним из трёх способов: через API, через файл обмена или через промежуточную очередь. API удобен для оперативной загрузки и обратной связи: система сразу получает идентификатор созданного документа или текст ошибки. Файл обмена проще внедрить в старом контуре, где прямой доступ к базе запрещён. Очередь подходит для процесса с ручным подтверждением: ИИ готовит карточку, бухгалтер проверяет и нажимает «провести».
Для примера: для 1С часто проектируют промежуточную структуру с полями «контрагент», «дата», «номер», «сумма», «ставка НДС», «договор», «статья затрат» и «исходный файл». Для SAP-подобных ERP логика похожа, но обычно строже описываются статусы, права доступа и журналирование. Это не вопрос моды, а вопрос аудита. Через полгода после внедрения понадобится понять, кто и на основании какого распознавания создал документ.
Без журнала событий такую систему нельзя считать готовой. Нужно хранить исходный файл, версию результата OCR, извлечённые поля, уверенность, список проверок, финальное действие и пользователя, который подтвердил спорный документ. Если модель или правила обновятся, старые решения должны оставаться объяснимыми.
Где здесь место SoftChat
SoftChat не надо представлять как готовую бухгалтерскую интеграцию, если речь идёт о прямой записи счетов в ERP. Такая интеграция проектируется отдельно: с доступами, форматами обмена, правами и журналами. Зато чатовая среда полезна на этапе проектирования правил, тестирования промптов и разбора спорных документов.
В SoftChat можно вести диалоги с разными моделями и переключать модель по разговору, хранить историю бесед по организации, использовать системные промпты, пользовательских ассистентов и шаблоны запросов. Если выбранная модель поддерживает нужный тип вложений, к сообщению можно прикладывать документы и изображения. Для команды это удобный способ собрать типовые инструкции: как извлечь реквизиты, как объяснить ошибку бухгалтеру, как сформировать JSON для передачи разработчику. В веб-чате есть потоковая выдача ответа, поэтому длинный разбор документа виден по мере генерации, без ожидания полного финала.
Практический сценарий такой: бухгалтер или аналитик берёт 20 обезличенных счетов, формулирует правила извлечения, проверяет ответы модели, уточняет промпт и передаёт разработчику структуру полей. Для похожих задач можно использовать подходы из статьи про нейросеть для генерации текста и проверку результата, потому что здесь тоже важны формат, критерии качества и повторяемость.
Калибровка на исторических данных
Перед запуском я бы не доверял системе, которую проверили на десяти красивых PDF. Нужна выборка из реальных документов: хорошие сканы, плохие фото, поставщики с разными шаблонами, счета с НДС и без НДС, счета в валюте, дубли, исправленные версии. Чем шире выборка, тем раньше всплывут неприятные случаи.
Минимальный тестовый набор для пилота обычно включает 200–500 документов. Это не магическое число, а практичный диапазон: на нём уже видны повторяющиеся проблемы, но разметка ещё не превращается в отдельный проект на месяцы. Документы размечают вручную: дата, номер, сумма, валюта, контрагент, ИНН, НДС, статус проверки. Затем сравнивают результат системы с эталоном.
Метрики лучше считать по каждому полю отдельно. Точность суммы может быть 98 процентов, а точность контрагента 87 процентов, и средняя цифра скроет проблему. Для платежного процесса поле «сумма» критичнее, чем поле «комментарий». Поэтому пороги принятия должны быть разными.
Стресс-тестирование и антиошибки
Стресс-тест нужен до промышленного запуска. Я проверяю документы с поворотом на 2–5 градусов, низким контрастом, печатью поверх суммы, несколькими итогами в таблице, двумя юридическими лицами на странице, пустым НДС, валютной суммой и сканом второй копии того же счёта. Отдельно надо проверять документы, где контрагент в шапке отличается от получателя платежа в банковском блоке.
Генеративные модели иногда уверенно заполняют поле, которого нет в документе. Для бухгалтерии это опаснее, чем честный отказ. Поэтому в промптах и правилах я задаю явное поведение: если поле не найдено, вернуть null, а не угадывать. Для чисел нужно хранить исходный фрагмент текста и нормализованное значение. Например, «1 234,50» превращается в число 1234.50, но рядом сохраняется строка-источник.
Ещё один приём — независимая проверка. OCR дал текст, модель извлекла сумму, правило пересчитало итог по строкам, справочник подтвердил контрагента. Если хотя бы один слой спорит с остальными, документ не должен проходить тихо.
Что считать успешным внедрением
Успех не равен «люди больше не смотрят счета». Для большинства компаний здоровая цель звучит иначе: 60–80 процентов типовых документов проходят без ручного ввода, спорные случаи попадают в понятную очередь, все действия протоколируются, бухгалтер видит причину отказа. Такой результат уже меняет экономику процесса.
Гипотетический пример: компания из сферы услуг, ~120 сотрудников, получает 900 счетов в месяц и задаёт целевой автопроход 70 процентов. Тогда 630 документов могут уходить дальше после проверок, а 270 остаются человеку. Если ручная обработка занимала 4 минуты на документ, потенциально освобождается 42 часа ввода в месяц. Реальная экономия будет ниже из-за контроля, обучения и поддержки, но порядок величины становится понятным до старта проекта.
Я бы оценивал внедрение по пяти показателям: доля автопрохода, точность критичных полей, среднее время обработки, число ошибок после проведения и доля документов, отправленных на ручную проверку по понятной причине. Последний показатель часто недооценивают. Если система пишет «ошибка распознавания», бухгалтер снова тратит время на расследование. Если пишет «сумма НДС не сходится с итогом на 2 000 рублей», решение принимается быстрее.
Заключение, что обновлено в этой версии
Обновлённая версия статьи делает акцент на полном контуре: от скана до записи в учёт и аудита результата. ИИ в этой задаче полезен не как волшебная кнопка, а как набор слоёв: зрение, OCR, извлечение полей, правила, справочники и интеграция. Чем точнее описаны исключения, тем меньше ручной работы останется после запуска.
Если проектировать такую систему с нуля, я начинаю не с выбора модели, а с карты процесса: откуда приходят счета, какие поля нужны, какие ошибки критичны, кто подтверждает спорные документы и как запись попадает в учёт. После этого можно тестировать OCR, промпты, правила и интеграцию. Так автоматизация становится управляемой: бухгалтерия получает меньше перепечатки, ИТ получает понятные требования, бизнес видит измеримый результат.