Разнесение платежей по договорам с помощью ИИ: автоматизация бухгалтерии

Введение: Разнесение платежей по договорам — точность 97% на «грязных» данных в поле «Назначение платежа»

Разнесение входящих платежей — один из самых трудоёмких участков процесса Invoice-to-Cash (весь цикл от выставления контрагенту счёта до получения денег). Когда учёт дебиторской задолженности зависит от ручного разбора тысяч платежей, этот этап быстро становится узким местом.

Проблема: Контрагенты заполняют поле «Назначение платежа» как придётся

Задача кажется простой: извлечь корректный номер договора. На практике казначейство федеральной компании с 1 500+ активных договоров ежедневно разбирает неточности и ошибки:

• Опечатки, смешение кириллицы/латиницы и десятки способов записи одного номера.

• В одной строке перемешаны периоды, суммы НДС, номера УПД и комментарии бухгалтера контрагента.

• В значительной доле платежей номер договора не указан вовсе — остаются лишь общие фразы («оплата аренды», «электроэнергия за ноябрь» и подобные).

Ручная обработка требовала колоссальных ресурсов (в нашем случае эквивалент 9 FTE) и приводила к «плавающей» дебиторской задолженности. Разработанные штатными программистами скрипты не справлялись с исключениями. Нашей целью стало построить систему, обеспечивающую точность не ниже 95% без расширения штата.

Решение: ИИ-конвейер на базе Epsilon Workspace

Мы внедрили систему, в которой реализовали 2 подхода

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

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

Результаты на выборке из 18 000 операций

• 97% — точность Top-1: Верное определение договора с первой попытки.

• 99% — точность Top-3: Правильный вариант всегда в тройке подсказок оператору.

• < 1 секунды: Скорость обработки одного платежа.

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

Решение

Особенность проекта — фокус на устранении «бутылочного горлышка» в финансах без увеличения численности сотрудников. Заказчик выбрал путь создания промышленного ИИ-конвейера на базе платформы Epsilon Workspace.

Выбор платформы был обусловлен тремя факторами, критичными для систем класса Invoice-to-Cash:

1. Работа с «грязными» данными: Устойчивость к опечаткам, омоглифам (смешение кириллицы/латиницы) и избыточному шуму в тексте.

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

3. Контроль: Возможность аудита каждого решения ИИ и единый контур управления реестрами и исключениями.

Как работает система

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

Этап 1. Детерминированное извлечение номера договора и нормализация

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

Система автоматически нормализует раскладку (латиница → кириллица) и приводит разделители к единому формату. Это позволяет сопоставлять даже «искаженные» номера с эталонным реестром договоров.

Этап 2. Векторный семантический поиск номера договора

Если номер договора отсутствует или не найден в базе, включается следующий слой:

• Очистка данных: Система «отфильтровывает» из назначения платежа даты, суммы и номера УПД, оставляет только смысловую нагрузку.

• Сопоставление по контексту: ИИ ищет договор по смыслу (например, «аренда за октябрь»), использует для этого векторные представления.

Этап 3. Разрешение неоднозначностей

Для определения договора система применяет более 37 бизнес-правил. Учитываются:

• Тип услуги и региональные признаки (КПП/ИНН).

• История прошлых оплат контрагента.

• Типовые суммы платежей по конкретным договорам.

Работа с исключениями

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

• Подсказки для эксперта: Система подсвечивает Top-3 кандидата с обоснованием (почему выбран именно этот договор).

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

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

Результаты внедрения: 97% платежей «разносятся сами» и больше не создают очередь на ручную сверку

Проект дал два типа результатов:

• прямые, измеримые в точности и скорости,
• операционные — которые меняют сам процесс разнесения и последующих сверок

1) Сократили ручную рутину и стоимость обработки платежей

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

После внедрения основная часть платежей распознаётся автоматически:

• система правильно определяет договор с первого раза в 97% случаев,
• в большинстве спорных ситуаций правильный договор всё равно попадает в короткий список для быстрой проверки (Top-3 = 99%).

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

2) Стали работать быстрее и стабильнее

Требование Заказчика — работать в реальном времени. Система обрабатывает один платёж менее чем за 1 секунду, то есть подходит для интеграции с учётной системой Заказчика (в этом кейсе это 1С).

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

3) Масштабируемость: работает на реальных данных

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

Чтобы поддерживать качество, Система использует:

• работу с 80+ регионов, 4 типа услуг и 37 правил разрешения неоднозначностей с учётом специфики номеров в регионах;
• каскадный поиск (ИНН+КПП+тип → ИНН+КПП → ИНН) и корректировочную таблицу для исключений — чтобы обрабатывать нестандартные платежи.

Результаты в цифрах

• 97% — точность Top-1 на выборке ~18 000 реальных операций по ~1 500 договорам.
• 99% — точность Top-3 (правильный договор почти всегда в тройке).
• < 1 секунды — обработка одного платежа, пригодно для потоковой интеграции.

Как считали экономику

