Как AI сравнивает договор, счёт и акт между собой

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



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

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

С чего я начинаю проверку

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

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

Как проходит документ

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

Рабочий маршрут состоит из семи шагов. Файл принимается и получает идентификатор. Система определяет тип документа и проверяет комплектность. OCR или Document AI извлекает текст, таблицы и реквизиты. Нормализатор приводит деньги, даты, номера и названия к общему формату. Модуль связывания находит договор, к которому относятся счёт и акт. Детерминированные правила выполняют сверку. Наконец, сотрудник видит только исключения и подтверждает спорные случаи.

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

Как связать три документа с одной сделкой

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

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

Здесь важнее не скорость, а проверяемость результата.

В сложных потоках каждому комплекту присваивается собственный reconciliation ID. Он связывает файлы, результаты извлечения, применённые правила, решения сотрудника и последующую запись в 1С. Тогда повторная загрузка акта не создаёт вторую операцию, а обновляет или переоткрывает существующую проверку по понятному сценарию.

Что именно сравнивать

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

Сумма и НДС: арифметика раньше модели

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

Отдельно фиксируют валюту и единицу измерения. Число «150 000» не имеет смысла без рубля, доллара или другой валюты; «10» не доказывает совпадение, пока не ясно, речь идёт о часах, лицензиях или комплектах. Нормализатор может подсказать значение по контексту, но отсутствие явной единицы должно оставаться видимым исключением.

Состав услуг: где действительно полезен AI

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

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

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

Где хранится источник, версия и статус

Устойчивая архитектура не отдаёт одной модели весь процесс. Приём файлов отвечает за тип, целостность и антивирусную проверку. Document AI извлекает кандидатов значений. Нормализатор приводит их к типизированной схеме. Reconciliation engine связывает документы и применяет правила. Очередь исключений получает спорные поля. Адаптер 1С или другой учётной системы выполняет только разрешённую команду после успешного контроля.

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

{
  "reconciliation_id": "rec_2481",
  "contract": "Д-184/26",
  "invoice_total": 186000,
  "act_total": 186000,
  "currency": "RUB",
  "status": "review_required",
  "issues": [
    {"field": "service_period", "rule": "WITHIN_CONTRACT_TERM"}
  ]
}

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

Какие ошибки я бы проверил руками

Fallback — это не кнопка «передать оператору» без контекста. В очередь должны попадать конкретное поле, причина остановки, значения из трёх документов и визуальные фрагменты. Тогда сотрудник принимает одно решение, а не повторяет всю работу системы вручную.

Какие ошибки действительно важны

Точность OCR сама по себе мало говорит о результате. Ошибка в названии несущественной позиции и ошибка в сумме НДС имеют разную цену. Поэтому качество измеряют на уровне поля, комплекта и завершённой бизнес-операции.

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

Как должна выглядеть карточка ручной проверки

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

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

Общий confidence полезен для мониторинга, но не для решения по комплекту. У номера договора, суммы, НДС и состава услуг разные риски. Поэтому пороги задаются на уровне поля и сценария. Низкая уверенность в необязательном комментарии не должна блокировать оплату, а сомнительный ИНН — должна.

Сценарий, где видно происхождение каждого поля

Представим договор на 1,2 млн рублей с ежемесячной приёмкой. В счёте указано 300 тыс. рублей аванса, а в акте — услуги за месяц на 100 тыс. Простое сравнение сумм выдаст расхождение. Корректная схема сначала определит тип платежа и модель исполнения: аванс не обязан совпадать с суммой одного акта, но накопленная стоимость актов не должна превысить лимит договора, а зачёт аванса должен соответствовать условиям.

Система извлекает номер договора, стороны, валюту, НДС, период и позиции. Затем проверяет, что счёт относится к тому же договору, а акт закрывает период внутри срока действия. Сумма счёта получает статус «допустимо по модели аванса», сумма акта — «совпадает с месячным этапом». Если приложение с графиком отсутствует, модель может найти упоминание аванса, но правило не получает достаточного основания. Комплект уходит на проверку с конкретной причиной: «не найден источник лимита этапа».

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

Критерии приёмки перед подключением к учёту

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

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

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

С какого типа документов я бы начал

1. Соберите выборку. Возьмите типовые комплекты, частичные акты, дополнительные соглашения и известные ошибки.
2. Опишите схему. Зафиксируйте обязательные поля, источники истины, типы значений и три состояния: совпало, допустимо, проверить.
3. Напишите правила. Отделите точное сравнение реквизитов от лимитов, периодов и семантического сопоставления услуг.
4. Запустите shadow-режим. Система формирует карточку, но не влияет на бухгалтерский учёт; сотрудник сравнивает результат со своей проверкой.
5. Разберите ошибки. Разделите проблемы извлечения, связывания документов, правил и интерфейса.
6. Автоматизируйте зелёный коридор. Без человека проходят только комплекты, успешно выдержавшие все критичные проверки.
7. Подключите запись. Передавайте результат в 1С идемпотентной командой и сохраняйте фактический ответ системы.

Что нужно уточнить по документам

Можно ли полностью доверить сверку AI?

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

Нужна ли большая языковая модель, если есть OCR?

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

Что считать источником истины?

Это задаётся по каждому полю. Юридические условия обычно определяет подписанный договор и приложения, факт оказания — акт, платёжное требование — счёт, а справочные реквизиты могут дополнительно проверяться по мастер-данным контрагента.

Как обрабатывать дополнительное соглашение?

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

Источники и документация

Возможности извлечения текста, таблиц и структурированных полей описаны в документации Google Cloud Document AI, Amazon Textract и Azure AI Document Intelligence. При проектировании передачи результата в учётный контур полезно сверяться с официальным описанием HTTP-сервисов 1С:Предприятия. Общую рамку управления риском даёт NIST AI RMF.

Следующие шаги: разобрать извлечение данных из счетов, актов и договоров или посмотреть безопасную передачу данных из PDF в 1С.

В «Как AI сравнивает договор, счёт и акт между собой» скорость имеет смысл только после доказуемости. Если результат нельзя восстановить по документу и журналу решений, я не считаю такой контур надёжным.