Распознавание счетов легко принять за автоматизацию расчётов с поставщиками. Но распознанный счёт доказывает только одно: поля из документа извлечены. Он не доказывает, что выбран правильный поставщик, что счёт соответствует согласованной закупке и что его разрешено проводить.
Поэтому до выбора инструмента для распознавания стоит описать весь путь счёта: от входящего письма до записи в учётной системе. Ниже разберём, на какие состояния его разделить, какие решения можно отдать правилам, где помогает AI и какие случаи должен решать человек. Тот же подход работает и для сверки банковской выписки.
Одна оговорка. Правила сопоставления, допустимые расхождения и порядок согласования устанавливает ваша финансовая служба. Здесь речь об устройстве процесса, а не об учётной политике.
Пять состояний счёта
Разделите путь счёта на состояния, которые нельзя спутать друг с другом:
- Распознан. Поля извлечены, у каждого есть ссылка на исходный файл. Больше это состояние ничего не означает.
- Сопоставлен. Счёт связан с поставщиком, заказом и, если этого требуют ваши правила, с фактической приёмкой. Основание связи сохранено.
- Исключение. Найдено расхождение или не хватает данных. Счёт ждёт разбора.
- Утверждён. Человек или правило, у которых есть такие полномочия, разрешили провести счёт.
- Проведён. Учётная система подтвердила запись, и её номер сохранён рядом со счётом.
Оплаты в этом списке нет намеренно. У неё должен быть свой процесс и свои права: утверждённый к проведению счёт ещё не означает разрешения платить.
Для каждого перехода запишите две вещи: какое нужно основание и кто вправе перевести счёт дальше — правило или конкретная роль. Например: «из „сопоставлен“ в „утверждён“ переводит правило, если сумма и количество совпадают с заказом; в остальных случаях решает руководитель, который отвечает за этот бюджет». Пока такой записи нет, автоматизировать переход рано: непонятно, что именно автоматизируется.
Счёт с заказом и счёт без заказа
Если у счёта есть заказ на закупку, проверьте, какое сопоставление требуют ваши правила. Иногда достаточно сравнить счёт с заказом. Иногда нужно сверить ещё и количество с документом приёмки — такое сопоставление называют трёхсторонним.
Условный пример. Заказали 100 коробок, на склад приняли 60, а счёт пришёл на все 100. Сравнение только с заказом покажет полное совпадение. Сравнение с приёмкой покажет расхождение, которое должен разобрать человек.
У счёта без заказа — за аренду, разовую услугу, подписку — сопоставлять не с чем. Ему нужен явный маршрут согласования. Хуже всего привязать такой счёт к первому похожему заказу только для того, чтобы проверка прошла.
Правила, AI и человек: кто что решает
Однозначное закрывают правила
Если ровно один кандидат подходит по всем признакам — поставщик, номер заказа, сумма в согласованных пределах, валюта, период, — совпадение подтверждает правило. Его решение можно объяснить и повторить. Именно такие случаи и стоит закрывать без участия людей.
AI предлагает кандидатов
AI полезен там, где данные записаны небрежно: номер счёта стоит в комментарии, название поставщика сокращено, в назначении платежа написано «оплата по сч. 15 за сентябрь», один платёж закрывает несколько счетов. Модель может разобрать такой текст и предложить кандидатов, объяснив, почему выбрала именно их.
Предложение — ещё не решение. Оценка уверенности модели — полезный сигнал, но не разрешение пропустить проверку.
Спорное решает человек
Если подходят несколько кандидатов, суммы расходятся или основания нет, случай остаётся открытым, пока его не разберёт ответственный сотрудник по согласованному правилу. Если просто взять первого подходящего кандидата, отчёт станет аккуратнее, а сверка — менее надёжной.
Совпадение сумм — подсказка, а не доказательство. Два платежа одному поставщику на одну и ту же сумму в одном месяце, банковская комиссия, сторно, частичная оплата — любое из этого меняет решение. Рядом с каждым предложенным совпадением храните исходные записи и причину, по которой оно предложено.
Почему сверка выписки подходит для первого проекта
Для первого проекта с AI в финансах нужна узкая задача, в которой каждое решение можно проверить. Сопоставление строк банковской выписки с проведёнными операциями подходит: у каждой строки понятный итог — совпадение найдено, не найдено или требует разбора.
Сначала определите границы: какой банковский счёт, какое юридическое лицо, какая валюта, какой период и какие правила сопоставления приняла финансовая команда. Без этого не получится отличить ошибку системы от разногласий внутри самой команды.
Исключения — это тоже процесс
У каждого расхождения должны быть причина, ответственный и следующее действие. Причину удобнее выбирать из короткого согласованного списка: «нет приёмки», «сумма не совпадает с заказом», «возможный дубль», «нет согласования». Тогда видно, какие причины повторяются.
Повторяющаяся причина — повод что-то изменить. Если поставщик всегда пишет номер заказа в комментарии, можно дополнить правило или договориться с поставщиком. А если очередь исключений только растёт, это та же ручная работа, просто перенесённая на другой экран.
Пилот без записи в учётную систему
Первый пилот должен только предлагать: совпадения, переходы между состояниями, черновики записей. В учётную систему он ничего не пишет. Команда работает как обычно, а предложения сравниваются с её проверенными решениями.
Считайте три вещи:
- ошибочно принятые совпадения — каждое разбирайте отдельно;
- случаи, переданные на разбор человеку;
- время, которое ушло на их разбор.
Указывайте, какие документы вошли в выборку и за какой период. Высокая доля закрытых случаев сама по себе ничего не говорит: за ней могут прятаться ложные совпадения. Нерешённый случай виден сразу, а ошибочно принятый выглядит закрытым, поэтому он обходится дороже.
Прежде чем расширять охват, прогоните трудные случаи: частичную приёмку, один и тот же счёт, пришедший дважды (письмом и сканом), отсутствие согласования, два правдоподобных кандидата. Отдельно проверьте обрыв связи после того, как учётная система уже сохранила документ: повторное создание без проверки даст дубль. Как безопасно повторять запись, мы разбирали в статье о заявках, которые не доходят до CRM, — механика здесь та же. Если вы выбираете готовое решение, попросите поставщика показать, как оно восстанавливается после каждой из этих ситуаций.
Чек-лист перед запуском
- Описан путь счёта от получения до записи в учётной системе.
- Состояния «распознан», «сопоставлен», «исключение», «утверждён», «проведён» разделены, оплата вынесена в отдельный процесс.
- Для каждого перехода известны основание и тот, кто вправе его выполнить.
- Финансовая служба утвердила правила сопоставления и допустимые расхождения.
- Для счетов без заказа есть свой маршрут согласования.
- Правила закрывают только случаи с единственным подходящим кандидатом.
- Предложения AI хранятся вместе с исходными записями и причиной.
- Случай с несколькими кандидатами остаётся открытым до решения человека.
- У каждого исключения есть причина из списка, ответственный и следующий шаг.
- Пилот не пишет в учётную систему.
- Ошибочно принятые совпадения считаются и разбираются отдельно, выборка и период указаны.
- Проверены частичная приёмка, дубль счёта, отсутствие согласования и обрыв связи после сохранения.
С чего начать
Выберите один поток: например, счета с заказами от одной группы поставщиков или выписку по одному банковскому счёту за месяц. Соберите прошлые случаи, которые команда уже разобрала, и обязательно добавьте трудные. Запустите пилот в режиме предложений и вместе с финансовой службой разберите каждое ошибочно принятое совпадение. Только после этого решайте, какие переходы автоматизировать. Как оценить, окупится ли такой проект, мы описали в статье про ROI AI-автоматизации.
Если хотите разобрать один такой процесс, опишите его нам в Telegram (@infracortex_studio) или через страницу автоматизации процессов: для первого разговора хватит описания шагов, без внутренних документов и персональных данных.