Как автоматизировать казначейство: платёжный реестр и согласование

Автоматизация казначейства — это не выгрузка выписки в Excel, а связка трёх процессов. Заявка на платёж от инициатора, маршрут согласования по лимитам и ролям, выгрузка реестра в банк. Бухгалтерский контур регулируется ФЗ-402 «О бухгалтерском учёте» от 06.12.2011 в действующей редакции от 15.12.2025; валютные платежи — 173-ФЗ «О валютном регулировании» от 10.12.2003, и с 01.01.2026 в нём действует новая отчётная форма со штрафами за непредставление. Управленческое казначейство строится поверх этих требований.

Что такое автоматизация казначейства и зачем она нужна

Казначейство — это процесс управления деньгами компании в реальном времени. Входящие платежи, исходящие платежи, остатки на счетах, лимиты по статьям и платёжная дисциплина. Бухгалтерия фиксирует то, что уже произошло, по правилам ФЗ-402 «О бухгалтерском учёте» (consultant.ru/document/cons_doc_LAW_122855); казначейство управляет тем, что произойдёт завтра.

Ручное казначейство выглядит знакомо. Заявки на оплату приходят финдиректору в Telegram и WhatsApp. Согласование идёт через «крикнул через стол» или короткие диалоги в коридоре. Реестр платежей казначей выгружает руками в Excel, потом — в клиент-банк. На контрольной точке месяца обнаруживается, что банковская выписка не сошлась с реестром на 240 тыс ₽, и неделю выясняют, чей это платёж и кто его одобрил.

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

На размере группы компаний выгода удваивается. В группе из пяти юрлиц без автоматизации казначейства финдиректор каждый день начинает с того, что собирает остатки на счетах из шести клиент-банков, сверяет их с записями в Excel и пытается понять, чьи платежи завтра в первой очереди. С автоматизацией этот ритуал занимает не утренние два часа, а 5–10 минут на проверку дашборда.

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

Что понадобится для постановки процесса

До запуска любого инструмента нужно собрать три блока — договорённости, данные, инструменты. Без первых двух софт ляжет поверх хаоса и автоматизирует хаос.

Договорённости — это рамка процесса. Классификатор статей платежей обычно содержит 30–50 пунктов: зарплата, налоги, аренда, поставщики, маркетинг, обучение, командировки, прочее. Лимиты согласования строятся по двум осям — по статье и по сумме. Перечень ролей в группе из 50 человек минимум четыре: инициатор, согласующий ЦФО, финансовый директор, казначей. В холдинге добавляются контролёр и внутренний аудит.

Данные — это реестр контрагентов с реквизитами и привязкой к договорам, остатки на расчётных счетах из банка или из 1С, история платежей за 3–6 месяцев для калибровки лимитов. Без истории лимиты ставятся «по ощущениям», и через месяц выясняется, что 60 процентов платежей превышают «нормальный» порог, а маршрут согласования стал бутылочным горлышком.

Инструменты — это либо модуль казначейства в 1С (УХ, ERP), либо специализированный сервис управленческого учёта с поддержкой заявок и согласования. Интеграция с клиент-банком — это конец цепочки, а не начало. До банковской выгрузки должны быть отстроены заявка и согласование, иначе казначейство сводится к «нажми кнопку отправить» без аудит-следа.

Пять шагов как автоматизировать казначейство

Постановка автоматизированного казначейства идёт строго последовательно. Перепрыгивать шаги нельзя — каждый следующий опирается на завершённый предыдущий.

1. Описать классификатор статей и лимиты. Выписать 30–50 статей расходов под структуру бизнеса, не под План счетов из 1С. Для каждой статьи задать лимит автоматического одобрения, лимит согласования с финдиректором и порог эскалации к собственнику. Для группы компаний — отдельная ось «по юрлицу» с лимитами под размер каждого ООО. Согласовать классификатор с бухгалтерией: он должен сопоставляться с бухгалтерскими счетами для последующей сверки.
2. Завести роли и маршруты согласования. Минимум четыре роли: инициатор (любой сотрудник), согласующий ЦФО (одобряет в пределах своего лимита), финансовый директор (платежи свыше лимита), казначей (формирует реестр и платит). Маршрут описывается по правилам: «до 50 тыс ₽ — руководитель отдела; 50–500 тыс ₽ — финдир; свыше 500 тыс ₽ — собственник». Принцип разделения обязанностей: никто не может одновременно создать, одобрить и отправить один и тот же платёж.
3. Внедрить форму заявки на платёж. Заявка должна содержать: контрагент с реквизитами из справочника, статья расхода из классификатора, ЦФО, сумма, дата оплаты, основание (договор, акт, счёт), комментарий инициатора. Обязательное поле — приложить документ-основание PDF или скан. Без документа заявка не уходит в маршрут. Параллельно настраивается SLA на согласование: если за N часов нет реакции, заявка эскалируется выше, а не зависает в чьём-то рабочем столе.
4. Собрать платёжный реестр на день. Все заявки, прошедшие согласование, попадают в реестр на дату оплаты. Казначей утром видит сводку: 18 платежей на 4,2 млн ₽, из них первоочередные — зарплата и налоги. Если на счетах не хватает — реестр перестраивается по приоритетам: что переносится на завтра, что согласовывается с финдиректором на сокращение, что закрывается из овердрафта.
5. Выгрузить реестр в клиент-банк. Стандартный путь — выгрузка XML формата 1С_8.2 или ISO 20022 в клиент-банк. Современные банки (Сбер, Тинькофф, Альфа, Точка, Открытие) поддерживают прямой обмен по API — заявка из системы казначейства уходит в банк без файла. После проводки банк отдаёт обратно выписку, и система автоматически закрывает заявку со статусом «оплачено». Реестр становится фактом и попадает в управленческий ДДС.

