План-факт по бюджетам подразделений: связка заявок и оплат

Почему план-факт не сходится и лимиты становятся неясными

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

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

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

Ручные Excel-своды усугубляют ситуацию. Они выглядят аккуратно, но обновляются с задержкой, зависят от одного человека и его формул, не показывают обязательства (то, что уже «занято», но еще не оплачено) и плохо переживают корректировки.

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

Рабочий план-факт отвечает на четыре вопроса без «ручных пояснений»: сколько было выделено, сколько уже зарезервировано заявками и заказами, сколько оплачено, сколько осталось доступно. Например, если ИТ-отдел планирует закупку серверов или рабочих станций, руководитель должен видеть не только оплаченные счета, но и сумму подтвержденных заказов, которые «съедят» лимит на следующей неделе.

Когда эти ответы видны сразу, контроль становится спокойнее: лимиты понятны, решения принимаются быстрее, а согласования идут по правилам, а не по переписке и догадкам.

Что подготовить перед настройкой: роли, статусы, правила

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

Роли: кто держит процесс на рельсах

Обычно достаточно четырех ролей:

• Инициатор создает заявку, выбирает подразделение и статью, описывает потребность и сумму.
• Руководитель подразделения подтверждает, что трата нужна и укладывается в лимит.
• Закупки переводят потребность в закупку (запрос цен, договор, заказ) и фиксируют условия.
• Финансы (бюджет/казначейство) следят за лимитами, резервом и оплатами, подтверждают платежи.

Если один человек совмещает роли, это нормально. Важно, чтобы роль была обозначена, а действия были одинаковыми для всех.

Статусы: в какой момент деньги «занимаются» и «тратятся»

Главная договоренность: какие статусы документов влияют на доступный остаток. Типовой набор:

• Черновик: ни на что не влияет.
• Согласовано: появляется резерв, лимит уменьшается на сумму заявки.
• Размещено (заказано/договор подписан): обязательство подтверждено документом закупки.
• Оплачено: факт, деньги ушли, обязательство закрывается.

Смысл простой: руководитель должен видеть не только оплаты, но и то, что уже «пообещали потратить».

Правила: где «источник правды» и что нельзя обходить

Выберите один источник правды: систему. Письма, чаты и таблицы могут быть приложениями, но не местом, где меняется сумма или статус. Иначе получится две реальности: в системе лимит есть, а в переписке его уже «заняли».

Зафиксируйте несколько коротких правил: кто имеет право менять сумму после согласования, когда нужна повторная проверка руководителем, что делать при частичной поставке или частичной оплате.

Минимальные данные для старта

Чтобы связать заявки, закупки и оплаты без ручных догадок, у каждого документа должен быть одинаковый «скелет»:

• подразделение (чей лимит расходуем);
• статья бюджета (на что тратим);
• сумма и валюта;
• период лимита (месяц/квартал/год);
• контрагент (когда уже известен) и основание (договор/счет).

Если начать с этого набора и дисциплины по статусам, расчет резерва и факта настраивается заметно легче. Руководители будут видеть остатки лимитов без сверок и фразы «у нас в Excel другое».

Справочники без хаоса: статьи, ЦФО и периоды лимитов

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

Как устроить статьи бюджета

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

Практичный подход - два уровня: крупная статья (например, «ИТ-оборудование») и уточнение («ПК», «серверы», «мониторы»). Тогда руководителю понятны суммы, а закупки и финансы не теряют детали.

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

Подразделения, ЦФО и проекты: не усложняйте

Структуру лучше строить от того, кто отвечает за лимит. Часто достаточно связки «подразделение + ЦФО». Проекты добавляйте только там, где реально нужен отдельный контроль, иначе заявки начнут «размазываться» по случайным проектам.

Пример: «ИТ-служба» ведет лимит по статье «ИТ-оборудование», а «Филиал Астана» - по статье «Связь и интернет». Если сотрудник филиала создает заявку на ноутбук, он выбирает статью «ИТ-оборудование» и свой ЦФО «Филиал Астана». Так руководитель филиала видит, что его лимит уменьшается, даже если закупку ведет центральная ИТ.

Периоды лимитов и переносы

Определите период лимита один раз и придерживайтесь его (год, квартал или месяц). Заранее опишите правила переноса: что делать с неиспользованным лимитом и что делать с перерасходом.

Чаще всего работает простая логика: лимит живет в рамках периода, перенос возможен только после утверждения и фиксируется отдельной корректировкой. Тогда остатки лимитов в бюджете не «рисуются», а объясняются понятными решениями.

Как задавать лимиты и изменения: план, утверждение, корректировки