Чтобы не спорить про «сколько сотрудников заменили» и не пересчитывать ставки, мы считали эффект через операционную единицу — один входящий платёж. Это тот же подход, который обычно используют в кейсах решений класса Invoice-to-Cash: основная ценность видна на уровне одной операции, а потом масштабируется на их количество.

Шаг 1. Зафиксировали базовый процесс «до»

Мы описали, что реально делает сотрудник, когда видит новый платёж:

• читает назначение;
• пытается найти номер договора (или догадаться по смыслу);
• проверяет контрагента, регион, тип услуги;
• вносит разнесение в учёт;
• при ошибке — разбирает корректировку, перепривязку и последствия.

Для расчёта нам нужны два показателя:

• среднее время ручной обработки одного платежа (лучше разделить на 2–3 класса сложности: “номер есть”, “номера нет”, “неоднозначно”);
• доля платежей, которые требуют исправлений и среднее время на исправление.

Шаг 2. Зафиксировали целевой процесс «после»

После внедрения поток делится на две части:

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

Для расчёта мы меряем:

• долю автоматического разнесения;
• среднее время обработки исключения (обычно меньше, чем “до”, потому что система сразу даёт кандидатов и подсказки);
• долю исправлений после внедрения (как правило, падает, потому что решение устойчивее к “шуму” и неоднозначностям).

Шаг 3. Перевели время в деньги

Затем время обработки переводится в стоимость через внутреннюю стоимость часа специалиста (полная стоимость, как принято в компании: зарплата + налоги + накладные расходы).

Мы считали две составляющие:

• Прямая стоимость обработки платежа — время сотрудников на разнесение и проверки.
• Стоимость исправлений — время на корректировки и разбор ошибок (до и после).

Важно: если вы не хотите учитывать “цену ошибки” в деньгах, можно оставить только время — методика всё равно будет корректной.

Шаг 4. Посчитали экономию на один платёж

Экономия в одной операции — это разница между тем, сколько стоило разнести платёж “до”, и сколько стоит “после”, с учётом того, что часть потока проходит автоматически, а часть уходит в исключения.

Идея расчёта такая:

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

Шаг 5. Масштабировали на поток и добавили эксплуатационные затраты

Чтобы получить годовой эффект:

• умножили экономию на один платёж на количество платежей за год;
• вычли эксплуатационные расходы (инфраструктура, сопровождение правил/справочников, мониторинг) — в расчёте на период.

Шаг 6. Посчитали окупаемость

Окупаемость считали стандартно:

• разовый бюджет внедрения делили на ежемесячную экономию;
• дополнительно считали ROI на горизонте года, чтобы сравнить с альтернативами (найм/аутсорс/доработка учётной системы).

Что это даёт

Такой расчёт хорош тем, что он:

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

Следующие шаги: новые возможности ИИ для управления дебиторской задолженностью

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

1) «Сколько недоплатили?» — анализ вычетов, удержаний и дисконтов

Если у заказчика уже есть сверка «План/Факт»:
мы не заменяем её, а добавляем «умный слой» — автоматическое объяснение причин расхождений и маршрутизацию разборов:

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

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

Цель: сократить ручные проверки расхождений и ускорить закрытие актов сверки.

2) «За что именно заплатили?» — обработка пакетных платежей

Если у Заказчика уже есть частичное разнесение платежей, усиливаем его обработкой «спорных» случаев:

• распознавание пакетных платежей по тексту и шаблонам;
• разложение одной суммы на несколько объектов с объяснением логики (почему именно так распределили);

Если функции нет:
вводим модуль автоматического “дробления” и привязки платежа к нескольким договорам/начислениям.

Цель: исключить ручное дробление сумм и повысить прозрачность взаиморасчётов.

3) «Когда мы получим остальное?» — прогнозная аналитика и управление средним сроком погашения дебиторской задолженности

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

• прогноз дат закрытия задолженности по контрагентам/договорам;
• оценка ожидаемого денежного потока по периодам;
• ранжирование рисков и сигналов (у кого прогнозируем просрочку, где нужна проактивная работа).

Если функции нет:
строим прогнозный контур на истории оплат и поведении контрагентов.

Цель: внедрить инструмент управления ликвидностью и системно снижать средний срок погашения дебиторской задолженности.

4) «Как связаться с тем, кто ошибся в платёжке?»

Если у заказчика уже есть каналы общения (почта, CRM, электронный документооборот):
мы их не заменяем, а собираем в единое окно по спорным платежам:

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

Если функции нет:
встраиваем базовый контур коммуникации и учета статусов разборов.

Цель: сократить время урегулирования спорных ситуаций с дней до часов.

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

Заключение: ИИ в финансах — от «длинных проектов» к быстрому результату

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

Три причины, почему внедрение сработало:

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

Дальнейшее развитие логично расширяет решение до поддержки сквозного процесса «от счёта до денег (Invoice-to-Cash)»: обработка расхождений и удержаний, разбор пакетных платежей, прогнозирование поступлений и работа со спорными случаями.

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