Каждый шаг занимает 1–2 недели на проекте средней сложности. На холдинге из пяти юрлиц первый запуск обычно укладывается в 6–8 недель — это нормально, потому что половина времени уходит на согласование классификатора и лимитов с пятью директорами параллельно.

Как устроены лимиты, маршруты согласования и роли

Базовая четвёрка ролей в казначействе устроена по принципу разделения обязанностей. Инициатор создаёт заявку — это любой сотрудник, у которого есть основание для платежа: руководитель отдела закупок, hr-менеджер, директор по маркетингу. Согласующий ЦФО одобряет заявку в пределах своего лимита — обычно это руководитель того направления, к которому относится статья расхода. Финансовый директор включается на платежах свыше лимита ЦФО. Казначей формирует итоговый реестр и отправляет его в банк.

Маршрут согласования настраивается по двум измерениям — по сумме и по статье. По сумме типовая лестница такая: до 50 тыс ₽ — руководитель отдела без эскалации; 50–500 тыс ₽ — финансовый директор; свыше 500 тыс ₽ — собственник или совет. Конкретные цифры подбираются под размер бизнеса. Принцип калибровки: 80 процентов платежей должны проходить автоматически или с минимальным согласованием, и только 20 процентов — действительно требовать внимания топов. Если у вас 90 процентов платежей идут к собственнику — лимит выставлен неправильно.

По статье работает отдельный список особенностей. Зарплатные платежи всегда идут отдельной веткой с участием бухгалтерии и контроля по штатному расписанию. Налоговые — с обязательной проверкой реквизитов получателя через справочник ФНС. Валютные платежи (173-ФЗ «О валютном регулировании») — отдельный маршрут с юристом и валютным контролёром банка. С 01.01.2026 за непредставление новой отчётной формы по валютным операциям введены штрафы (garant.ru/news/1811437), поэтому валютная ветка теперь обязательна, а не «по желанию».

SLA на согласование — критический параметр, который часто забывают. Без SLA заявка может зависнуть в почте руководителя на 5 дней, и платёж сорвётся. Рабочее правило: если за 4 рабочих часа нет реакции согласующего, заявка автоматически эскалируется на уровень выше с пометкой «согласовано по таймауту». Это дисциплинирует руководителей и не даёт казначейству встать на двух-трёх отпусках.

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

Как платёжный реестр связывается с управленческим учётом и банком

Платёжный реестр — это сводный документ на день со всеми одобренными заявками. Без него казначейство — это набор разрозненных платежей; с ним — управляемый поток с фиксированной точкой контроля. После выгрузки в банк реестр становится фактом списания и должен попасть в управленческий учёт автоматически.

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

Связка с управленческим учётом критична для группы компаний. Одобренная заявка с привязанной статьёй и ЦФО — это уже готовая проводка в управленческий ДДС. Если этой связки нет, ДДС придётся строить из выписки задним числом, классифицируя каждую строку по сумме и контрагенту. На холдинге это занимает 3–5 дней работы помощника финдиректора каждое первое число месяца. Со связкой — закрытие ДДС автоматическое в день последнего платежа.

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

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

Сверка с банковской выпиской на закрытии дня — ещё один обязательный шаг. Каждая строка выписки должна быть привязана к одобренной заявке или явно помечена как «не наша операция» (комиссия банка, ошибочный платёж, возврат). Расхождения свыше 1 тыс ₽ — расследуются в тот же день, не откладываются. На горизонте месяца это даёт ноль расхождений между управленческим ДДС и банковской выпиской, и закрытие периода больше не превращается в недельное расследование.

Как свóдно решает задачу автоматизации казначейства

Свóдно. закрывает четыре блока казначейства, которые в 1С приходится дописывать руками, а в массовых сервисах учёта вообще отсутствуют.

Модуль /payment-approval/ — это заявки на платёж с настраиваемыми маршрутами согласования по лимитам и ролям. Финдиректор описывает один раз: классификатор статей, лимиты, роли, маршруты, SLA на согласование. Дальше система применяет правила автоматически. Эскалация по таймауту, разделение обязанностей, аудит-след каждого действия — встроены, не нужно дописывать в скриптах.

/calendar/ — платёжный календарь группы компаний на 30–90 дней вперёд. Все одобренные заявки автоматически попадают в календарь. Финдир видит кассовые разрывы заранее: где конкретно ломается ликвидность, по какой статье и юрлицу, и за какое количество дней до проблемы. Подробнее о платёжном календаре — в нашей следующей статье.

Источники данных подключаются по расписанию: 1С (любая редакция: Бухгалтерия, УНФ, УТ, ERP) через OData, банки напрямую — Сбер, Альфа, Точка, Т-Банк и другие, 1С:ЗУП — для зарплатных проводок, маркетплейсы — Ozon и Wildberries. Одобренная заявка превращается в проводку в управленческом ДДС автоматически, без двойного ввода и без помощника финдиректора. Подробнее об этом — в статье Интеграция 1С с управленческим учётом и принцип 0 DIFF.

Audit-bridge сверяет факт платежей с банковскими выписками и проводками 1С — расхождения видны в /discrepancies/. Финдир не ловит «где-то пропали 240 тысяч» за месяц до отчёта, а видит конкретную строку через день после проводки. Логика четырёх сверок описана в статье audit-bridge: как устроена сверка управленческого с РСБУ.