директор и машина · финансы · запись № 044 · 24 августа 2026 · Давид Герштейн

Дебиторка растёт: разбор кейса с предоплатой в крипте и требованием полного возврата

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные.

Дебиторка растёт из-за паники: клиент требует вернуть крипто-предоплату за день

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

У нас в практике был именно такой случай. Клиент внёс предоплату криптовалютой — 300 000 ₽, с учётом конвертации на счёт компании пришло 330 000 ₽ (курсовая наценка около 10%). Через несколько недель клиент потребовал вернуть всю сумму в течение одного дня, той же криптовалютой, ссылаясь на устное обещание менеджера «найти нужные корни» — формулировка, которая нигде не была зафиксирована. Юридически это была серая зона: обещание менеджера — не договор, но и молчать про него было нельзя.

Руководитель принял решение за час: вернуть 270 000 ₽, удержав 60 000 ₽ — расходы на уже выполненную работу и бонус менеджера. Логика была не «отдать всё, чтобы не судиться» и не «не отдавать ничего, потому что мы правы». Логика — посчитать реальные издержки и вернуть остаток быстро, чтобы не дать конфликту перерасти в публичный спор. Это разовое решение, а не система: оно сработало на конкретных 330 000 ₽. Вопрос, который встал сразу после — что делать, чтобы следующий такой случай не решался в ручном режиме за час до дедлайна.

Что решили сделать после этого случая

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

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

Неделя 1: фиксируем возвраты и чиним реферальную программу

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

Реестр возвратов сделали в той же таблице, где уже велась дебиторка — колонки: дата запроса, сумма к возврату, сумма фактического возврата, причина расхождения, кто согласовал. Ничего сложного, но именно этого не хватало в кейсе с криптовалютой: если бы реестр уже существовал, решение о 270 000 ₽ из 330 000 ₽ было бы принято по шаблону, а не с нуля. Автоматизация уведомлений партнёрам заняла по факту около 20 минут работы: бот в мессенджере стал сообщать рефералу о закрытии проекта сразу, а не когда клиент сам напомнит о деньгах. Маленькая правка, но она снимает половину напряжения вокруг реферальных выплат — партнёр видит начисление сразу, а не выясняет его постфактум.

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

Неделя 2: что сломалось

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

Разработчик настроил ежечасную сверку дат создания сделок в CRM — и обнаружил, что даты «мигрируют»: сдвиг варьировался от 18 до 36 часов при повторной синхронизации. Для дебиторки это критично: если дата возникновения долга скачет на полтора дня туда-сюда, любой отчёт «просрочка 30+ дней» становится приблизительным. Подробный разбор этой проблемы с Битрикс24 и что с ней делать — в отдельной статье: CRM врёт. Как я поймал Битрикс24 на сдвиге дат. Здесь одно правило: пока даты в CRM нестабильны, контроль дебиторки по срокам будет давать ложные тревоги и ложное спокойствие вперемешку.

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

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

ИИ-связка: ежедневный контроль дебиторки без ручного свода

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

Схема конвейера: Bitrix24-вебхук раз в сутки выгружает сделки со стадией «Ожидает оплату» в Google Sheets → Apps Script построчно отправляет данные в модель → модель возвращает классификацию риска и рекомендацию → результат пишется обратно в таблицу и дублируется алертом в Telegram, если риск высокий. Модель здесь нужна дешёвая — классификация 40-60 строк в день не требует дорогой рассуждающей модели, достаточно недорогого классификатора: задача чисто категориальная — сопоставить срок просрочки, сумму и историю платежей клиента с тремя уровнями риска.

Ты — ассистент финансового контроля дебиторской задолженности сервисной компании.
На входе — JSON одной сделки с открытой оплатой. Классифицируй риск неплатежа
и предложи следующее действие.

Правила:
- "высокий" риск: просрочка более 20 дней ИЛИ сумма выше 250000 ₽ с просрочкой от 10 дней
- "средний" риск: просрочка 5-20 дней, сумма любая
- "низкий" риск: просрочка менее 5 дней
- Если клиент платил с задержкой 3+ раза за последний год — риск повышается на одну ступень
- Ответ — строго JSON, без пояснений вне JSON

Входные данные:
{
  "deal_id": "48213",
  "client": "ООО Ромашка",
  "sum": 180000,
  "currency": "RUB",
  "due_date": "2026-08-20",
  "days_overdue": 12,
  "package_type": "Базовый",
  "payment_method": "bank_transfer",
  "manager_id": "M-04",
  "late_payments_last_year": 1
}

Пример ответа модели:

{
  "deal_id": "48213",
  "risk_level": "средний",
  "reason": "12 дней просрочки, единичная задержка в истории, сумма ниже порога высокого риска",
  "action": "напомнить менеджеру, звонок клиенту в течение дня",
  "escalate_to_finance": false
}

Инженерная обвязка простая и без внешних сервисов: сам Bitrix24-вебхук и Apps Script крутятся на стороне Google, ключ API модели хранится в свойствах скрипта, а не в коде таблицы. Если выгрузка падает — Apps Script пишет ошибку в отдельный лист «Errors» с таймстампом и шлёт алерт в тот же Telegram-чат, куда падают алерты по высокому риску; повторная попытка — по расписанию раз в час, без участия человека. Раз в неделю, перед планёркой по четвергам, Марина открывает не сырую выгрузку, а уже классифицированную таблицу — и видит только те строки, где риск средний или высокий.

Неделя 6: что показали цифры

