Автоматизация обработки первичных документов: счета, акты, накладные

Первая ошибка проекта — начать с вопроса, какой OCR или AI лучше читает документы. До выбора технологии нужно определить, что именно считается успешно обработанным документом.

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

Полезно разделить три состояния.

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

Поэтому хороший контур автоматизации документооборота строится вокруг проверок и статусов, а распознавание является только одним из этапов.

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

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

Пример матрицы:

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

Рабочую архитектуру полезно проектировать не как одну функцию «распознать документ», а как конвейер.

Источник документа → получение файла и метаданных → сохранение оригинала → определение типа и формата → парсер или OCR → извлечение реквизитов и табличной части → нормализация значений → поиск контрагента и номенклатуры → сверка с заказом, договором или другим основанием → арифметические и бизнес-проверки → автоматический маршрут для однозначных случаев → очередь исключений → проверка сотрудником → создание или обновление объекта в 1С / ERP → журнал результата.

У каждого этапа своя функция.

Интеграция получает документ из ЭДО, почты, файлового хранилища или другой системы и передаёт результат дальше.

Парсер разбирает структурированный формат, если его поля известны заранее.

OCR получает текст из изображения или скана.

Обычный код приводит даты, суммы, идентификаторы и единицы измерения к нужному виду.

Бизнес-правила проверяют арифметику, обязательные поля, дубли и допустимые значения.

Поиск сопоставляет внешние данные со справочниками компании.

AI имеет смысл подключать только для действительно неоднозначной информации.

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

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

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

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

Если система не уверена, какой объект справочника выбрать, безопасный результат — «требует проверки», а не автоматический выбор первого подходящего варианта.

Наличие PDF или скана само по себе не делает процесс задачей для генеративного AI.

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

AI становится полезным, когда обычные правила перестают надёжно описывать вход:

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

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

Граница между этими механизмами подробнее разобрана в материале «ИИ-автоматизация для бизнеса: чем отличается от обычной интеграции».

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

Ниже показана возможная структура интерфейса, а не скриншот существующей системы.

Для каждого исключения можно показывать:

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

Например:

Документ: входящая накладная Строка: пример позиции поставщика Найдено в справочнике: возможное соответствие Количество: совпадает Единица измерения: отличается Цена: совпадает Статус: требуется подтверждение сопоставления После подтверждения: строка попадёт в черновик учётного документа.

Сотрудник проверяет конкретное исключение, а не выполняет весь процесс повторно.

Необязательно переносить всю автоматизацию внутрь 1С или, наоборот, выносить всю учётную логику наружу.

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

Практическая схема может выглядеть так:

ЭДО / почта / хранилище → интеграционный контур → извлечение данных → проверки → запрос справочников 1С → очередь исключений → подтверждение → создание черновика в 1С → возврат статуса → журнал обработки.

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

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

В опубликованном кейсе AI-системы для B2B-поставщика входящие заявки и документы связаны с 1С, складом и CRM, а менеджер проверяет результат перед дальнейшим действием.

Автоматизировать извлечение данных и автоматически принимать финансовое или учётное решение — не одно и то же.

Человеку следует оставлять подтверждение, если система сталкивается с неоднозначностью или решение имеет существенные последствия. Например:

• два возможных контрагента;
• неизвестная номенклатура;
• изменение цены относительно основания;
• существенное расхождение количества;
• выбор договора из нескольких вариантов;
• принятие спорного акта;
• создание нового элемента справочника;
• конфликт между исходным документом и данными учётной системы;
• проведение документа, если этого требует внутренний регламент.

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

Для пилота лучше выбрать не «всю первичку», а один ограниченный поток с понятным владельцем процесса.

Рассмотрим условный пример.

Компания получает накладные от разных поставщиков и вручную создаёт документы в учётной системе. Для пилота выбираются только входящие товарные накладные одного подразделения.

До разработки собираются:

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

Затем фиксируется маршрут:

входящая накладная → извлечение данных → сопоставление контрагента → сопоставление строк → проверки → черновик → ручная проверка исключений → запись результата.

Критерии приёмки пилота

Проверять нужно весь процесс, а не только качество чтения текста.

Для тестового набора следует определить:

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

Целевые значения определяются по конкретному процессу. Универсальный процент «достаточной точности» не заменяет критерии приёмки для разных типов ошибок.

Стоимость определяется границами процесса и количеством исключений, которые система должна обрабатывать, а не только выбором OCR или AI-модели.

На оценку влияют:

• количество типов документов;
• разнообразие форм и поставщиков;
• наличие структурированных документов и сканов;
• объём табличных данных;
• качество изображений;
• число справочников;
• сложность сопоставления номенклатуры;
• правила сверки с заказами и договорами;
• количество интеграций;
• особенности конфигурации 1С или ERP;
• необходимость пользовательского интерфейса;
• роли и права доступа;
• требования к хранению исходников;
• журналирование;
• информационная безопасность;
• обработка повторных событий и сбоев;
• сопровождение после изменения форматов и внутренних правил.

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