Зачем нужен реестр платежей в 1С, чем он отличается от выгрузки платёжек, как выстроить приоритеты и согласование и почему опасна оплата без основания.
Реестр платежей в 1С - это не список платёжных поручений на выгрузку в банк. Это перечень заявок к оплате с основанием, сроком, приоритетом и маршрутом согласования: документ, по которому принимается решение, что платим сегодня, а что переносим. Без него решение принимается в мессенджере, а в учёт попадает уже результат.
| Выгрузка платёжных поручений | Реестр платежей | |
|---|---|---|
| Суть | Бухгалтер получает согласованные где-то платежи, создаёт поручения и выгружает их в банк. Решение о том, что именно платить, принято раньше и вне системы. | Заявка на оплату создаётся с основанием, сроком и статьёй, проходит согласование по правилу и попадает в реестр на дату. Платёжное поручение — последний шаг, а не первый. |
| Что видно | суммы и получатели | обязательство, срок, статья, инициатор, согласующий |
| Основание | лежит в почте или у инициатора | договор, счёт, документ поступления |
| Приоритет | определяется тем, кто громче попросил | по последствиям неоплаты и лимитам |
| След | остаётся только факт платежа | кто, когда и на каком основании одобрил |
Типовые конфигурации 1С различаются глубиной: в решениях управленческого класса заявка на расходование денежных средств с маршрутом согласования есть, в бухгалтерской конфигурации её обычно нет - там реестр собирают отчётом, таблицей или дорабатывают. Отсюда и распространённая гибридная схема: согласование в мессенджере, реестр в Excel, платёжки в 1С.
Договор, счёт или документ поступления. Заявка без основания не должна доходить до оплаты - это то место, где потом теряются закрывающие документы.
Не «когда удобно», а дата по договору и что произойдёт при просрочке: пени, остановка поставки, блокировка счёта.
Статья БДДС, проект, подразделение, юрлицо. Без них реестр не сходится с бюджетом и план-фактом.
Правило, а не мнение: обязательные платежи, критичные для операционной деятельности, остальные. Приоритет должен быть у заявки, а не у того, кто её принёс.
Кто утверждает в зависимости от суммы, статьи и юрлица. Маршрут задан заранее, иначе согласование каждый раз ищется заново.
Реестр сверяется с фактическими остатками и ожидаемыми поступлениями. Без этого он не предупреждает о кассовом разрыве, а просто фиксирует желания.
Деньги ушли, договора и счёта под платёж нет. Всплывает при закрытии месяца и на сверке с контрагентом, когда закрывающий документ так и не появился.
Один счёт подан дважды - инициатором и бухгалтерией - с разницей в несколько дней. Без контроля по номеру счёта и сумме дубль проходит незамеченным.
Срочные платежи оказываются наверху не по последствиям, а по настойчивости инициатора. Налоги и зарплата при этом уезжают на следующую неделю.
Одобрение получено голосом или в чате. Через месяц нельзя ответить, кто разрешил платёж и на каком основании - а вопрос задаётся именно тогда.
Перечень собран, но остатки и поступления не учтены. Кассовый разрыв обнаруживается в день платежа, а не за неделю.
Все пять проблем объединяет одно: они не про арифметику, а про дисциплину.
Их не решает более удобная таблица - их решает правило, которое проверяется до того, как заявка попадёт в реестр. ### Что это стоит компании
Раздел для руководителя, которому финансист или бухгалтер показывает этот материал.
Слабый реестр не выглядит проблемой: платежи проходят, банк работает.
Цена проявляется в трёх местах - просроченные обязательства с пенями там, где деньги были; закрывающие документы, которых не хватает при закрытии периода; и время руководителя, который еженедельно вручную решает очередь платежей. Что стоит спросить у команды: -
Какая доля платежей уходит без привязки к договору или счёту? -
Где хранится решение о согласовании платежа на существенную сумму? -
За сколько дней мы узнаём о нехватке денег на обязательный платёж?
Автоматизируется здесь сбор и проверка, а не решение об оплате.
Агент собирает в реестр только заявки с понятным основанием и маршрутом, проверяет дубли, лимиты и остатки, а спорное выносит в очередь исключений.
Решение о платеже остаётся за финансистом или собственником.
Это процесс из контура ИИ-бухгалтера; прогнозная часть - платёжный календарь и кассовые разрывы - разобрана отдельно в статье «Платёжный календарь в 1С», а как собирать управленческую картину - в кейсе управленческой отчётности.
Разнесение уже прошедших платежей - соседний участок, про него есть разбор «Банковская выписка в 1С».
FAQ
Реестр - это что платим сегодня и в каком порядке. Календарь - это прогноз: когда какие обязательства наступают и хватит ли денег. Реестр формируется из календаря на конкретную дату.
Заявки на расходование денежных средств с маршрутом согласования есть в решениях управленческого класса. В бухгалтерской конфигурации реестр обычно собирают отчётом или таблицей, поэтому согласование часто уезжает в почту и мессенджеры.
Правилом, а не обсуждением: сначала обязательные платежи с прямыми последствиями просрочки, затем критичные для операционной деятельности, затем остальное. Приоритет принадлежит заявке и её последствию, а не инициатору.
Не пропускать в реестр. Отсутствие договора или счёта на этапе заявки почти всегда означает отсутствие закрывающего документа потом - и вопрос при закрытии периода и на сверке.
Собрать реестр, проверить основания, дубли и лимиты и провести заявку по заданному маршруту - да. Само решение об оплате остаётся у человека: агент готовит и проверяет, а не распоряжается деньгами.
Напрямую: платёж без основания или разнесённый не на тот договор проявляется расхождением в акте сверки. Регулярная сверка - это способ увидеть последствия слабой платёжной дисциплины.
