Обновлено в июне 2026 года: я переписал материал под текущую практику обработки первичных документов, добавил этапы проверки, метрики качества и сценарии передачи данных в учётную систему.

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

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

Что именно автоматизируем в бухгалтерской первичке

В типовом процессе есть 5 групп данных, которые нужны чаще всего: реквизиты контрагента, дата и номер документа, сумма, ставка и сумма НДС, строки табличной части. Для акта это может быть одна строка услуги. Для УПД, 20–200 строк с номенклатурой, количеством, ценой, ставкой налога и итогом.

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

Для этого нужны 4 слоя:

Слой Что делает Типичная ошибка без слоя
Предобработка скана Выравнивает, чистит шум, улучшает контраст Цифра 8 распознаётся как 3
Распознавание текста Превращает изображение в текст и координаты Таблица превращается в кашу из строк
Извлечение полей Находит сумму, дату, контрагента, НДС Берётся сумма без налога вместо итога
Валидация Проверяет арифметику, формат и дубли В учёт попадает документ с неверной датой

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

Этап 1. Скан попадает в конвейер

Документ может прийти из почты, папки обмена, личного кабинета поставщика или мобильного скана. На входе система должна сохранить исходник, присвоить ему идентификатор и определить тип: счёт, акт, УПД, накладная, чек, договорное приложение.

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

Условный пример: если в папку загрузили 1 000 сканов за месяц, и 7% из них имеют обрезанный правый край, автоматическая проверка качества должна отправить эти 70 файлов на пересканирование или ручной просмотр до извлечения реквизитов. Иначе ошибки попадут дальше, где их сложнее поймать.

Этап 2. Распознавание текста и структуры

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

На этом этапе система решает 3 задачи:

  1. Разделяет страницу на зоны: шапка, реквизиты, табличная часть, итоги, подписи.
  2. Определяет строки и колонки таблицы.
  3. Сохраняет связь между подписью поля и значением.

Сложность начинается на реальных документах. Один поставщик пишет «Всего к оплате», другой «Итого», третий ставит сумму прописью ниже таблицы. В УПД встречаются колонки «Количество», «Цена», «Стоимость товаров», «Налоговая ставка», «Сумма налога». В актах услуг таблица часто короче, но названия услуг могут занимать 2–4 строки.

Поэтому одного распознавания текста мало. Нужен следующий слой, который понимает, какие фрагменты текста являются бухгалтерскими полями.

Этап 3. Извлечение суммы, даты и контрагента

После распознавания языковая модель или специализированный извлекатель получает текст, координаты и тип документа. Дальше она собирает структурированный результат. Например:

{
  «тип_документа»: «УПД»,
  «номер»: «1547»,
  «дата»: «12.06.2026»,
  «продавец_инн»: «7700000000»,
  «покупатель_инн»: «7711111111»,
  «сумма_итого»: 118000,
  «ндс»: 18000
}

В продакшене я не полагался бы на свободный ответ в виде абзаца. Нужна строгая схема: поле, тип данных, значение, уверенность, источник на странице. Для даты, формат ДД.ММ.ГГГГ. Для ИНН, 10 или 12 цифр. Для КПП, 9 цифр. Для суммы, число с копейками, валюта и признак НДС.

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

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

Этап 4. Проверка ошибок до записи в учёт

Главная часть автоматизации бухгалтерии находится не в распознавании, а в проверке. Документ можно прочитать красиво и всё равно занести неверно. Поэтому после извлечения запускают валидацию.

Базовые проверки выглядят так:

  • сумма строк сходится с итогом документа;
  • НДС равен расчётному значению для ставки 20%, 10% или 0%, если ставка указана явно;
  • ИНН и КПП имеют правильную длину и формат;
  • дата документа не уходит в закрытый период;
  • номер документа не повторяется у того же контрагента;
  • контрагент найден в справочнике;
  • валюта соответствует договору или настройке поставщика;
  • организация-покупатель совпадает с вашей компанией.

Условный пример: документ на 59 000 рублей с НДС 9 000 рублей при ставке 20% проходит арифметику, потому что база 50 000 рублей плюс налог 9 000 рублей даёт итог 59 000 рублей. Если распознавание ошиблось и прочитало итог как 58 000 рублей, проверка суммы строк сразу отправит документ на ручной разбор.

Для контроля качества удобно назначать каждому полю уровень уверенности. Например, дата найдена с уверенностью 0,98, сумма, 0,96, ИНН продавца, 0,91, номер документа, 0,63. Если порог для номера стоит на 0,8, документ не записывается автоматически. Бухгалтер видит исходный скан, подсвеченное место и предложенное значение.

Этап 5. Сопоставление с контрагентами и договорами

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

Хороший алгоритм не создаёт нового контрагента при первом несовпадении. Он ищет кандидатов в справочнике, считает сходство реквизитов и показывает бухгалтеру варианты. Если ИНН совпал, а название отличается на 2 слова, это обычно безопаснее, чем полное совпадение названия при разных реквизитах.

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

Для примера: в компании из сферы оптовой торговли, ~120 сотрудников, поток первички может включать 2 000–5 000 документов в месяц. Даже если автоматически проходит 60% входящих документов, ручной участок сокращается на тысячи переносов полей. Но оставшиеся 40% всё равно требуют удобного интерфейса проверки, иначе экономия утонет в переписке и исправлениях.

Этап 6. Запись в учётную систему

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

Практичный порядок такой:

  1. Сначала система только извлекает поля и показывает их рядом со сканом.
  2. Затем формирует черновик документа без проведения.
  3. После проверки бухгалтер нажимает «записать».
  4. Для надёжных типов документов включается автозапись при выполнении всех правил.
  5. Ошибочные и сомнительные документы уходят в очередь ручной обработки.

Автоматизация без журнала действий опасна. Нужны дата обработки, версия правил, кто подтвердил документ, какие поля исправлялись, какое значение было до правки. Это помогает разбирать споры с поставщиками и понимать, почему система приняла решение.

Какие метрики показывают, что автоматизация работает

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

Полезные показатели:

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

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

Где нейросети полезны бухгалтеру уже до интеграции

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

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

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

Как запускать проект без лишнего риска

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

План пилота:

  1. Собрать 500–2 000 документов с исходными сканами и правильными значениями полей.
  2. Разделить их по типам и качеству изображения.
  3. Описать обязательные поля и допустимые форматы.
  4. Настроить извлечение и валидацию.
  5. Прогнать тест, посчитать ошибки по каждому полю.
  6. Разобрать 50–100 худших случаев и доработать правила.
  7. Запустить режим черновиков, без автоматического проведения.
  8. Через 2–4 недели решить, какие документы можно проводить автоматически.

Условный пример: если пилот показывает 97% точности по дате, 99% по ИНН и 92% по сумме НДС, нельзя смотреть только на среднее. НДС надо разбирать отдельно, потому что именно это поле влияет на налоговый учёт. Иногда выгоднее оставить НДС на ручную проверку, а дату, номер и контрагента заносить автоматически.

Что изменилось в обновлённой версии статьи

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

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

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