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

Ручной ввод из актов, счетов, накладных и УПД редко выглядит как большая проблема на одном документе. Открыл PDF, нашёл дату, скопировал контрагента, проверил сумму, занёс в 1С. Но при 200 документах в месяц даже 3 минуты на один файл превращаются примерно в 10 часов механической работы. При 5 минутах это уже около 17 часов, и сюда не входят исправления после опечаток.

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

Где ручной ввод ломается чаще всего

В первичных документах бухгалтер обычно ищет ограниченный набор данных: номер, дату, контрагента, ИНН, КПП, сумму без НДС, НДС, сумму с НДС, назначение, иногда договор и склад. Кажется, что это простая таблица. На практике один и тот же реквизит может называться «Итого к оплате», «Всего», «Сумма документа», «Итог с НДС». В скане поле может быть сдвинуто, часть печати перекрывает цифры, а качество после пересылки в мессенджере падает до уровня, где «8» легко читается как «3».

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

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

Как нейросеть читает PDF и скан

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

Дальше файл превращается в промежуточное представление. В нём есть текст, координаты элементов, страницы, иногда отдельные таблицы. Нейросеть получает задачу: найти сущности по смыслу, а не по одному слову. Например, дата рядом с фразой «Счёт на оплату» может быть датой счёта, а дата в строке «Договор от 15.03.2025» относится к договору. Модель должна отличить эти поля.

Для устойчивой работы я не прошу модель «вытащи всё полезное». Такой запрос слишком широкий. Рабочее ТЗ выглядит строже: верни JSON с полями document_type, number, date, seller_name, seller_inn, buyer_name, buyer_inn, total_with_vat, vat_amount, currency, confidence, warnings. Если поле не найдено, нужно вернуть null, а не угадывать. Подход к формулировкам похож на промптинг для обычных задач, и здесь помогает база из статьи про правильные запросы к нейросетям.

Этап Что происходит Пример проверки Что попадает дальше
Предобработка Поворот, обрезка, повышение контраста Страница не перевёрнута, текст читается Изображение или PDF нормального качества
OCR Символы извлекаются из скана «ООО» не распознано как «000» Текстовый слой с координатами
Извлечение сущностей Модель ищет дату, сумму, ИНН, контрагента Дата документа отделена от даты договора Структурированный JSON
Валидация Поля проверяются правилами бухгалтерии ИНН 10 или 12 цифр, НДС сходится с итогом Проверенный набор реквизитов
Загрузка в 1С Данные передаются через обмен, обработку или API Дубль по номеру и контрагенту не создаётся Документ в учётной системе

Что именно проверять до загрузки в 1С

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

Для ИНН есть формальные контрольные алгоритмы: у юридических лиц 10 цифр, у ИП и физлиц 12 цифр. КПП состоит из 9 символов. Эти проверки быстро отсекают часть OCR-ошибок. Если в ИНН вместо нуля попала буква «О», поле не должно молча ехать в 1С.

С суммами логика ещё полезнее. При ставке НДС 20% сумма НДС обычно равна сумма с НДС × 20 / 120, с округлением до копеек. Если в документе указано 120 000 рублей с НДС, ожидаемый НДС около 20 000 рублей. Расхождение на 1 копейку бывает из-за округления по строкам, а разница в 2 000 рублей уже похожа на неверно прочитанную колонку. Для документов без НДС правило другое: модель должна найти фразу «Без НДС» или аналогичную отметку и не пытаться вычислить налог.

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

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

Как данные попадают в 1С

Есть несколько рабочих схем, и выбор зависит от конфигурации, объёма документов и готовности дорабатывать учётную систему. Самый простой вариант, обмен через файл: система распознавания формирует JSON, XML или CSV, а обработка в 1С забирает его из папки или по расписанию. Это удобно для пилота, потому что не требует сложной интеграции на старте.

Второй вариант, HTTP-сервис или API на стороне 1С, если конфигурация и инфраструктура это допускают. Тогда распознанные реквизиты передаются сразу в нужный объект: поступление, счёт, акт или УПД. Перед созданием документа 1С может выполнить свои проверки: найти контрагента по ИНН, проверить дубль по номеру и дате, сопоставить номенклатуру.

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

Условный пример: бухгалтерия с 250 входящими документами в месяц и ручным вводом по 4 минуты на документ тратит около 16–17 часов на копирование реквизитов. Если автоматизация оставляет человеку только проверку спорных полей, экономия зависит от качества входящих файлов и правил валидации, но уже пилот на 30 документах показывает, где узкие места: сканы, нестандартные формы, контрагенты без ИНН, сложные табличные части.

Как собрать пилот без хаоса

Я начинаю не с интеграции, а с набора документов. Нужны 20–30 файлов разных типов: текстовые PDF, сканы, УПД, акты, счета, документы с печатью поверх таблицы, файлы на 1–2 страницы и многостраничные варианты. Если взять только аккуратные PDF из одного сервиса, пилот покажет красивую картинку, а реальная почта бухгалтерии быстро её разрушит.

Дальше задаётся схема полей. Для каждого поля фиксируется тип данных, источник и правило пустого значения. Например: date, дата документа в формате ДД.ММ.ГГГГ; total_with_vat, число с двумя знаками после запятой; seller_inn, строка из 10 или 12 цифр. Такой словарь помогает и разработчику, и бухгалтеру говорить об одном результате.

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

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

Почему человек остаётся в контуре

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

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

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

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

Что считать нормальным результатом

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

Для примера: если ручной ввод одного акта занимал 4 минуты, а проверка распознанного черновика занимает 1 минуту 20 секунд, экономия на 100 актах составит около 4 часов 27 минут. Это модельный расчёт, а не гарантия результата: на плохих сканах выигрыш будет меньше, на стандартных текстовых PDF больше.

Я бы не начинал проект с фразы «автоматизируем всю первичку». Лучше выбрать один тип документа, например входящие акты от поставщиков, описать 10–15 обязательных полей и собрать тестовую партию. После этого станет ясно, что сложнее: распознавание, сопоставление контрагентов, табличная часть или загрузка в 1С.

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

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

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

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