Через 6 недель после запуска ежедневного дашборда доля дебиторки старше 30 дней снизилась с 24% до 11% — это оценка на основе данных дашборда, а не отдельный аудит. Сдвиг цифр дала связка «ежедневный дашборд + фиксация возвратов», вклад отдельно взятого ИИ-классификатора выделить нельзя. На диаграмме ниже — то же распределение по срокам просрочки в деньгах и сравнение доли просрочки старше 30 дней до и после внедрения дашборда.

Доля дебиторки старше 30 дней до внедрения ежедневного дашборда и через 6 недель после (оценка на основе данных дашборда).

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

Экономика: сколько стоило, что дало и где ломается

Внедрение обошлось в ~6 часов настройки разработчика (~9 000 ₽ разово) и ~500 ₽/мес на эксплуатацию, а суммарный эффект — около 133 000 ₽/мес (117 000 ₽ снижения риска дебиторки + 16 000 ₽ высвобожденного времени финансиста, оценка), не считая разового решения в 270 000 ₽ по кейсу с криптовалютой.

Формула для своего случая: риск зависшей дебиторки = доля сделок с просрочкой × средний чек × число сделок в месяц. Возьмём отдел из 8 менеджеров с чеком 180 000 ₽ и оборотом 9 млн ₽ в месяц — это около 50 сделок. Если 10% сделок зависает в оплате (5 сделок), риск зависшей дебиторки — 5 × 180 000 ₽ = 900 000 ₽ в месяц (оценка). Снижение доли просрочки 30+ дней с 24% до 11% на этом объёме эквивалентно освобождению около 117 000 ₽ в месяц (900 000 ₽ × 13 п.п.), которые раньше просто зависали дольше нужного.

Отдельно — время финансиста: ручной свод дебиторки по трём срезам занимал около 4 часов в неделю, это 16 часов в месяц; по ставке около 1000 ₽/час (типовая почасовая ставка финансиста) — это 16 × 1000 ₽ = 16 000 ₽/мес высвобожденного времени, которое теперь уходит на анализ аномалий, а не на сведение таблиц вручную. Часы финансиста при этом не сократились — они перераспределены на другую работу, поэтому эффектом «в деньгах» это можно считать только условно, как перенаправленную ценность, а не прямую экономию бюджета.

Ещё один ориентир — для тех, кто считает экономику через менеджеров, а не финансистов: менеджер обходится компании примерно в 124 000 ₽ в месяц (100 000 ₽ зарплаты плюс около 24 000 ₽ налогов, 48% от базовой ставки 50 000 ₽) — это около 775 ₽/час при 160 рабочих часах в месяц. Если автоматическая классификация риска освободит хотя бы 10% времени одного менеджера от ручной сверки дебиторки, это ещё около 12 400 ₽/мес на человека; этот эффект мы отдельно не измеряли, потому что основной вклад дал не классификатор, а дашборд и регламент возврата — цифры двух эффектов складывать не стоит, чтобы не задвоить экономику.

Стоимость внедрения: настройка вебхука, скрипта и промпта — около 6 часов работы разработчика, это разовая задача. При ставке около 1500 ₽/час (типовая почасовая ставка разработчика на подобных задачах) — это 6 × 1500 ₽ = 9 000 ₽ разово. На фоне суммарного эффекта около 133 000 ₽/мес разовые 9 000 ₽ окупаются меньше чем за сутки работы системы — порог входа несопоставимо ниже эффекта, даже если считать консервативно. Автоматизация уведомлений рефералам — отдельные 20 минут, без дополнительных вложений.

Эксплуатация классификатора при объёме 50-60 сделок в месяц — около 500 ₽ в месяц на токены: без контроля лимитов легко переплатить в 20 раз за инфраструктуру, которая при аккуратной настройке стоит около 500 ₽/мес, а не 10 000 ₽. Что мы не считаем эффектом: разовый возврат 270 000 ₽ клиенту по крипто-кейсу — это ускорение решения конкретного спора, а не ежемесячная экономия, и складывать эту сумму с эффектом дашборда нельзя — это запас, а не поток.

Чек-лист: с чего начать в понедельник

1. Завести реестр возвратов: дата запроса, сумма к возврату, сумма фактического возврата, причина, кто согласовал.
2. Настроить автоматические уведомления по обязательствам, которые задерживаются дольше суток — на боте или в CRM, это 20-30 минут работы.
3. Вывести три метрики дебиторки — объём, распределение по срокам, распределение по пакетам услуг — в отчётность, которую видно каждый день, а не раз в месяц.
4. Прогнать промпт-классификатор на текущей выгрузке сделок и сверить результат вручную на 10 строках, прежде чем доверять ему алерты.
5. Зафиксировать письменно, кто принимает решение о возврате и в каких пределах суммы — без этого правила каждый крупный возврат снова решается за час до дедлайна.
6. Поставить фиксированное время для разбора дебиторки — например, четверг 13:00 — и обсуждать на нём только цифры, у которых есть источник, а не оценки на глаз.

Частые вопросы

Дебиторка растёт что делать в первую очередь?

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

Клиенты не платят вовремя — как понять, где реальная проблема?

Разбить дебиторку по срокам возникновения и типам пакетов минимум за 2-3 месяца и искать аномалии в конкретных сегментах, а не смотреть на общую сумму — так нашли, что просрочка концентрируется в одном типе услуг.

Контроль дебиторской задолженности — с чего начать технически?

С ежедневной выгрузки сделок с открытой оплатой в таблицу (Bitrix24-вебхук или amoCRM API), классификации риска дешёвой моделью и алертом в мессенджер, если риск высокий — это 1-2 дня настройки.

#деньги #контроль и надёжность #ии и нейросети