Чтобы план-факт работал, лимит должен появляться в системе раньше заявок и быть «живым»: с датой действия, владельцем и историей изменений.

План обычно заводят как бюджет по статьям и подразделениям (ЦФО) на период. Важно заранее договориться о детализации, чтобы потом не плодить сотни мелких строк.

План и утверждение лимита

Базовая схема выглядит так:

• инициатор вводит план по статьям и периоду;
• финансы проверяют правила (статья, период, ЦФО, обоснование);
• утверждающий фиксирует «утвержденный лимит» отдельным статусом;
• после утверждения лимит становится доступен для резервирования;
• любые изменения идут только через «корректировку», а не ручной правкой утвержденной цифры.

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

Корректировки, возвраты и отмены

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

Продумайте заранее, как система реагирует на типовые события: отмена заявки или закупки (резерв возвращается), частичное исполнение (часть резерва превращается в факт, остаток остается), перенос сроков (только через согласованную корректировку), возврат от поставщика (уменьшает факт и восстанавливает доступный лимит), замена статьи или подразделения (только через документ изменения с маршрутом согласования).

Ориентир простой: руководитель открывает лимит и видит три цифры (утверждено, зарезервировано, оплачено) и понимает, почему остаток стал именно таким.

Пошагово: как связать заявку, закупку и оплату в системе

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

Логика цепочки такая: намерение (заявка) -> обязательство (резерв/заказ) -> подтверждение получения (приемка/акт) -> оплата. Если хотя бы одно звено не связано с предыдущим, лимиты начинают «прыгать».

Пять шагов, которые должны быть связаны одним основанием

• Потребность оформляется заявкой. В ней сразу указывают подразделение, статью, период и ожидаемую сумму. До согласования система должна проверять доступный лимит с учетом уже зарезервированного.
• После согласования появляется резерв. Деньги еще не ушли, но их уже нельзя потратить второй раз. Если закупка планируется частями, резерв лучше создавать по этапам.
• Оформляется заказ поставщику (PO) с контролем суммы и валюты. Заказ наследует статью, ЦФО и проект (если он используется) из заявки. Важно заранее закрепить правила пересчета валюты.
• Подтверждается получение (приемка, акт, накладная). При частичной поставке приемка тоже должна быть частичной.
• Счет и оплата привязываются к заказу и статье. Авансы, частичные оплаты и доплаты должны ссылаться на конкретный заказ или приемку, чтобы факт закрывал обязательство автоматически.

Что чаще всего ломает связку

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

Как считать остаток лимита: план, резерв и факт

Чтобы руководители видели реальную картину, в системе нужно разделять три слоя: план (утвержденный лимит), резерв (обязательства) и факт (оплаты).

Три слоя, которые нельзя смешивать

План - это сколько подразделению разрешили потратить в периоде по статье и ЦФО. Резерв - это сколько уже пообещали потратить, даже если денег еще не перечислили. Факт - это сколько реально оплатили.

Остаток удобно считать так:

Остаток = План - Резерв - Факт.

Так руководитель не видит «свободные» деньги, которые уже заняты заявками и договорами.

Частичные поставки и частичные оплаты

Частичные поставки можно учитывать отдельным показателем «принято/поставлено», но на остаток лимита они влияют только по выбранному правилу. Самое понятное для управленческого контроля: резерв держится по сумме обязательства до закрытия заказа, а факт уменьшает остаток по мере оплат.

Пример: лимит 10 000 000 тг, договор на 8 000 000 тг, оплата 3 000 000 тг. Остаток = 10 000 000 - 8 000 000 - 3 000 000 = -1 000 000 тг. Это сигнал, что обязательства уже превышают лимит, даже если деньги еще не ушли полностью.

НДС, курсовые разницы, округления

Чтобы лимиты не «прыгали», заранее закрепите единые правила:

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

Отчеты для руководителей: что показывать, чтобы было понятно

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

Что руководитель должен увидеть за полминуты

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

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

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

Фильтры и подсветки

Фильтры должны быть одинаковыми во всех отчетах. Минимум: период, проект, поставщик, инициатор.

Подсветки помогают не пропустить риск:

• остаток ниже порога (например, 10% от лимита);
• документ «на согласовании» дольше нормы;
• есть заказ/договор, но нет ожидаемой даты оплаты;
• счет на оплату не совпадает по статье с заявкой.

Пример на практике: закупка оборудования в рамках лимита

Представим ИТ-отдел, у которого на квартал утвержден лимит 12 000 000 тг по статье «Компьютерная техника». Руководителю важно видеть не только «сколько уже оплатили», но и «сколько уже заняли обязательствами», чтобы не раздать деньги дважды.

