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

Что значит «мимо бюджета» и почему это случается

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

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

Процесс чаще всего ломается в типовых местах:

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

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

Короткий пример: отделу нужно докупить комплектующие на 1,2 млн. Руководитель согласовал, потому что задача важная. Позже выяснилось, что по этому же подразделению уже есть согласованные заявки на 900 тыс., которые еще не оплачены. В сумме лимит превышен, и заказ зависает. Поэтому настройка лимитов закупок по подразделениям должна учитывать не только оплаченные счета, но и будущие обязательства.

Процесс «заявка-лимит-утверждение-заказ» простыми словами

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

Обычно это выглядит так:

• Заявка. Инициатор описывает, что нужно купить и зачем. Здесь важно зафиксировать в системе сумму и привязку к подразделению, а не договориться «на словах».
• Лимит. Бюджетодержатель (руководитель ЦФО или ответственный за бюджет подразделения) проверяет, есть ли свободный остаток по нужной статье. На этом шаге и работает настройка лимитов закупок по подразделениям.
• Утверждение. Согласующие (руководитель, финансы, иногда служба безопасности или IT) подтверждают, что покупка допустима по правилам и документам.
• Заказ. Закупки оформляют заказ: выбирают поставщика, согласуют условия, контролируют поставку и закрывающие документы.

Роли лучше разделять жестко. Инициатор отвечает за корректность потребности и цели. Бюджетодержатель - за расход лимита. Финансы - за соблюдение бюджета и статей. Закупки - за процедуру и условия покупки.

Где чаще всего теряется контроль:

1. До заявки: договорились устно, поставщик уже привез, а потом ищут, как это провести.

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

3. При выборе поставщика: формально лимит был, но из-за замены позиции или роста цены сумма становится выше, и это замечают слишком поздно.

Чтобы контроль работал, в заявке стоит фиксировать минимум:

• сумму (плановую и, если нужно, с НДС)
• статью затрат и центр затрат (подразделение)
• цель покупки (для чего и кому)
• срок, когда нужно
• обоснование или вложение (например, расчет, КП, спецификация)

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

Какие лимиты стоит вводить: виды и примеры

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

1) Лимит на подразделение (на месяц или квартал)

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

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

2) Лимит на статью затрат (категорию)

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

Пример категорий: IT-оборудование, расходные материалы, услуги (подрядчики), командировки, обучение. У отдела есть квартальный лимит 6 млн тг, но внутри него: 2 млн тг на IT, 1 млн тг на услуги, 500 тыс тг на расходники, остальное - на прочее.

3) Лимит на разовую покупку (порог суммы)

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

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

4) Резерв под договоры и регулярные платежи

Если есть услуги по договору (связь, обслуживание, лицензии, охрана, клининг), их лучше резервировать заранее. Тогда эти деньги не потратят на другие заявки, а в конце периода не появится сюрприз в виде обязательного счета без лимита.

Пример: ежемесячный платеж 450 тыс тг по сервисному договору. На квартал резервируется 1,35 млн тг, и эта сумма сразу уменьшает доступный лимит подразделения.

5) Отдельный лимит на срочные случаи

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

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

Подготовка: данные и правила, без которых лимиты не заработают

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

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

Дальше приведите к одному виду статьи затрат. Не должно быть ситуации, когда «канцелярия», «офисные расходники» и «бумага/картриджи» живут как разные статьи с разными лимитами. Зафиксируйте границы: что относится к статье, а что нет. Это снижает споры при согласовании.

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

Полезно заранее определить типовые заявки и поля, которые должны заполняться. Например:

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

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

Как настроить лимиты по подразделениям: пошаговый план

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

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

2. Задайте лимиты: по подразделениям и статьям расходов (например, IT, офис, сервис, командировки). Сразу определите период, чаще всего месяц или квартал. Не смешивайте разовые крупные проекты и текущие мелкие траты: для проекта лучше выделить отдельную статью или отдельный лимит.

3. Включите проверку лимита на этапе заявки, а не после заказа. Тогда сотрудник сразу видит, проходит ли сумма, и не тратит время на согласование того, что все равно не оплатят.

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

5. Утвердите матрицу согласований: кому и при каких суммах уходит заявка, и какие типы закупок требуют дополнительных проверок.

Матрица может быть простой:

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

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

Правила исключений: чтобы контроль не мешал работе

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

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

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

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

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

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

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

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

Контроль и отчеты: как вовремя видеть превышения

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

Панель для руководителя: что смотреть каждый раз

В отчете по подразделению оставьте то, что помогает принять решение сегодня:

• план на период (месяц или квартал) по статьям
• факт: уже оплачено или уже проведено в учете
• зарезервировано: заявки/заказы, которые уже «съели» лимит, но еще не стали фактом
• остаток лимита: сколько можно тратить без пересогласования
• прогноз до конца периода: факт + резерв + ожидаемые регулярные покупки

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

Как ловить «дробление» и другие обходы

Частая проблема - несколько небольших заявок вместо одной крупной, чтобы пройти по упрощенному маршруту. Для контроля «дробления» задайте правила отбора: один поставщик, одна статья, одно подразделение, короткий период (например, 7-10 дней) и сумма в итоге выше порога согласования.

Дополнительно держите набор сигналов риска. Они помогают увидеть проблему раньше, чем лимит уже превышен:

• резкий рост срочных закупок и закупок «сегодня на вчера»
• превышения по одной статье при экономии по другим (часто это неверная статья или подмена цели)
• заказы без привязки к заявке или без резерва лимита
• скачок отмененных заявок и повторных заявок (часто так «подгоняют» сумму)
• необычно частые закупки у одного поставщика небольшими суммами

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

Чтобы данным доверяли, назначьте ответственность: инициатор подтверждает закрытие заявки (что получили и в каком объеме), закупки подтверждают статус заказа, финансы подтверждают факт и статьи затрат. Например, если отдел IT закупает партию рабочих станций для учебного класса, руководитель должен видеть не только оплату, но и резерв по уже согласованным заявкам. Иначе остаток лимита будет выглядеть больше, чем он есть на самом деле.

Частые ошибки и как их избежать

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

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

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

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

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

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

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

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

Короткий чеклист: лимиты работают или нет

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

Быстрая проверка за 10 минут

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

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

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

Пример из практики: закупка на грани лимита

Финансовый отдел видит: у IT-подразделения на квартал осталось 180 000 тенге по статье «Компьютерное оборудование». В это же время сервис-деск просит срочно купить две рабочие станции для новых сотрудников. По коммерческим предложениям сумма выходит 220 000 тенге. Лимит почти выбран, но потребность реальная.

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

• цель и обоснование (кого нанимаем, какие задачи, что будет если не купить)
• статья бюджета и центр затрат (какое подразделение и на что именно)
• сумма и валюта, с НДС или без (чтобы не было сюрпризов на этапе счета)
• срок поставки и желаемая дата ввода в работу
• подтверждение, что есть сравнение цен (хотя бы 2-3 предложения)

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

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

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

Следующие шаги: как внедрить и закрепить процесс

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

Дальше выберите 1-2 проблемных участка и запускайте изменения именно там. Чаще всего это услуги (где сложно сравнить цены), срочные закупки и мелкие покупки, которые в сумме дают большую дыру в лимитах.

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

План внедрения удобно оформить как короткий пилот на 2-4 недели:

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

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

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