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

Автоматизация казначейства связывает три процесса: заявку на платёж, согласование по лимитам и ролям, выгрузку реестра в банк. Бухгалтерский контур регулируется ФЗ-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 (0 технических расхождений).

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