Автоматизация дебиторской задолженности: реестр оплат и напоминания без дублей

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

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

Что автоматизировать в работе с дебиторской задолженностью

В процессе нужно разделить три операции.

1. Учёт обязательства. В реестре появляется счёт с покупателем, валютой, суммой и согласованным сроком. Эти сведения берут из источника, который компания назначила главным для выставленных счетов и договорных условий.
2. Сверка фактической оплаты. Банковское событие или запись платёжного провайдера сопоставляют со счётом. В расчёт попадает только подтверждённая и уникальная оплата.
3. Контакт с клиентом. После проверки остатка система выбирает разрешённый адресат и канал, готовит или отправляет сообщение в пределах согласованных полномочий и записывает результат в журнал.

Такое разделение не даёт событию коммуникации изменить финансовые данные. Например, фраза клиента «оплатим в пятницу» может запустить период тишины или задачу сотруднику. Однако это обещание не является подтверждённым платежом, поэтому остаток остаётся прежним.

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

Какие данные включить в реестр

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

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

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

Как сопоставлять оплаты и считать остаток

Основное правило можно записать обычной формулой:

остаток = max(0, сумма счёта − сумма уникальных подтверждённых оплат по этому счёту)

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

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

Частичная оплата. Каждый уникальный подтверждённый платёж уменьшает остаток один раз. После пересчёта меняется и сумма в следующем сообщении.

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

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

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

Как настроить согласованные напоминания

Напоминание состоит из четырёх независимых настроек.

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

Для каждого сообщения полезно хранить состояние:

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

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

Официальная документация Microsoft Dynamics 365 Finance описывает стратегический отбор счетов для действий по задолженности, шаблоны сообщений, выбор получателя, историю процесса и quiet days. Для функции последовательного прохождения шагов документация отдельно называет Dynamics 365 Finance версии 10.0.43 и новее. Это пример документированного устройства процесса, а не заявление о проверенной совместимости с системой конкретного заказчика. Доступные версии, права и API нужно проверять перед проектом.

Что делать при расхождениях и недоступном источнике

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

Банковские данные задерживаются. Реестр отмечает время последнего успешного обновления. Если свежесть данных не соответствует согласованному условию, сообщение остаётся запланированным или уходит на ручную проверку. Отсутствие нового события не доказывает отсутствие оплаты.

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

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

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

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

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

Учебный пример частичной оплаты и остановки напоминания

Ниже приведён синтетический пример, а не клиентский кейс, файл или результат внедрения Switch On AI.

Компания выставила условный счёт INV-001 на 60 000 рублей. В реестр последовательно поступили два подтверждённых платежа: P-001 на 20 000 и P-002 на 15 000.

1. До оплаты остаток равен 60 000 рублей.
2. После P-001: 60 000 − 20 000 = 40 000 рублей.
3. После P-002: 60 000 − 20 000 − 15 000 = 25 000 рублей.
4. Плановое сообщение пересчитывается и должно содержать остаток 25 000 рублей.

Как исключить повтор платежа

Предположим, источник снова прислал P-002 на 15 000 рублей с тем же идентификатором. Множество уникальных платежей остаётся {P-001, P-002}. Сумма учтённых оплат по-прежнему равна 35 000 рублей, а остаток — 25 000 рублей.

Расчёт 60 000 − 20 000 − 15 000 − 15 000 = 10 000 был бы ошибкой: одно банковское событие учтено дважды. Поэтому проверка уникальности должна выполняться до сложения сумм, а не после подготовки сообщения.

Как меняется состояние сообщения

После первой оплаты сообщение переходит из состояния «запланировано» в состояние «пересчитано после оплаты» с остатком 40 000 рублей. После второй оплаты оно снова пересчитывается — теперь до 25 000 рублей.

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

Как принять автоматизацию и обсудить внедрение

Приёмку лучше строить на событиях с заранее записанным ожидаемым результатом.

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

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

Switch On AI может разработать ИИ-помощника, бота или интеграцию для такой операции после проверки данных, доступных API и прав. Упомянутая документация вендора не подтверждает совместимость с конкретной системой, тарифом или конфигурацией заказчика — это выясняется отдельно.

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

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