Электронное согласование счетов на оплату: маршруты и сроки

Зачем переводить согласование счетов в электронный вид

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

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

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

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

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

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

Как устроено электронное согласование простыми словами

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

Важно не путать документы. Счет фиксирует сумму, реквизиты и основание платежа (за что платим и кому). Акт, накладная или УПД подтверждают факт поставки товара или оказания услуги. Часто счет приходит первым, а первичка закрывает сделку позже. Поэтому удобно хранить документы рядом, но помнить про их роли: счет запускает оплату, первичка подтверждает выполнение.

Чтобы никто не гадал, что происходит, обычно используют статусы:

• На проверке: проверяют реквизиты, сумму, договор, корректность НДС и статью/центр затрат.
• На согласовании: руководители и владельцы бюджета подтверждают необходимость и сумму.
• Отклонено: документ возвращают с причиной.
• К оплате: все проверки пройдены, можно формировать платеж.

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

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

Маршруты согласования: какие бывают и как выбрать

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

Какие маршруты встречаются чаще всего

Компании обычно комбинируют несколько базовых схем:

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

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

Как выбрать маршрут без лишней сложности

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

Полезно заранее ответить на несколько вопросов:

• Какие счета можно согласовывать без руководителя (в пределах лимита)?
• Где нужен параллельный этап, чтобы не ждать одного человека?
• Какие типы расходов требуют отдельной проверки (договор, бюджет, реквизиты)?
• Что делать, если согласующий не отвечает (замена, автоэскалация)?

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

Лимиты и правила: чтобы решения были быстрыми и понятными

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

Лимиты по сумме и по ответственности

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

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

Базовый набор правил обычно выглядит так:

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

Исключения, замещение и причины отказа

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

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

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

Прикрепление первички: как собрать комплект без лишних запросов

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

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

Перед отправкой стоит быстро проверить реквизиты. Ошибки в БИН/ИИН, банке, номере счета или назначении платежа почти всегда ведут к возврату и потере дней. Если поставщик прислал счет в новой редакции, в комплекте должен быть только актуальный вариант.

Чтобы документы не искали по чатам и почте, достаточно нескольких требований: читаемый скан без обрезанных полей, единый формат (часто PDF), понятные названия файлов и правило «без чужих счетов в одной папке». Мелочь, но экономит время на каждом шаге.

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

Контроль сроков оплаты: как не допускать просрочек

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

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

• дата получения/регистрации счета
• срок оплаты по договору или спецификации
• срок, указанный в самом счете (если отличается)
• плановая дата платежа
• крайняя дата, после которой начинаются штрафы или стоп поставок

Дальше работает простое правило: чем раньше видно отклонение от плана, тем дешевле исправление. Для этого задают SLA по этапам, например: проверка комплекта документов - 1 рабочий день, согласование руководителем - 2 дня, финальное утверждение - 1 день. Так понятно, где «съедается» время, даже если общий срок оплаты еще не наступил.

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

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

Хорошая отчетность показывает не просто список просроченных счетов, а узкие места: на каком этапе они застревают и где чаще всего превышается SLA.

Пошаговая настройка процесса: от схемы до запуска

Начните не с системы, а с реальности. Возьмите 10-20 последних счетов и разберите, как они проходили: откуда пришли (почта, ЭДО, бумага), кто проверял, где зависали, кто и почему возвращал на исправление.

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

Затем зафиксируйте лимиты и исключения. Обычно они завязаны на сумму, статью затрат и тип покупки. Пример: счет на оборудование до определенной суммы утверждает руководитель отдела, выше - финдиректор; услуги ИТ идут по отдельному маршруту; срочные платежи проходят ускоренно, но с обязательным комментарием и последующим контролем.

Продумайте карточку счета. Обязательными стоит сделать поля, без которых бухгалтерия не сможет оплатить: контрагент, договор/основание, сумма, валюта, срок оплаты, статья затрат, подразделение, проект, НДС (если применимо). По вложениям заранее закрепите минимум: счет, договор/заказ, акт/накладная (если уже есть) или подтверждение поставки.

Практичный порядок запуска:

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

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

Пример сценария: как проходит один счет от получения до оплаты

Компания получила счет за поставку оборудования. По договору оплата должна пройти в течение 10 календарных дней с даты получения комплекта документов. Задача процесса - провести счет так, чтобы никто не искал файлы по почте и не уточнял суммы вручную.

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

Комплект документов обычно включает договор, счет, спецификацию и подтверждение приемки (акт, накладная или другой документ).

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

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

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

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

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

Самые большие проблемы возникают не из-за программы, а из-за недоговоренных правил. Тогда электронное согласование становится тем же хаосом, только быстрее.

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

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

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

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

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

Короткий чеклист и следующие шаги

Мини-чеклист перед стартом

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

Следующие шаги, чтобы внедрение не затянулось

1. Зафиксируйте «как есть» и «как должно быть» на одной странице. Возьмите 2-3 самых частых типа счетов (аренда, услуги подрядчиков, закупки материалов) и пропишите правила.

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

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

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

Если параллельно вы пересобираете внутреннюю ИТ-основу под такие процессы (почта, ЭДО, хранение документов, учетные системы), важно, чтобы инфраструктура была предсказуемой и поддерживаемой. В Казахстане многие организации опираются на локально произведенные серверы и рабочие станции и услуги системной интеграции от GSE.kz (gse.kz) - это удобно, когда нужно разворачивать и сопровождать корпоративные сервисы в едином контуре.