Как я разбиралась в расхождениях ожидаемых платежей

Когда прогноз расходится с ожиданиями

В EdSofa я работаю с аналитикой платежей в Yandex DataLens и готовлю данные в PostgreSQL. Бизнесу важно видеть не только уже прошедшие операции, но и ожидаемые поступления: когда планируется платёж, состоялся ли он и есть ли задолженность. В одном из отчётов при просмотре будущего периода часть ожидаемых платежей отсутствовала. Итоговая цифра выглядела неверно, но сама по себе не показывала, на каком шаге теряются данные.

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

Почему проверять нужно не только сумму

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

В работе над отчётностью я исследую связи между платежами, планами и клиентами, готовлю SQL-датасеты и проверяю расчёты DataLens на конкретных записях. В этой задаче движение от итогового показателя к составу строк помогло локализовать проблему именно в отборе. Такой способ проверки полезен и для других платёжных метрик: сначала понять, какие записи должны участвовать, затем проверить формулу и только после этого интерпретировать общий итог.

Граница между текущим и историческим планом

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

Результат и следующий шаг

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

Для ревью перед публикацией

• Подтвердить, как проверяли результат после изменения условия отбора.
• Уточнить статус исторической модели план-факт: проектирование, внедрение или дальнейшая работа.
• Выбрать безопасный учебный пример без реальных клиентов и внутренних правил.