Управление дебиторской задолженностью в B2B: рабочий процесс

Учет показывает долг, управление отвечает за следующий шаг

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

1С:ERP уже умеет учитывать фактическую и планируемую задолженность, детализировать взаиморасчеты, формировать акты сверки и анализировать долг по срокам. Поэтому отдельный рабочий контур нельзя продавать как замену учету. Его смысл появляется там, где финансовый факт нужно связать с обещанием клиента, неподписанным документом, ответственностью между отделами и конкретным действием на сегодня.

• учет: сколько должны, по какому объекту и с какого срока
• управление: что мешает оплате и кто отвечает за движение
• контроль: какое событие ожидается и в какую дату
• эскалация: какое решение нельзя принять на уровне исполнителя

Соберите исходную картину до настройки правил

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

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

• дата актуальности выгрузки
• сумма и непогашенный остаток
• договорный срок или условие его наступления
• статус УПД, акта или сверки
• последнее подтвержденное событие
• роль владельца внутри компании

Разделите задолженность по рабочей причине

Возраст долга важен, но сам по себе не объясняет действие. Две суммы с одинаковой просрочкой могут требовать разной работы. В одном кейсе клиент готов платить после исправления УПД, в другом спорит с объемом работ, в третьем назвал конкретную дату, а в четвертом перестал отвечать. Если все четыре строки получают статус «просрочено», команда снова восстанавливает контекст вручную.

Для первого цикла достаточно шести–восьми причин. Справочник должен быть коротким и влиять на маршрут: документ, обещанная дата, частичная оплата, спор, внутреннее решение, отсутствие следующего шага, отсутствие реакции, передача специалисту. Категории вроде «в работе» и «у менеджера» бесполезны, потому что не объясняют ни препятствие, ни ожидаемое событие.

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

Назначьте владельца кейса, а не владельца всей дебиторки

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

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

• финансы: приоритет, остаток, качество очереди и контроль
• продажи или аккаунт: контакт, обещание и клиентский контекст
• бухгалтерия: УПД, акты, сверки и корректность разнесения
• проект: замечания по объему и результату работ
• руководитель: лимит, стоп работ, график или переход к специалисту

Сделайте следующее действие проверяемым

Запись «связаться с клиентом» не является хорошим следующим действием: неизвестно, зачем связываться и какой результат завершит задачу. Проверяемая формулировка содержит объект, ожидаемый результат и срок. Например: «получить подтверждение даты подписи УПД до 15:00», «проверить поступление 420 тыс. рублей после платежного дня» или «подготовить для директора два варианта по новым работам».

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

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

Организуйте короткий ежедневный цикл

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

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

• утро: сформировать очередь по наступившим сигналам
• день: выполнить действия и зафиксировать источник ответа
• эскалация: передать руководителю контекст и варианты
• вечер: вернуть незавершенные кейсы с новой причиной

Запустите первый контур за 14 дней

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

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

• дни 1–2: структура и обезличивание данных
• дни 3–4: причины, роли и пороги эскалации
• дни 5–10: ежедневная очередь и фиксация пробелов
• дни 11–13: повторные переносы и решения руководителя
• день 14: go, repackage или stop

Измеряйте качество процесса до денежного эффекта

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

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

• доля кейсов с причиной, владельцем и следующей датой
• сумма по просроченным внутренним контролям
• медианное время до первого действия
• повторные обещания без решения
• кейсы, возвращенные в сверку из-за недостоверного факта

Когда отдельный контур не нужен

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

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