Сотрудник создает заявку: 10 офисных ПК (например, из линейки L200) и 10 мониторов. В заявке указывает плановую сумму 11 500 000 тг. После согласования заявка получает статус «Утверждена», и система резервирует сумму как обязательство. Остаток меняется сразу, потому что деньги уже заняты под будущую закупку.

Дальше закупки проводят конкурс и получают цену ниже: 10 900 000 тг. В корректной связке документов заказ привязывается к заявке, а резерв пересчитывается по сумме заказа. Разница 600 000 тг возвращается в доступный остаток лимита без ручных правок.

Поставка приходит частями: сначала 6 комплектов, потом еще 4. По одному заказу проходят две оплаты: аванс 30% и финальная оплата после закрывающих документов. Факт оплаты накапливается по мере платежей, а «занято» остается равным сумме обязательства, пока заказ не закрыт полностью.

Для руководителя самый понятный итог - четыре числа по статье и периоду:

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

Частые ошибки: почему лимиты показывают не то

Обычно проблема не в формулах, а в правилах. Если не договориться, когда появляется обязательство, куда оно относится и как отменяется, «остаток лимита» почти всегда будет расходиться с ожиданиями.

1) Резерв делают слишком рано или слишком поздно

Если резерв ставят в момент создания заявки, лимит «съедается» даже по идеям, которые потом не утвердят. Если резерв делают только на этапе оплаты, руководитель долго видит свободные деньги, хотя закупки уже запущены.

Лучше выбрать один понятный момент для резерва (например, статус «Утверждено» или создание заказа) и явные события, которые резерв снимают или превращают в факт.

2) Заявки, закупки и оплаты идут по разным статьям и подразделениям

Классика: заявка по статье «Офисные расходы», заказ по «Компьютерной технике», оплата - по третьей статье. В отчетах резерв «сидит» в одной строке, факт - в другой, и каждая статья по отдельности выглядит неверно.

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

3) Нет правил для отмен и возвратов, лимит не освобождается

Если заявку отклонили, заказ отменили, товар вернули или поставщик сделал сторно, лимит должен освобождаться предсказуемо. Иначе резерв «висит» месяцами и занижает доступный остаток.

Минимум нужны два сценария: отмена до заказа (резерв снимается полностью) и отмена после заказа/частичной оплаты (пересчет резерва и факта по документам).

4) Оплаты проходят без привязки к заказу, факт попадает не туда

Если платеж уходит без ссылки на заказ/договор/заявку, факт сложно отнести к правильной статье и подразделению. Тогда руководитель видит неожиданное списание в другой статье или «пустой» факт при занятом резерве.

Рабочее правило: платеж подтягивает бюджетную аналитику из основания. Ручной ввод аналитики в платеже - исключение, а не норма.

5) Смешивают план по начислению и факт по оплате без пояснений

Иногда план ставят «по начислению» (по ожидаемым счетам и закрывающим), а факт считают «по оплате». Тогда в одном месяце лимит кажется свободным, а в другом резко уходит в минус, хотя работа шла ровно.

Если используются разные подходы, это нужно явно показывать: отдельно обязательства/резерв, отдельно оплачено, и отдельной строкой - логика учета.

Чек-лист перед запуском и следующие шаги внедрения

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

Чек-лист перед стартом

• Справочники: статьи бюджета, ЦФО, периоды лимитов и правила резервирования.
• Цепочка документов: у заявки, закупки и оплаты должны быть обязательные поля (статья, ЦФО, период, ответственный, основание) и единая логика статусов.
• Формула остатка: что входит в план, что считается резервом, что попадает в факт. Отдельно - возвраты и сторно.
• Частичные операции: частичная поставка, частичная оплата, пересогласование и корректировки должны правильно менять резерв и факт.
• Контроль сверки: прогоните 5-10 типовых сценариев и сверяйте итог с бухгалтерией/казначейством.

Полезно сделать короткий «пробный день» в реальном ритме: 2-3 заявки от разных подразделений, одна закупка с частичной поставкой и одна оплата в два платежа. Это быстро показывает, где людям не хватает полей, где статусы непонятны и где рвется связка.

Следующие шаги внедрения

Дальше помогает простой план:

1. Выберите платформу, где можно закрепить правила и отчеты.

2. Назначьте владельца процесса (обычно финансы) и владельцев данных (подразделения), чтобы было кому разбирать спорные случаи.

3. Опишите минимальный набор отчетов для руководителей: лимит, резерв, факт, остаток и расшифровка «что зарезервировало».

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

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