Как поставить под контроль просроченные счета без ручного надзора
Просрочка по выставлению счетов бьет не по отчетности, а по деньгам. Пока счет не ушел клиенту, выручка висит в воздухе, менеджер спорит с бухгалтерией о статусе сделки, а собственник видит воронку продаж без реального притока средств. Я внедряю контроль в этой зоне не через общий призыв к дисциплине, а через ясную схему: когда счет создается, кто отвечает за срок, где фиксируется дедлайн, какой сигнал срабатывает при задержке и кто закрывает проблему в тот же день.
Первый шаг — описать путь счета от договоренности с клиентом до отправки. Без длинного регламента, на одном листе. Нужны пять точек: основание для счета, исполнитель, срок подготовки, способ отправки, подтверждение отправки. Если хотя бы одна точка размыта, просрочка будет повторяться. Основанием служит конкретное событие: подписанный договор, согласованная спецификация, заявка, отгрузка, этап работ. Исполнитель назначается по роли, а не по фамилии. Срок задается в часах или в рабочих днях. Формулировка «по мере готовности» разрушает контроль.
Дальше я разделяю просрочки на три вида. Первый — счет не создан. Второй — счет создан, но не отправлен. Третий — счет отправлен без подтверждения получения, а внутри компании он ошибочно считается закрытым. Для каждого вида нужен свой сигнал. Иначе у команды появится красивая таблица с общим статусом, но без понимания, где реальная причина задержки.
Точка контроля
Система контроля начинается не с отчетов, а с карточки задачи. В ней фиксируются дата основания, крайний срок выставления счета, ответственный, сумма, клиент, стадия и причина задержки, если срок сорван. Я не смешиваю эту задачу с общей задачей по сделке. Иначе счет теряется среди звонков, согласований и переписки. У задачи по счету свой срок и свой результат: счет отправлен, клиент получил документ.
Если работа идет в учетной системе или в CRM, достаточно одного обязательного поля со сроком и одного статуса просрочки. Если цифровой контур слабый, подойдет общий реестр. В нем важны не красота и сложные формулы, а порядок обновления. Реестр заполняется в момент появления основания для счета, а не в конце дня и не по памяти. Запись без срока я считаю браком процесса.
Следом я ввожу правило эскалации, то есть передачи проблемы на уровень выше при нарушении срока. Без него контроль превращается в наблюдение. На первом уровне задачу закрывает исполнитель. На втором — руководитель функции разбирает причину в день просрочки. На третьем — собственник получает короткий список задач старше заданного порога. Не весь массив, а только отклонения, которые влияют на денежный поток. Если просрочка попала к собственнику, у записи уже должны быть причина, ответственное лицо и новый срок. Без этих трех пунктов эскалация бесполезна.
Ответственность и ритм
Распространенная ошибка — считать бухгалтерию единственным владельцем процесса. На деле просрочка рождается раньше: менеджер не передал данные, юрист не закрыл формулировки, производство не подтвердило объем, проектная команда не зафиксировала этап. Я назначаю владельца процесса по цепочке. За полноту основания отвечает коммерческий или проектный блок. За корректность реквизитов и формы счета — финансовый блок. За факт отправки и подтвержденияие получения — та роль, которая общается с клиентом по документам. Когда зона ответственности разложена по этапам, спор о виновнике теряет смысл.
Потом задаю ритм контроля. Не недельный, а короткий. Для просроченных задач по счетам подходит ежедневный цикл: утром список новых просрочек, днем разбор причин, вечером закрытие или перенос с обоснованием. Встреча на десять минут лучше длинного совещания раз в неделю. На ней не обсуждают общую картину бизнеса. На ней снимают задержки по конкретным счетам. Формат простой: клиент, сумма, дата основания, причина, действие до конца дня.
Чтобы цикл не превратился в рутину ради галочки, я считаю три показателя. Первый — доля счетов, выставленных в срок от общего числа оснований. Второй — средний возраст просроченной задачи. Третий — сумма зависшей выручки по просроченным счетам. Этого набора хватает для управленческого контроля. Если добавить десяток вторичных метрик, команда начнет обслуживать таблицу вместо денег.
Причины срыва я не оставляю в свободной форме. Нужен короткий кодификатор: нет основания, не хватает данных, ошибка в сумме, спор по условиям, нет согласования, технический сбой, забыли отправить, нет подтверждения клиента. Когда причины записаны одинаково, виден повторяющийся источник потерь. Если половина просрочек идет по коду «не хватает данных», значит проблема в передаче информации из продаж или проекта, а не в бухгалтерии.
Запуск без перегруза
Я запускаю систему в три шага. Сначала беру период за последний месяц и вручную поднимаю просроченные задачи по счетам. Нужна не идеальная история, а реальный список узких мест. Затем настраиваю единый реестр и правила эскалации. После этого провожу две недели в режиме ежедневного разбора. За этот срок вскрываются ложные статусы, пустые поля, дубли задач и привычка откладывать отправку до чего-то напоминания.
На старте не нужен большой регламент. Достаточно короткого описания процесса на одну страницу, списка статусов, перечня причин просрочки и роли каждого участника. Если команда не укладывает процесс в одну страницу, она не управляет им, а пересказывает его. Подробности добавляют позже, когда появляются спорные случаи.
Отдельно я проверяю исключения. Счета на аванс, этапные закрытия, счета по рамочным договорам, корректировки после изменения объема, документы по группе компаний — все нестандартные сценарии любят выпадать из общего контроля. Для них я создаю отдельную пометку в реестре и отдельный срок реакции. Не ради бюрократии, а ради видимости. Неучтенные исключения быстро съедают дисциплину по обычным счетам.
Главный признак работающей системы простой: собственник не ищет просроченные счета вручную и не узнает о них случайно. Он видит короткий список отклонений, понимает причину по каждой позиции и знает, кто закрывает задержку. Когда контроль устроен так, просрочка перестает быть фоном и превращается в управляемый сбой с понятным сроком устранения.
