ИИ для бухгалтерии: извлечение данных из сканов в 2026
Разбираю практическую схему: от скана счёта или акта до проверки реквизитов и передачи данных в учётную систему.
Ручной ввод первички кажется простой операцией, пока документов десять в неделю. Когда поток растёт до сотен счетов, актов, накладных и чеков, бухгалтерия начинает тратить часы на однотипные действия: открыть файл, найти дату, сумму, ИНН, номер документа, проверить НДС, перенести всё в учётную систему. Ошибка в одной цифре может уехать дальше, в оплату, сверку или налоговый отчёт.
Я смотрю на автоматизацию бухгалтерии через призму процесса, а не модного термина. Нейросеть здесь не заменяет бухгалтера. Она берёт на себя скучный участок, где человек быстро устаёт: распознавание текста, поиск полей, первичную проверку и подготовку структурированных данных. Человек остаётся на контроле спорных документов, нестандартных договоров, расхождений и правил учёта.
Если вы только выстраиваете работу с нейросетями в компании, полезно сначала описать повторяемые сценарии. Я отдельно разбирал этот подход в материале про внедрение нейросетей в рабочие процессы: без понятного маршрута даже хорошая модель превращается в дорогую игрушку.
Где ИИ реально помогает бухгалтерии
В бухгалтерской первичке есть несколько типов документов, которые хорошо подходят для автоматизации:
- счета на оплату;
- акты выполненных работ;
- товарные накладные;
- универсальные передаточные документы;
- кассовые чеки;
- банковские выписки в виде файлов и сканов;
- договоры с типовыми реквизитами.
Общее между ними одно: внутри есть повторяющиеся поля. Например, дата документа, номер, сумма, валюта, контрагент, ИНН, КПП, ставка НДС, итог с налогом и без него. Часть данных лежит в таблицах, часть в шапке, часть в подвале рядом с подписью или печатью.
Обычный OCR распознаёт текст на картинке. Этого мало. Если на скане написано 125 000,00, система должна понять, это сумма к оплате, сумма без НДС, номер договора или часть банковского счёта. Документный ИИ добавляет второй слой: анализ расположения текста, связей между подписями и значениями, формата чисел, контекста строк и таблиц.
Для примера: если рядом с числом 24 000,00 стоит подпись «НДС 20%», а ниже указано «Итого к оплате 144 000,00», модель должна вернуть не одно найденное число, а набор полей: сумма без налога, сумма налога, итоговая сумма. Это уже не распознавание картинки, а извлечение смысла из документа.
Маршрут документа: от скана до учётной записи
Типовая схема выглядит так: документ попадает в систему, проходит распознавание, поля извлекаются, значения проверяются, а затем данные передаются в учётную систему через API, файл обмена или роботизированный сценарий. В SoftChat можно разбирать отдельные документы в чате, прикрепляя изображения и файлы к сообщению, но передачу в бухгалтерскую систему я описываю как общий архитектурный приём, а не функцию продукта.
flowchart TD
A[Скан или PDF] --> B[Распознавание текста]
B --> C[Поиск полей: дата, сумма, контрагент]
C --> D[Проверка правил]
D --> E{Есть расхождения?}
E -->|Да| F[Очередь на ручную проверку]
E -->|Нет| G[Передача в учётную систему]
F --> H[Исправление и обучение правил]
H --> D
На практике я делю процесс на пять шагов.
Первый шаг, приём документа. Файл приходит из почты, мессенджера, личного кабинета поставщика, сканера или загрузки вручную. Здесь лучше сразу сохранять исходник, технические метаданные и источник. Потом это помогает разбирать спорные платежи.
Второй шаг, подготовка изображения. Система выравнивает перекошенные страницы, повышает контраст, убирает шум, определяет ориентацию, режет многостраничный PDF на страницы. Даже поворот на 90 градусов способен испортить распознавание, если этот этап пропустить.
Третий шаг, OCR. Алгоритм получает текстовые блоки и координаты. Хороший результат для бухгалтерии, это не просто строка текста, а набор фрагментов с расположением: где находится шапка, где таблица, где подписи, где печать.
Четвёртый шаг, извлечение сущностей. Я обычно называю это бухгалтерским парсером. Он ищет поля «дата», «номер», «контрагент», «ИНН», «сумма», «НДС», «назначение платежа» и связывает подписи со значениями.
Пятый шаг, контроль. Суммы пересчитываются, ИНН проверяется по формату, даты сравниваются с периодом учёта, контрагент сопоставляется со справочником. Только после этого запись можно отправлять дальше.
Какие данные извлекаются из первички
Ниже таблица, которую я использую как черновик технического задания. Она помогает бухгалтеру и разработчику быстро договориться, что именно нужно извлекать и как проверять результат.
| Поле | Где обычно находится | Типичная проверка | Что делать при сомнении |
|---|---|---|---|
| Дата документа | Шапка, рядом с номером | Формат даты, период закрыт или открыт | Отправить в ручную проверку |
| Номер документа | Шапка или строка «Счёт №» | Наличие дубля у того же контрагента | Показать похожие документы |
| Контрагент | Шапка, реквизиты, печать | Сверка с ИНН и справочником | Выбрать из 2–3 кандидатов |
| ИНН | Реквизиты поставщика | 10 или 12 цифр, контрольная логика | Запросить подтверждение |
| Сумма без НДС | Табличная часть или итог | Итог строк равен сумме | Подсветить расхождение |
| НДС | Итоги, отдельная строка | Ставка 0%, 10% или 20% | Проверить договор и тип операции |
| Сумма к оплате | Нижний итог | Сумма без НДС плюс налог | Блокировать автозагрузку при расхождении |
Для текстовых документов задача проще. Для сканов с печатями, факсом, рукописными пометками и сжатыми фотографиями сложнее. Часто проблема не в модели, а в качестве входа: фотография под углом, тень от руки, обрезанный край страницы, два документа на одном снимке.
По этой причине я не советую начинать проект с лозунга «автоматизируем всё». Начните с одного типа документа, например счетов на оплату от поставщиков. Если за месяц приходит 300 счетов, а ручная обработка каждого занимает 2–4 минуты, один этот поток даёт понятный объём рутины. Даже частичная автоматизация, при которой 70–80% документов проходят без вмешательства, заметно разгружает участок ввода.
Чем OCR отличается от документного ИИ
OCR отвечает на вопрос: «Какой текст напечатан на изображении?» Документный ИИ отвечает на другой вопрос: «Что этот текст значит для бизнес-процесса?» Разница хорошо видна на счёте.
OCR может вернуть набор строк:
- «ООО Ромашка»;
- «Счёт № 154 от 12.03.2026»;
- «Итого: 86 400,00»;
- «В том числе НДС: 14 400,00».
Документный ИИ должен вернуть структуру:
{
«тип_документа»: «счёт»,
«номер»: «154»,
«дата»: «12.03.2026»,
«контрагент»: «ООО Ромашка»,
«сумма_к_оплате»: «86400.00»,
«ндс»: «14400.00»
}
Такой формат уже можно валидировать и передавать дальше. Если вы работаете с генерацией текстов и хотите лучше понимать, почему модели ошибаются в формулировках и структуре, пригодится статья про проверку результатов нейросети при генерации текста. Логика похожая: модель даёт черновик, а качество появляется после правил, примеров и контроля.
Проверка ошибок: где автоматизация чаще всего ломается
Я бы закладывал проверки с первого дня. Без них система будет красиво извлекать неправильные данные.
Частая ошибка, путаница между поставщиком и покупателем. В счёте обычно есть реквизиты обеих сторон. Если модель берёт первую найденную организацию, она может записать вашу компанию вместо контрагента. Решение простое: хранить собственные реквизиты и исключать их из кандидатов на поле «поставщик».
Вторая ошибка, неверная сумма. В документе может быть сумма строки, сумма без налога, налог, итог, предоплата, задолженность. Для примера: в акте на 118 000,00 рублей с НДС 18 000,00 система должна различить минимум два финансовых поля, а не выбрать первое крупное число.
Третья ошибка, дата не того события. В договоре есть дата подписания, дата начала услуг, дата счета, срок оплаты. Для бухгалтерской проводки эти даты значат разное. Я предпочитаю задавать правила отдельно: «дата документа», «дата оказания услуги», «срок оплаты».
Четвёртая ошибка, контрагент найден по названию, но не совпал по ИНН. Названия пишут с сокращениями, кавычками, опечатками. ИНН надёжнее, хотя и его нужно проверять по длине и контрольным цифрам.
Пятая ошибка, табличная часть распалась. Если строк много, OCR может склеить соседние колонки. Тогда количество, цена и сумма начинают жить отдельно. Для таких документов полезно сравнивать итог таблицы с итоговой суммой документа.
Какие метрики качества нужны до запуска
В бухгалтерской автоматизации нельзя смотреть только на общий процент распознавания. Если система точно распознала адрес и ошиблась в сумме, польза сомнительная. Я бы разделил метрики по критичности.
| Метрика | Что показывает | Нормальный вопрос к ней |
|---|---|---|
| Точность OCR | Сколько символов распознано верно | Хватает ли качества сканов |
| Точность поля | Верно ли извлечено конкретное значение | Какие поля ошибаются чаще |
| Полнота | Все ли нужные поля найдены | Где модель пропускает данные |
| Доля автопроведения | Сколько документов прошло без ручной правки | Можно ли расширять сценарий |
| Доля ручной проверки | Сколько документов попало в очередь | Не перегружаем ли бухгалтеров |
| Цена ошибки | Сколько стоит неверная сумма или контрагент | Какие ошибки блокировать сразу |
Для пилота достаточно взять 100–300 документов одного типа. Их размечают вручную: где дата, где сумма, где контрагент, где НДС. Затем результат модели сравнивают с эталоном. Я не люблю тесты на пяти идеальных PDF, потому что они создают ложную уверенность. Лучше взять реальные сканы: кривые, тёмные, с печатями, разными шаблонами и старыми поставщиками.
Условный пример: компания из сферы оптовой торговли, ~80 сотрудников, запускает пилот на 250 счетах за квартал и помечает 7 полей в каждом документе. Такой набор даёт 1750 проверяемых значений. По нему уже видно, где система устойчива, а где требуется ручная проверка или отдельное правило.
Как подготовить данные для обучения и настройки
Даже если используется готовая модель, без примеров предметной области качество будет плавать. Бухгалтерские документы отличаются от страны к стране, от отрасли к отрасли и от поставщика к поставщику. У транспортной компании в актах будут рейсы, маршруты и тонно-километры. У рекламного агентства, кампании, периоды размещения и площадки. У производственного поставщика, номенклатура, единицы измерения и партии.
Я начинаю с карты документов. В ней фиксируются типы файлов, источники, объём в месяц, обязательные поля, правила проверки и дальнейший маршрут. После этого выбирается первый поток. Не самый сложный и не самый редкий. Хороший кандидат, массовый документ с повторяемой структурой и понятной ценностью автоматизации.
Разметка делается не «на глаз», а по инструкции. Если поле «контрагент» означает поставщика, это нужно написать прямо. Если нужно извлекать сумму к оплате с НДС, а не сумму без налога, это тоже фиксируется. Иначе два бухгалтера разметят один документ по-разному, а модель получит шум.
Работу с промптами удобно отрабатывать в чате. В SoftChat есть шаблоны промптов и пользовательские ассистенты для повторяемых сценариев, а ответы отображаются с разметкой Markdown, включая таблицы и блоки кода. Это помогает описывать правила извлечения, проверять JSON-структуру и обсуждать спорные документы. При этом интеграцию с учётной системой нужно проектировать отдельно: через API, обменные файлы или другой технический контур.
Если сотрудникам только предстоит привыкнуть к нейросетям, сначала дайте им бытовые и офисные сценарии. В статье про нейросети и чат-боты для повседневных задач я показывал, как снижать порог входа через планирование, черновики и рутину. Для бухгалтерии это особенно полезно: недоверие часто связано не с технологией, а с непонятным процессом проверки.
Как передавать данные в учётную систему
После извлечения у вас появляется структурированная запись. Дальше есть несколько путей.
Первый путь, ручное подтверждение и экспорт. Бухгалтер видит карточку документа, проверяет подсвеченные поля и нажимает «передать». На раннем этапе это самый безопасный вариант.
Второй путь, пакетная загрузка. Система собирает проверенные записи в файл обмена. Такой подход удобен, если учётная система уже поддерживает импорт по шаблону.
Третий путь, API-интеграция. Данные отправляются напрямую, а ответ учётной системы сохраняется в журнале: создан документ, найден дубль, не прошла проверка справочника, не хватает аналитики.
Четвёртый путь, роботизированный ввод через интерфейс. Его используют, когда API нет или он закрыт. Я отношусь к этому варианту осторожно: интерфейс меняется, кнопки переезжают, робот ломается там, где нормальная интеграция продолжила бы работать.
При любом варианте нужен журнал действий. Кто загрузил документ, что извлекла модель, какие поля исправил человек, когда запись попала в учётную систему. Без журнала сложно расследовать ошибку, а в бухгалтерии это не мелочь.
Таблица решений: что выбрать для разных потоков
| Подход | Когда подходит | Сильная сторона | Ограничение |
|---|---|---|---|
| Ручной ввод | До 20–30 документов в месяц | Не нужна разработка | Растёт нагрузка и риск опечаток |
| OCR без извлечения полей | Нужен поиск по архиву | Быстро делает текст доступным | Не понимает смысл полей |
| Документный ИИ с ручной проверкой | 100+ однотипных документов в месяц | Снижает рутину без потери контроля | Нужна разметка и очередь проверки |
| Полуавтоматическая загрузка | Поток стабилен, правила понятны | Бухгалтер подтверждает только спорное | Требует правил валидации |
| Полная автозагрузка | Документы стандартизированы, ошибки редки | Минимум ручных действий | Нужен сильный контроль и журнал |
Я бы не начинал с полной автозагрузки. Сначала лучше накопить статистику: какие поставщики дают чистые документы, какие поля ошибаются, сколько записей возвращается на исправление. После этого можно разрешать автоматический проход только для безопасных сочетаний: знакомый контрагент, совпавший ИНН, корректный НДС, сумма пересчиталась, дублей нет.
Роль человека в процессе
Бухгалтер не должен превращаться в оператора, который слепо принимает результат модели. Его работа смещается к контролю правил. Хорошая очередь проверки показывает не весь документ целиком, а причину остановки: «ИНН не найден», «сумма строк не равна итогу», «найдены два кандидата на контрагента», «дата относится к закрытому периоду».
Такой интерфейс экономит внимание. Человек исправляет конкретное поле, а не перечитывает каждую страницу. Исправление затем можно использовать для настройки правил и новых примеров. Если система месяцами повторяет одну ошибку, проблема не в бухгалтере, а в процессе улучшения.
Для обучения сотрудников хорошо работает формат коротких задач: взять скан, попросить модель вернуть JSON, затем сравнить с эталоном. Похожий принцип я использую в образовательных сценариях, где нейросеть помогает не списывать, а тренировать навык. Об этом подробнее есть материал про нейросети в образовании и саморазвитии.
Где здесь место SoftChat
SoftChat уместен на этапе анализа документов, настройки запросов, проверки структур и подготовки рабочих инструкций. В чате можно выбирать модель для конкретного разговора, использовать шаблоны промптов, подключать сохранённого ассистента к открытому чату и прикреплять изображения или документы к сообщениям с учётом лимитов выбранной модели. Для команды это удобный способ быстро проверить гипотезу: какие поля модель видит, где путается, какой формат ответа понятнее бухгалтеру и разработчику.
Я не стал бы обещать, что один чат сам построит бухгалтерскую интеграцию. Для промышленного контура нужны хранилище документов, очередь проверки, права доступа, журнал действий, обмен с учётной системой и регламент исправлений. Нейросеть закрывает смысловой слой: распознать, извлечь, объяснить, предложить структуру. Всё, что связано с проводками, правами и передачей данных, проектируется отдельно.
Если в компании уже сравнивают голосового помощника, браузерный чат и рабочий интерфейс для задач, полезно прочитать разбор что выбрать для обычных задач: Алису или нейросеть в браузере. Для бухгалтерии критерий похожий: важны файлы, история, повторяемые настройки и контроль результата.
Что бы я сделал на вашем месте
Я бы начал с инвентаризации первички за последние 2–3 месяца. Не с презентации, а с папки реальных документов. Разложил бы их по типам, посчитал объём, отметил самые частые форматы и выбрал один поток для пилота. Например, счета поставщиков или акты по регулярным услугам.
Затем я бы описал 8–12 обязательных полей и правила остановки. Если не найден ИНН, документ не уходит дальше. Если сумма без НДС плюс налог не равна итогу, документ попадает в очередь проверки. Если контрагент совпал со справочником и дубля нет, можно готовить запись к передаче.
Пилот на 100–300 документах покажет больше, чем длинное обсуждение стратегии. Вы увидите реальные ошибки: плохие сканы, нестандартные шаблоны, спорные даты, старые реквизиты, разные форматы НДС. После этого решение о расширении будет опираться на факты, а не на ожидания.
Автоматизация бухгалтерии с ИИ работает лучше всего там, где есть повторяемость, правила и честная проверка. Начните с узкого участка, сохраните ручной контроль для спорных случаев и ведите журнал исправлений. Тогда нейросеть станет частью нормального учётного процесса, а не отдельным экспериментом рядом с бухгалтерией.