ИИ в бухгалтерии: счета, акты и загрузка в учёт в 2026

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

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

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

Из чего состоит задача: от картинки до проводки

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

Первый слой, подготовка изображения. Файл приводят к читаемому виду: выравнивают страницу, убирают шум, повышают контраст, разворачивают лист, режут многостраничный PDF на страницы. Для бухгалтерских документов часто хватает 300 dpi, но фотографии с телефона требуют отдельной обработки: там бывают тени, перспектива и обрезанные края.

Второй слой, OCR. Система превращает изображение в текст и координаты слов на странице. Координаты нужны не меньше текста: сумма справа внизу, ИНН рядом с блоком поставщика, дата около номера счёта. Без геометрии модель чаще путает реквизиты продавца и покупателя.

Третий слой, понимание макета. Нейросетевые модели анализа документов смотрят на текст вместе с расположением блоков. Они учатся различать шапку, табличную часть, подписи, итоги, строки с НДС. Для счёта это один набор признаков, для акта другой. Универсальная модель может читать оба типа, но качество обычно растёт, когда в обучающей выборке есть документы нужного формата.

Четвёртый слой, бизнес-валидация. Даже идеально распознанный текст ещё не означает, что документ годится к загрузке. Сумма по строкам должна совпадать с итогом, ставка НДС должна соответствовать сумме НДС, дата не должна выпадать из закрытого периода, ИНН должен пройти контрольную проверку. На этом этапе бухгалтерская логика важнее распознавания.

flowchart LR
A[Скан или PDF] --> B[Подготовка изображения]
B --> C[OCR: текст и координаты]
C --> D[Извлечение полей]
D --> E[Проверка сумм, дат, ИНН]
E --> F{Уверенность достаточна?}
F -->|Да| G[Запись в очередь загрузки]
F -->|Нет| H[Проверка бухгалтером]

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

Какие поля извлекают из счётов и актов

Минимальный набор для счёта обычно включает номер, дату, сумму, валюту, ставку и сумму НДС, ИНН и КПП поставщика, наименование контрагента, реквизиты договора, назначение платежа. Для акта добавляются период оказания услуг, номер договора, исполнитель, заказчик, перечень работ, итоговая сумма, подписи или отметка об электронном подписании.

Сложность начинается на похожих полях. В документе может быть дата договора, дата счёта, дата акта, дата оплаты. Если просто искать первую дату на странице, система быстро ошибётся. Нужен контекст: «Счёт № 245 от 12.03.2026» отличается от строки «Договор от 15.01.2025». То же самое с суммами. В табличной части может быть цена за единицу, сумма строки, сумма без НДС, сумма НДС и итог к оплате.

Условный пример: в пачке из 1 000 документов 40 поставщиков используют 40 разных шаблонов, но нужных полей остаётся около 12–20. Поэтому выгоднее обучать систему искать смысловые зоны, а не координату «правый нижний угол». Такой подход выдерживает смену шаблона, добавление логотипа или перенос блока реквизитов.

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

Где ИИ ошибается чаще всего

Ошибки делятся на технические и смысловые. Техническая ошибка, это когда OCR прочитал «8» как «3», потерял запятую в сумме или склеил две строки таблицы. Смысловая ошибка, это когда текст распознан верно, но поле выбрано не то: система взяла ИНН покупателя вместо ИНН поставщика или перепутала итог с суммой без налога.

Я бы заранее проверял такие зоны риска:

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

Для качества мало смотреть среднюю точность по документу. Поле «наименование товара» может быть распознано с ошибкой без бухгалтерского риска, а поле «сумма к оплате» критично. Поэтому метрики считают по каждому полю отдельно: доля верных сумм, доля верных дат, точность ИНН, полнота извлечения табличных строк. В промышленной схеме ещё смотрят долю документов, ушедших на ручную проверку. Если автоматизация читает 95% полей, но отправляет бухгалтеру 70% документов из-за слабых правил, экономия будет небольшой.

Сравнение подходов к автоматизации

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

