Управление ликвидностью: как увидеть будущие платежи до появления заявок на оплату

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

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

Альтернатива – планирование от потребности (demand-driven planning). Подход меняет парадигму: все участники процесса, от закупщиков до казначеев, видят будущие обязательства на этапе, когда бизнес только формирует планы, а не выставляет счета. ПДДС (плановое движение денежных средств), о котором идёт речь в этой статье, – частный случай более широкой концепции планирования от потребности (demand-driven planning), охватывающей стык закупок, бюджетирования и управленческого учёта. В следующих публикациях мы раскроем концепцию шире; в этой статье сфокусируемся как это работает на примере казначейства: как выстроить архитектуру планового движения денежных средств, чтобы превратить казначейство из регистратора фактов в проактивный центр управления ликвидностью, а бизнес-подразделения – из «потребителей услуг» в участников планирования.

Ловушка реактивного режима: почему казначейство видит платежи слишком поздно

В классической модели ПДДС (плановое движение денежных средств) часто строится «снизу вверх»: подразделения подают заявки, казначейство их агрегирует. Но к моменту подачи заявки на оплату (ЗнО) обязательство уже сформировано. Если у компании нет свободных средств, казначею приходится в срочном порядке привлекать дорогой овердрафт, использовать факторинг, либо эскалировать проблему на правление.

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

Сдвиг горизонта: от потребности к платежу

Решение – единый функционал-агрегатор документов ПДДС (плановое движение денежных средств), который выступает «хранителем данных». Методология меняется: планирование начинается не от момента выставления счёта, а от формирования потребности в закупке.

Цепочка формирования обязательства и её проекция в ПДДС

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

План — формирование обязательства

1. Этап 1 Потребность инициатива бизнес-подразделения
   ПДДС
2. Этап 2 Тендер выбор поставщика, согласование условий
   ПДДС
3. Этап 3 Договор график платежей фиксирует обязательства
   ПДДС
4. Этап 4 Заказ фиксация потребности в системе
   ПДДС
5. Этап 5 Поступление подтверждение факта исполнения
   ПДДС

Документ-агрегатор ПДДС Консолидирует плановые графики, реестры договоров и фактические остатки — в казначейском контуре холдинга

план → факт

Факт — исполнение платежа

Этап 6 Заявка на оплату объект факта платежа — фиксирует переход планового обязательства в реальную оплату

Факт платежа

• Серые горизонтальные стрелки — последовательная передача данных между этапами цепочки (план).
• Синие вертикальные стрелки — формирование плановой записи ПДДС на каждом этапе.
• Синяя линия под блоками ПДДС — поток данных в документ-агрегатор.
• Коричневая стрелка от агрегатора к Заявке — переход плана в факт: плановое обязательство реализуется как платёж.
• Заявка на оплату не входит в ПДДС — это отдельный объект факта платежа.

Реальная цепочка формирования обязательства выглядит так:

1. Потребность – инициатива бизнес-подразделения: «нужно закупить сырьё, оборудование, услуги».
2. Тендер или закупочная процедура – выбор поставщика, согласование условий.
3. Договор и график платежей юридически фиксирует обязательства.
4. Заказ на закупку / спецификация фиксирует потребность в системе и связывает её с графиком платежей по договору.
5. Поступление товара или услуг подтверждает факт исполнения.
6. Заявка на оплату – финальная точка, которая теперь не сюрприз, а ожидаемое событие.

Информация не вбивается в казначейскую систему вручную. Выстраивается непрерывная логическая цепочка, где системные документы последовательно генерируют друг друга. Так ПДДС консолидирует плановые графики платежей по договорам и реестры потребностей, а казначей, кураторы договоров и закупщики видят конкретные обязательства, привязанные к датам, контрагентам и статьям БДР/БДДС, причём на этапе, когда договор ещё не подписан, а потребность только формируется.

Такие связки ПДДС мы выстраивали в крупных промышленных холдингах, в компаниях из секторов ГМК и ТЭК, где ERP-ландшафт построен на базе SAP. Ключевая сложность: модуль закупок (MM) и модуль казначейства (TRM) в стандартной поставке SAP не «разговаривают» друг с другом в части плановых платежей. Потребность, зафиксированная в заявке на закупку (Purchase Requisition), не порождает плановую запись в ПДДС автоматически. Чтобы это заработало, требуется кастомная доработка: связка через условия оплаты в договоре, график поставок и пользовательские поля в заказе на закупку, которые «протаскивают» плановую дату платежа в казначейский контур. Аналогичная логика применима и в 1С, хотя там архитектура интеграции иная.

