AI-агент для автоматизации дебиторки: как бот снижает просрочку на 30% за квартал
Что происходит с дебиторкой прямо сейчас
За пять лет, с 2020 по 2025-й, просроченная дебиторская задолженность в России выросла на 110%. Это не тренд, который "надо мониторить". Это уже рабочая реальность большинства B2B-компаний с портфелем хотя бы в сотню контрагентов.
Ручной контроль ломается именно здесь: не на пяти клиентах и не на двадцати. Где-то между 80 и 200 строками в таблице менеджер начинает путать сроки, забывает зафиксировать ответ после звонка, откладывает напоминание, потому что "позвоню завтра". Завтра превращается в затянутые недели на одном просроченном счёте. При автоматизации тот же счёт закрывается заметно быстрее.
Разница в две-три недели на одном счёте звучит терпимо. Умножь на 40 открытых позиций одновременно, и получишь кассовый разрыв, который финансовый директор объясняет совету директоров в конце квартала.
Закупки автоматизируют, чтобы тратить меньше, дебиторку автоматизируют, чтобы получать быстрее то, что уже заработано. Два разных мотива, одинаковый уровень срочности.
Просроченная дебиторка съедает оборотный капитал быстрее, чем любой другой операционный сбой.
Как устроен AI-агент для работы с дебиторкой
Простейший чат-бот ждёт, пока человек напишет первым. AI-агент для дебиторской задолженности работает иначе: он сам инициирует контакт, выбирает канал, отправляет сообщение и записывает результат в систему. Без оператора в цепочке.
Триггер приходит из ERP или CRM. Допустим, в 1С зафиксировано: счёт просрочен на 7 дней, контрагент из сегмента "стратегические клиенты". Агент получает это событие, достаёт из базы историю предыдущих коммуникаций с этим контрагентом, смотрит, как тот реагировал раньше (отвечал на email, игнорировал SMS), и выбирает подходящий тон и канал. Потом генерирует текст через LLM и отправляет. Всё это без единого клика со стороны сотрудника.
Архитектурно агент собирается из четырёх слоёв.
Первый: языковая модель. Она генерирует текст письма или сообщения под конкретный контекст. Не шаблон с подставленным именем, а текст, адаптированный под сумму, срок просрочки, тон предыдущей переписки и юрисдикцию контрагента.
Второй: модуль интеграции. Без него агент слепой. Коннекторы к 1С, SAP, Bitrix24 или любой другой системе учёта дают агенту данные: кто должен, сколько, с какого числа, были ли частичные оплаты.
Третий: планировщик задач. Он управляет очерёдностью: когда отправить напоминание, когда сделать паузу, когда повторить с более жёстким тоном.
Четвёртый: блок аналитики и эскалации. Если после двух-трёх касаний реакции нет, агент не продолжает бесконечно слать письма. Он эскалирует задачу: передаёт менеджеру, помечает контрагента как проблемный, или инициирует подготовку претензии.
Принципиальное отличие от чат-бота в том, что агент помнит контекст. Чат-бот обрабатывает один запрос. Агент видит всю историю: этот контрагент платил вовремя восемь месяцев, потом начал задерживать, в прошлый раз ответил после второго напоминания в мессенджере. Эта память и контекст в работе AI-агента меняет стратегию коммуникации.
IBM в исследовании 2025 года назвала цифру: к 2027 году AI-агенты закроют больше половины рутинных финансовых операций в крупных компаниях. Сейчас, в 2026-м, часть компаний в России и за рубежом уже запустила такие системы в продакшн, и разрыв между теми, кто автоматизировал эту работу, и теми, кто не начал, виден в операционных метриках.
Ядро системы: ERP отдаёт долговые данные, языковая модель формирует текст, каналы доставляют его, аналитика замыкает цикл.
Сценарии работы: что именно делает бот
Разберу конкретно, без абстракций. Бот работает по временной шкале: каждый шаг привязан к числу дней до или после срока оплаты, а не к настроению менеджера.
За 3-5 дней до срока. Бот отправляет счёт повторно и задаёт простой вопрос: всё ли в порядке, нет ли вопросов по сумме. Это не давление. Это страховка от ситуации "я не получил счёт" или "забыл уточнить реквизиты". Этот шаг закрывает часть потенциальных просрочек ещё до того, как они случились.
В день просрочки. Тон нейтральный. Бот называет конкретную сумму, срок, реквизиты для оплаты. Никаких обвинений, никакого нагнетания. Просто факты: "Счёт №147 на 84 000 рублей не поступил. Вот реквизиты."
На 7-й и 14-й день. Здесь тон меняется. Второе сообщение уже упоминает договорные условия: штрафы, пени, возможные последствия. Третье добавляет конкретику: сумму накопленной пени на текущую дату. Бот не угрожает, но перестаёт быть мягким.
Эскалация. Если после 14 дней реакции нет, бот не продолжает слать сообщения в пустоту. Он передаёт задачу живому менеджеру или юристу и вместе с задачей отдаёт карточку: кто контактное лицо, сколько касаний было, какие каналы использовались, был ли хоть какой-то ответ. Менеджер сразу видит историю и не начинает разговор с нуля. Про логику такой передачи подробно написано в статье про квалификацию лидов и передачу менеджеру в AI-агенте для продаж: те же принципы работают и в AR-сценариях.
Логика эскалации выглядит примерно так:
# Псевдокод сценария эскалации
if days_overdue >= 1 and days_overdue < 7:
send_message(channel='email', template='reminder_soft')
elif days_overdue >= 7 and days_overdue < 14:
send_message(channel='whatsapp', template='reminder_firm')
add_penalty_note()
elif days_overdue >= 14:
escalate_to_manager(
reason='no_response',
history=get_contact_log()
)
Обрати внимание на get_contact_log(). Это не декоративная функция. Она тянет реальную историю: дату каждого касания, канал, статус доставки, был ли прочитан WhatsApp-message. Менеджер получает не просто "клиент не платит", а полный таймлайн.
Частичная оплата. Клиент заплатил половину? Бот фиксирует входящий платёж, вычитает из долга и пересчитывает остаток с учётом накопленной пени. Дальнейшие напоминания идут уже с новой суммой. Это снимает целый класс конфликтов вида "вы требуете полную сумму, хотя я уже платил".
Весь сценарий линейный только на бумаге. В реальности бот параллельно ведёт десятки таких цепочек по разным контрагентам, и каждая находится в своей точке временной шкалы.
Каждый следующий шаг эскалации меняет тональность и канал, а не просто повторяет тот же текст громче.
Выбор канала: email, мессенджеры или звонки
Начну с цифр, потому что интуиция здесь обманывает. Email в B2B-сегменте открывают в 28-35% случаев. Звучит не очень, но для делового документооборота это нормально: контрагент получил, прочитал, занёс в CRM. Формальный статус письма никуда не делся, и для юридически значимой переписки email до сих пор предпочтительней.
WhatsApp и Telegram показывают 70-85% открываемости. Разница кратная. Но здесь есть условие, которое часто игнорируют: нужно явное согласие контрагента на общение через мессенджер. Без этого вы рискуете нарваться на жалобу, особенно если долг связан с физлицом. С юрлицами проще, многие компании сами указывают мессенджер как предпочтительный канал, но всё равно лучше зафиксировать это явно.
Голосовые AI-звонки с синтезом речи закрывают сегмент долгов до 50 тыс. руб. Живой оператор на такой сумме экономически не оправдан: стоимость звонка съедает маржу. Автоматический звонок с распознаванием ответа работает здесь как конвейер. Качество синтеза речи в 2026 году достаточное, чтобы человек не бросал трубку сразу.
Правильная цепочка выглядит так: email, потом мессенджер, потом звонок, потом передача живому сотруднику. Каждый следующий шаг только если предыдущий не дал ответа за 48 часов. Не нужно валить все каналы одновременно, это создаёт ощущение агрессии и портит отношения с контрагентом, которого вы, скорее всего, хотите сохранить.
Отдельно про время отправки в мессенджерах. В 2026 году сложился неписаный, но уже устойчивый стандарт деловой переписки: сообщения отправляются с 9:00 до 19:00 по часовому поясу получателя. Написать в мессенджер в 22:00 с напоминанием о долге, пусть даже корректным по тону, это гарантированный способ получить раздражённый ответ или полный игнор. Сервисы автоматической рассылки умеют определять часовой пояс по номеру телефона или адресу, настройку стоит включить принудительно.
Цифры открываемости объясняют, почему мессенджеры и звонки работают там, где email давно перестал.
Интеграция с учётными системами
Агенту по взысканию дебиторки нужно совсем немного данных, чтобы начать работу: ИНН контрагента, сумма долга, дата выставления счёта, дата просрочки и имя контактного лица. Всё. Если хотя бы одного из этих полей нет, агент либо ошибётся в сегментации, либо напишет письмо без обращения по имени, что сразу убивает тон коммуникации.
Откуда брать эти данные зависит от того, что стоит у клиента. В моей практике чаще всего встречается 1С:Управление торговлей и 1С:ERP. У обеих есть OData API, и это самый чистый способ забирать просроченные счета без промежуточных выгрузок. SAP FI подключается через RFC или REST в зависимости от версии и того, насколько щедро настроены права доступа. Bitrix24 и amoCRM дают webhook при смене статуса сделки или счёта, и это удобно: агент получает событие сразу, а не ждёт планового опроса.
Для систем, где нет нормального API (такое бывает со старыми конфигурациями 1С или самописными ERP), я использую экспорт в Excel по расписанию через планировщик задач. Некрасиво, но работает. Главное, чтобы расписание было не реже раза в час, иначе агент будет работать с устаревшей картиной.
Запрос к OData API 1С выглядит примерно так:
import requests
response = requests.get(
'https://1c.company.ru/odata/standard.odata/Document_CustomerInvoice',
params={
'$filter': "Status eq 'Overdue' and DueDate lt datetime'2026-05-01T00:00:00'",
'$select': 'Number,Counterparty,Amount,DueDate,ContactPerson'
},
auth=('user', 'pass')
)
overdue_invoices = response.json()['value']
Фильтр по DueDate lt datetime'2026-05-01T00:00:00' нужно подставлять динамически, а не хардкодить. Я обычно беру datetime.utcnow() и вычитаю нужный период просрочки прямо в коде перед вызовом.
Теперь про обратную запись, и вот тут у большинства реализаций провал. Агент отправил письмо или звонок? Это событие должно немедленно лечь обратно в CRM: дата отправки, канал (email, WhatsApp, звонок), что ответил контрагент, новый статус долга. Без этого система потеряет связность уже через два-три цикла напоминаний.
Самая частая поломка, которую я видел: агент продолжает слать напоминания по счетам, которые закрыли вручную прямо в 1С. Менеджер провёл оплату, статус в учётной системе сменился на "Оплачен", а агент об этом не знает и на следующий день пишет должнику снова. Контрагент злится, менеджер краснеет. Лечится это только двусторонней синхронизацией: агент не просто читает данные из учётной системы, он туда же пишет результаты каждого взаимодействия и перед каждой новой отправкой перепроверяет актуальный статус счёта.
Webhook при изменении статуса счёта в этом смысле лучше, чем поллинг: 1С или CRM сами толкают событие агенту, и он немедленно останавливает коммуникацию по закрытому долгу. Если нужно быстро собрать прототип такой интеграции, хорошим стартом будет архитектура AI-агента на n8n с подключением к внешним базам данных.
Требования 152-ФЗ при автоматизации коммуникаций
Когда бот сам пишет клиенту "Ваш заказ готов" или "Напоминаем о встрече", он работает с персональными данными. ФИО, номер телефона, email контрагента, всё это попадает под действие 152-ФЗ. И если раньше компании на это закрывали глаза, то в 2026 году цена вопроса стала другой.
С 1 июля 2025 года в силе прямой запрет: персональные данные граждан РФ нельзя хранить в зарубежных базах данных. Это касается напрямую облачных AI-сервисов. Если ваш бот работает через американский или европейский облак и туда же пишет историю переписки с именами и телефонами клиентов, это нарушение, вне зависимости от того, насколько удобен интерфейс сервиса. Серверы должны быть в России. Точка.
Штрафы в этом году выросли кратно. Первичное нарушение для юридического лица обходится до 300 тыс. руб., повторное, до 1 млн руб. Раньше компании могли отделаться суммами, которые проще было заплатить, чем перестраивать инфраструктуру. Сейчас арифметика другая.
Отдельный момент, согласие на обработку персональных данных. Перед тем как бот отправит первое автоматическое сообщение физлицу, у вас должно быть зафиксированное согласие именно на эти цели. Не абстрактное "согласен на обработку данных" из формы регистрации, а согласие, покрывающее автоматические коммуникации. Устная договорённость и галочка "я принимаю условия" без расшифровки не считаются.
Чек-лист для тех, кто запускает рассылки через бота:
- Согласие физлица зафиксировано и охватывает автоматические сообщения.
- Данные хранятся на сервере с российской юрисдикцией.
- В каждом сообщении есть механизм отказа от коммуникации, кнопка, команда или явная инструкция.
Третий пункт часто упускают. Регулятор смотрит не только на то, как вы собрали данные, но и на то, дали ли вы человеку выйти из коммуникации без звонков в поддержку и объяснений.
Без проработки требований 152-ФЗ автоматизированные рассылки превращаются в регуляторный риск с реальными штрафами.
Метрики: как измерить эффект от AI-агента
Запускать AI-агента без измерений, всё равно что тушить пожар с закрытыми глазами. Ниже пять цифр, которые я смотрю в первую очередь.
DSO (Days Sales Outstanding), среднее число дней от выставления счёта до фактической оплаты. Это главная метрика для AR-команды. При внедрении агента ориентир такой: минус 20-35% за первые три месяца. Если через 90 дней DSO не сдвинулся, что-то сломано в логике сценариев или в интеграции с учётной системой. Не в самом боте.
Доля просроченной дебиторки в общем портфеле. Считать еженедельно, не раз в квартал. Ежеквартальный срез показывает уже последствия, а не причины. Еженедельный дашборд даёт возможность заметить рост на 3-4 процентных пункта раньше, чем он станет проблемой.
Процент эскалаций на живого менеджера. Агент должен решать вопрос сам, а не быть дорогим маршрутизатором. Если эскалации выше 40%, это сигнал: либо сценарии написаны слишком осторожно, либо карточки контрагентов содержат мусор (неверные контакты, устаревшие условия договора). Разбирать надо именно причину, а не просто снижать порог.
Стоимость одного касания. Автоматическое сообщение обходится в разы дешевле, чем звонок менеджера с учётом его рабочего времени и накладных расходов. При портфеле в 500 активных контрагентов и трёх касаниях в цикл цифры складываются быстро.
Конверсия напоминания в оплату по каждому каналу отдельно. WhatsApp, email, СМС, голосовой обзвон дают принципиально разные результаты в зависимости от сегмента клиентов. Я видел случаи, когда email давал 6% конверсии, а WhatsApp по той же базе выдавал 31%. Агрегированная цифра "по всем каналам" такую картину скрывает. Смотреть нужно по каждому каналу отдельно, неработающие отключать без сентиментов и перераспределять бюджет туда, где конверсия реальная.
Типичные ошибки при внедрении
Самая частая ошибка, которую я вижу на проектах: компания берёт один сценарий, натягивает его на всю клиентскую базу и нажимает "запустить". Через неделю звонит разъярённый директор сети супермаркетов, которому прилетело то же уведомление, что и физлицу с долгом 800 рублей. Отношения испорчены, сделка под угрозой.
Крупный стратегический партнёр требует отдельного сценария: персонализированного тона, учёта истории отношений, иногда ручного контроля перед отправкой. Разовый покупатель на мелкую сумму терпит автоматику. Смешивать их в одну очередь нельзя. Как выстраивать разные сценарии под разные сегменты аудитории с учётом контекста, хорошо показано в руководстве по проектированию промптов для AI-агента поддержки клиентов: там те же принципы сегментации.
Вторая проблема: данные. Компании годами копят в CRM мусор. Устаревшие контакты, задвоенные записи, телефоны уволившихся сотрудников. Бот честно отправит напоминание всем подряд. Кто-то чужой получит сообщение про "вашу задолженность 150 000 рублей" и напишет в соцсети. Перед запуском нужна чистка базы, даже если это занимает неделю ручной работы.
Обратная запись в учётную систему, это отдельная боль. Клиент оплатил счёт утром. Бот не знает об этом, потому что синхронизация настроена раз в сутки или не настроена вообще. Вечером клиент получает напоминание про "неоплаченный" долг. Это прямой репутационный ущерб, который никакими извинениями быстро не закрыть. Синхронизация должна быть максимально близкой к реальному времени.
С тоном первого сообщения тоже регулярно перегибают. Практика показывает: люди часто просто забыли, и им достаточно вежливого напоминания без давления. Мягкое первое касание закрывает долги без конфликта значительно чаще, чем агрессивный старт. Но некоторые команды сразу ставят жёсткие формулировки: "в случае неоплаты будем вынуждены..." Это работает хуже и убивает лояльность тех, кто задержал платёж случайно.
И последнее: время отправки. Сообщение в 23:00, это не недосмотр, это скандал. Человек получает уведомление про деньги поздно ночью, злится, блокирует контакт и пишет жалобу. В России отправка коммерческих сообщений после 22:00 ещё и регулируется законодательством. Ограничение по времени отправки должно стоять в настройках с первого дня, а не добавляться после первого инцидента.
Две типичные ошибки при запуске AI-агента показывают, почему синхронизация с ERP и тайминг критичны с первого дня.
Реальный кейс: снижение просрочки на 30% за квартал
Расскажу про конкретный проект, который мы запустили в конце 2025 года. Производственная компания, 340 активных контрагентов. Не гигант, но и не малый бизнес: дебиторка живая, оборачиваемость важна, каждый лишний день в цикле сбора реально стоит денег.
На старте картина была такая: DSO 47 дней, 23% дебиторки висело в просрочке. Два менеджера по 3 часа в день звонили должникам. Вручную. По списку из Excel. Это не работа с долгами, это конвейер напоминалок.
Мы построили AI-агента на базе GPT-4o с прямой интеграцией в 1С:ERP. Агент вытаскивает из системы актуальные данные по каждому счёту, смотрит историю платежей контрагента и выбирает один из трёх сценариев коммуникации. Первый сценарий: надёжный плательщик с разовой задержкой, веж