Компания из сферы логистики, ~200 сотрудников, обычно получает документы от перевозчиков, складов, подрядчиков по ремонту и арендодателей. Даже без привязки к конкретному бренду учётной системы структура задачи похожа: 10–15 типов входящих документов, десятки шаблонов, пик нагрузки в конце месяца. В такой среде гибридный подход выигрывает у чистых правил, потому что поставщики меняют формы без предупреждения.

Как устроена проверка перед загрузкой

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

Отдельный вопрос, как работать с уверенностью модели. Для суммы и ИНН порог должен быть жёстче, чем для описания услуги. Если модель уверена в сумме на 99%, но ИНН распознан с низкой уверенностью, документ не должен автоматически попадать в загрузку. Его лучше отправить в очередь ручной проверки с подсветкой поля.

Условный пример: для счёта «С-1045» система извлекла сумму 118 000 рублей, НДС 18 000 рублей и дату 31.03.2026, но нашла в справочнике двух контрагентов с похожим названием. Такой документ нельзя молча записывать в учёт. Правильное действие, показать бухгалтеру оба варианта и сохранить выбор как сигнал для следующих документов этого поставщика.

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

Как готовят обучающую выборку

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

Разметчик выделяет поля: номер, дата, итог, НДС, ИНН поставщика, ИНН покупателя, строки таблицы. Для табличной части часто размечают не только текст, а связи: эта цена относится к этой позиции, эта сумма относится к этой строке. Разметка 200 документов вручную может занять несколько рабочих дней, потому что спорные зоны приходится обсуждать с бухгалтером. Зато после первых 100–300 документов уже видно, какие поля стабильно читаются, а какие требуют новых правил.

Для примера: если в выборке 500 актов, но только 12 из них многостраничные, качество на приложениях будет случайным. Лучше заранее добавить документы с приложениями, нулевыми суммами, разными ставками НДС и нестандартными периодами. Это дешевле, чем ловить ошибки после запуска.

С промптами и текстовыми правилами можно работать отдельно от OCR-конвейера. Например, в чате удобно сформулировать инструкцию для проверки полей, список исключений, шаблон ответа бухгалтеру по спорному документу. В SoftChat для таких задач можно использовать текстовый чат, переключать модели в рамках разговора, хранить историю по организации и подключать сохранённого ассистента к открытому чату. Если вы готовите такие инструкции, пригодится материал про формулировку запросов для нейросетей, потому что качество правила часто зависит от точности постановки задачи.

Интеграция с учётной системой без хаоса

Загрузка в учётную систему должна быть последним шагом, а не первым. Между распознаванием и записью нужен слой нормализации: привести даты к одному формату, суммы к копейкам, контрагентов к справочнику, договоры к внутренним идентификаторам. Если такого слоя нет, в учёте появляются дубли: «Ромашка ООО», «ООО Ромашка», «Общество с ограниченной ответственностью Ромашка».

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

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

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

Как запускать проект по шагам

Я бы не начинал с фразы «автоматизируем всю бухгалтерию». Слишком широко. Лучше взять один поток, например входящие счета от поставщиков услуг, и описать его до уровня полей и исключений. Затем собрать 300–500 документов за несколько месяцев, удалить лишнее, разметить ключевые поля и прогнать тестовый контур без записи в учётную систему.

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

Условный пример: из 2 000 входящих счетов в месяц 1 300 проходят все проверки, 500 требуют выбора договора, 200 имеют плохие сканы или новый шаблон. Автоматизировать первые 1 300 выгоднее, чем пытаться любой ценой закрыть все 2 000. Оставшиеся документы дают материал для следующей итерации: добавить шаблоны, уточнить правила, расширить справочник.

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

Что бы я сделал на вашем месте

Я бы начал с инвентаризации документов за последний квартал: сколько счетов, сколько актов, сколько поставщиков, какие форматы файлов, какие ошибки встречаются при ручном вводе. Затем выбрал бы один поток с понятной экономикой. Если документов меньше 50 в месяц, полноценный Document AI может оказаться тяжелее ручной обработки. Если поток идёт сотнями, уже есть смысл считать пилот.

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

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