Когда оплаты согласуются, но закупки “сверх лимита” всплывают только на счёте, и приходится выбирать между кассовым разрывом и конфликтом с бизнесом.
Вы строите контроль расходов и ликвидности, но регулярно получаете сюрприз: на этапе заявки на оплату выясняется, что обязательство уже создано и лимит давно превышен. В этой статье разберём разницу между контролем оплаты и контролем обязательств, покажем, где именно рождается перерасход, и как перенести контроль “влево” — на договор/закупку/заказ. Вы получите 2–3 работающих подхода, список ошибок, план внедрения на 60–90 минут и готовые скрипты, чтобы объяснить логику руководству и коллегам без войны за бюджеты.
Вызов: Управленческий вопрос на повестке
Вы можете идеально согласовывать платежи, но всё равно получать перерасход по лимитам из-за обязательств, которые появились раньше оплаты. Что делать с понедельника, чтобы контроль работал до возникновения платежа, а не “на финише”? Как донести до руководства, что контроль обязательств — это не бюрократия, а способ не создавать будущие кассовые разрывы?
Система координат: Глоссарий и основа методологии
Контроль оплаты — это проверка лимитов и полномочий на уровне счёта/заявки на оплату/платежа, когда расход уже почти неизбежен.
Контроль обязательств — это проверка лимитов и полномочий на уровне договора, заявки на закупку, заказа поставщику, заявки на обеспечение, то есть до заявки на оплату.
Обязательство — это решение компании “потратить” деньги в будущем, которое уже снижает доступный лимит, даже если деньги ещё не ушли.
Простыми словами: контроль оплаты отвечает “можем ли мы заплатить сейчас”, а контроль обязательств отвечает “можем ли мы вообще обещать этот расход, не провалив следующий месяц”. Контроль оплаты ловит проблему поздно, а контроль обязательств не даёт ей родиться.
Что включаем в модель
● Договор/заказ/заявка на закупку как точка возникновения обязательства, потому что именно там бизнес принимает решение, после которого платёж становится ожидаемым.
● Лимит/бюджет по статье и аналитикам, потому что без “границ” контроль превращается в обсуждение вкусов, а не правил.
● Сумма обязательств + сумма уже оплаченного, потому что лимит “съедается” не только оплатами, но и будущими обещаниями.
● Статусы согласования и полномочия, потому что контроль — это не запрет, а управляемая эскалация.
● Период лимита (месяц/квартал) и календарь поставок/работ, потому что обязательства часто “переезжают” между периодами и создают скрытые провалы.
Что НЕ включаем в модель
● Детальные расчёты себестоимости до копейки, потому что цель контроля — дисциплина принятия обязательств, а не идеальная калькуляция.
● Все возможные аналитики сразу, потому что избыточная детализация в начале приводит к обходу контроля и “ручным исключениям”.
Единица анализа — обязательство по документу и его владельцу лимита, потому что управленчески важно знать “кто создал будущий расход и на каком основании”.
Период — месяц с просмотром вперёд на 8–12 недель, потому что обязательства часто формируются заранее, а платятся позже, и именно это рождает кассовые разрывы.
Требуемая точность — по крупным статьям и источникам перерасхода (80/20), потому что точность в 99% на старте обычно стоит дороже, чем экономия от контроля.
Цель расчётов: Ответы на ключевые управленческие вопросы
● Почему по оплатам мы “в лимите”, а по факту перерасход уже неизбежен?
● Сколько будущих платежей уже законтрактовано, даже если заявок на оплату ещё нет?
● Где именно возникают закупки сверх лимита: на договоре, на заказе, на “срочной заявке”, на изменении объёма?
● Какие обязательства можно сдвинуть/пересобрать, чтобы не убить ликвидность следующего месяца?
● Как настроить правило: “обязательство можно создать только в лимите”, но оставить управляемые исключения для аварийных ситуаций?
Методология: Различные подходы к решению одной задачи
Подход 1. “Контроль только оплат” (барьер на выходе денег)
Цель — не допустить лишний платёж и сохранить ликвидность “сегодня”.
Что считаем — суммы заявок на оплату и фактические оплаты vs лимит периода.
Где обычно ломается/где ошибаются — обязательство уже создано, и на этапе оплаты выбор становится токсичным: либо платим “сверх лимита”, либо останавливаем операцию и получаем простой/штрафы.
Пример: закупка размещена на 6 млн при лимите 4 млн, но выявляется это только при счёте, и “спасти” лимит уже невозможно без срыва поставки.
Подход 2. “Контроль обязательств + контроль оплат” (два барьера: вход и выход)
Цель — не создавать будущий перерасход и при этом управлять ликвидностью в момент оплаты.
Что считаем — обязательства (договор/заказ/заявка на закупку) + оплаты в совокупности vs лимит, с разделением по периодам.
Где обычно ломается/где ошибаются — если нет чёткой точки, где обязательство считается “созданным”, контроль становится дырявым, а бизнес находит путь “мимо системы”.
Пример: на этапе заказа система показывает: лимит остался 1,2 млн, заказ на 2,0 млн требует эскалации, и решение принимается до того, как появится счёт.
Подход 3. “Резервирование лимита графиком” (обязательство как план будущих оплат)
Цель — видеть не только факт обязательств, но и их “хвост” по датам, чтобы заранее прогнозировать кассовые разрывы.
Что считаем — обязательство разбивается на ожидаемые даты оплат (условно: 30% аванс, 70% после поставки), и попадает в прогноз ликвидности.
Где обычно ломается/где ошибаются — слишком детальный график на старте превращает модель в администрирование, а не управление.
Пример: договор на 10 млн: 3 млн в феврале, 7 млн в марте; в феврале лимит выглядит свободным, но график показывает провал марта заранее.
Сравнение подходов
● Подход 1 быстрый, но ловит проблему поздно и провоцирует “пожарные” решения.
● Подход 2 даёт управляемость: обязательство не создаётся без лимита, а оплата остаётся под контролем ликвидности.
● Подход 3 повышает точность прогнозов, но требует зрелости процессов и дисциплины в исходных данных.
Типовые ошибки: На что обращать внимание
Ошибка: контроль включается только на оплате, а обязательства создаются свободно.
Риск: перерасход становится неизбежным, и финансы превращаются в “тормоз” в последний момент.
Как проверить за 2 минуты: сравните сумму оплат за месяц с суммой новых договоров/заказов за этот же месяц по ключевым статьям, и найдите статьи, где обязательства стабильно выше оплат.
Ошибка: “сверх лимита” разрешён без правил и причин.
Риск: система превращается в формальность, и любой перерасход оправдывается срочностью.
Как проверить за 2 минуты: посмотрите долю обязательств, созданных “сверх лимита”, и кто их согласует, если согласует вообще.
Ошибка: нет владельца лимита и маршрута эскалации.
Риск: решения зависают, бизнес обходится без согласований, ответственность размывается.
Как проверить за 2 минуты: назовите по каждой крупной статье одного человека, который имеет право сказать “да/нет” на превышение, и если это невозможно — контроль не заработает.
Ошибка: слишком детальная аналитика на старте.
Риск: растёт число “исключений”, люди ошибаются в классификации, контроль блокирует не то, что нужно.
Как проверить за 2 минуты: если для создания обязательства нужно выбрать больше 5–7 полей, и их часто заполняют “наугад”, начните с укрупнения.
Ошибка: обязательство не определено формально (что именно считается обязательством).
Риск: часть расходов проходит “мимо”, и отчёты по обязательствам дают ложное чувство безопасности.
Как проверить за 2 минуты: выберите одну проблемную статью (например, логистика) и вручную перечислите, какие документы/решения создают будущий платёж, и где контроль отсутствует.
Что делать с понедельника: План на 60–90 минут
Шаг 1. 10 минут. Зафиксируйте определение обязательства: какой документ или действие считается точкой, после которой у компании появляется ожидаемый платёж.
Шаг 2. 15 минут. Нарисуйте цепочку процесса: от потребности до оплаты, и отметьте, где сейчас стоит контроль, а где образуются обходы.
Шаг 3. 10 минут. Выберите 10–15 статей, где перерасходы болезненны, и определите владельцев лимитов по этим статьям.
Шаг 4. 15 минут. Определите правила лимита: период (месяц/квартал), уровень аналитики (минимально достаточный), и что именно “съедает” лимит: обязательства, оплаты или оба слоя.
Шаг 5. 15 минут. Настройте эскалацию: кто согласует превышение, какие причины допустимы, какой SLA по решению, какой формат фиксации решения.
Шаг 6. 10 минут. Введите две метрики контроля: “сумма обязательств в лимите” и “сумма обязательств сверх лимита”, и договоритесь о еженедельном разборе топ-5 превышений.
Итог плана
Что видим → обязательства формируются раньше оплат и уже съедают лимит.
Почему → контроль на оплате ловит перерасход слишком поздно, когда выбора почти нет.
Что делаем → ставим первый барьер на создании обязательства, второй — на оплате, и вводим управляемую эскалацию.
Как объяснить руководителю и коллегам: Скрипты
Руководителю: версия на 60 секунд.
Контроль оплаты защищает деньги “сегодня”, но не защищает бюджет “завтра”, потому что перерасход рождается раньше — на договоре и закупке. Контроль обязательств нужен, чтобы компания не обещала расходов сверх лимита до того, как появится счёт, иначе мы спорим в самый плохой момент, когда товар уже заказан и сроки горят. Мы не усложняем жизнь бизнесу, мы переносим решение в точку, где ещё есть выбор: изменить объём, срок, поставщика или согласовать превышение заранее и осознанно.
Коллегам по ролям.
Закупки: контроль обязательств — это ясное правило “можно/нельзя” до заказа, а не запрет оплаты в последний момент.
Производство: меньше остановок и авралов, потому что критичные закупки согласуются заранее, а не “спасаются” через срочные оплаты.
Логистика: видно, какие услуги уже “законтрактованы”, и можно планировать мощности и график без сюрпризов по оплатам.
Бухгалтерия: меньше “неожиданных” первичных документов и корректировок, потому что решения фиксируются до возникновения факта.
Казначейство: прогноз ликвидности становится честнее, потому что видны будущие платежи до заявок на оплату.
Микро-пример “что сказать на совещании”. Мы не обсуждаем оплату как отдельное событие, мы управляем обязательствами: если расход нельзя взять в лимит на этапе договора или закупки, значит его нельзя “легализовать” только потому, что пришёл счёт.
Наглядно: О чём это, если говорить просто?
Представьте семейный бюджет: у вас лимит на месяц 100 000, а на карте сейчас 60 000. Вы контролируете оплату и говорите себе: “пока не покупаем лишнего, всё нормально”. Затем вы обещаете: ремонт 40 000, школа 30 000, техника 50 000, потому что “платить будем потом”. Через неделю приходят счета, и вы обнаруживаете, что обещали 120 000, хотя оплат ещё почти не было, и лимит уже пробит будущими обязательствами.
Перевод на язык темы: контроль оплаты — это проверка покупок “на кассе”, а контроль обязательств — это правило “не складывать в корзину больше, чем позволяет лимит”, даже если платёж будет позже.
Управленческий вывод: если обязательства можно создавать сверх лимита до оплаты, вы неизбежно получите перерасход, а контроль оплат станет конфликтом “в последний момент”, а не управлением.
Мини-кейс на цифрах: лимит по статье 5 млн; за месяц оплатили 3 млн и кажется, что всё хорошо; при этом создали обязательства на 7 млн; через 2–3 месяца приходят счета и заявки на оплату, и вы получаете минус 2 млн, который уже не отменить без срыва операций.
Финал
● Контроль оплаты управляет ликвидностью “сегодня”, но не предотвращает перерасход, если обязательства формируются свободно.
● Контроль обязательств фиксирует будущие расходы на договоре/закупке/заказе и не даёт “занять” лимит незаметно.
● Лучший результат даёт двухбарьерная модель: сначала контроль на обязательстве, затем контроль на оплате.
● Эскалация “сверх лимита” должна быть управляемой, иначе контроль превращается в декорацию.
● Минимальная практическая метрика — обязательства в лимите vs сверх лимита, потому что она показывает реальную дисциплину расходов.
Вопрос: где у вас чаще появляется перерасход — на договорах, на закупках или уже на этапе счетов и заявок на оплату?
Всё остальное — финансовая лирика, пока не кончились деньги.