От фиксации к моделированию: платёжный календарь и сценарии закрытия кассового разрыва

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

• При прогнозируемом дефиците – сценарии ликвидации (перенос дат некритичных платежей, внутренние займы между контурами холдинга, операции кэш-пулинга, использование факторинга);
• При прогнозируемом профиците – размещение средств на депозите overnight или досрочное погашение существующих активных кредитов.

Базовый функционал сценарного моделирования есть «из коробки» в некоторых ERP-системах, в том числе в 1С:ERP/УХ, но он сильно ограничен. Модуль «Платежный календарь» в типовой поставке работает с уже созданными заявками на расходование денежных средств. Потребности на этапе их формирования – до договора, до заказа на закупку – в стандартный контур не попадают. Ценность появляется, когда функционал расширяется: система анализирует не только поданные заявки, но и планы закупок, графики договоров, тендерные процедуры. Именно такую расширенную модель мы реализуем в проектах.

При типовом сценарии, который мы регулярно моделируем, казначей видит в Платежном календаре (используя функционал ПДДС как источников данных), например, что через 10-12 дней ожидается кассовый разрыв около 130-140 млн руб. – платёж за оборудование наложился на выплаты по НДС и другим налогам. Система анализирует позиции и предлагает три варианта:

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

Казначей выбирает вариант, утверждает его одним кликом, и система автоматически формирует поручения. Без ПДДС этот разрыв обнаружился бы за два дня, и единственным вариантом остался бы овердрафт под рыночную ставку.

Почему внедрение ПДДС не запускается нажатием кнопки: типичные разрывы в процессах

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

Типичные разрывы, которые приходится устранять:

1. Невыровненная НСИ и отсутствие центрального ведения НСИ. Справочники контрагентов, статей БДДС и счетов ведутся в нескольких системах параллельно, без единого центра, а дочерние общества заводят справочники самостоятельно. Один и тот же поставщик в ERP-системе заведён как «ООО “Ромашка”», а в казначейской системе – как «Ромашка ООО». Система сама не может сопоставить плановый платёж с фактическим, и это приходится делать руками.
2. Разрыв между шаблоном и реальностью. Головная компания спускает единый шаблон процесса отражения платежей, но на местах его не соблюдают, и каждая дочерняя компания адаптирует процесс под себя. Центр узнаёт об этом только на этапе консолидации, когда данные уже не сходятся. Иногда приходится тратить недели для того, чтобы убедить руководство филиалов или дочерних компаний на работу в общем шаблоне.
3. Закупки не привязывают заказы к договорам. Заказ создаётся «в воздух», система не понимает, какой график или условие оплаты применять.
4. Потребность не фиксируется в системе. Бизнес-подразделения формируют потребность «на словах» или в Excel, и она не попадает в ПДДС до момента создания заказа.
5. Ручное управление статьями ДС. Подразделения при создании заказов выбирают статьи БДДС наугад, что ломает аналитику и прогнозирование.

Часть этих проблем встречается даже у гигантов с высоким уровнем ИТ-зрелости, не говоря о более мелких и менее зрелых компаниях. Только проработав методологию сбора данных и устранив эти пробелы, можно получить систему, которая формирует единую картину ликвидности холдинга за считанные минуты.

3 шага для перехода от реактивного к проактивному управлению ликвидностью

Чтобы перевести казначейство и бизнес-подразделения из реактивного режима в проактивный, начните с трёх шагов.

1. Аудит договоров и потребностей. Проверьте, какая доля обязательств компании описана жёсткими графиками и условиями оплат, а не размытыми условиями. Оцените, какая часть потребностей фиксируется в системе до этапа договора.
2. Связка «Потребность – Заказ – Платёж». Поставьте ИТ- и закупочному блоку задачу: обеспечить автоматическое отражение утверждённой потребности в плановом ПДДС, а затем – автоматическое отражение заказа на закупку.
3. Тестовый периметр. Не пытайтесь охватить всю компанию сразу. Возьмите один критичный вид закупок (например, сырьё или логистику) и выстройте сквозную цепочку от потребности до платежа по нему.

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

В следующей статье мы раскроем концепцию планирования от потребности (demand-driven planning) шире – на стыке закупок, бюджетирования и управленческого учёта. Покажем, как выстроить сквозную цепочку от стратегии компании до ежедневных платежей. А пока начните с трёх шагов, описанных выше. Даже один из них, доведённый до конца, изменит работу казначейства.

Мнение авторов может не совпадать с мнением редакции.