Коротко
Платежный календарь — это таблица или отчет, где по дням расписаны ожидаемые поступления и списания: кто и сколько должен заплатить, кому и когда платить самим. Смысл простой — увидеть заранее день, когда денег на счете не хватит, и успеть перенести платеж или ускорить дебиторку. Пока обороты небольшие, для этого хватает Excel. Как только счетов становится сотни, а филиалов больше одного, таблица начинает врать: кто-то забыл внести платеж, кто-то держит вкладку с формулой недельной давности, и финансовый директор узнает о разрыве в день, когда его уже нельзя закрыть.
ИИ в этой задаче не заменяет казначея. Он берет на себя две вещи, которые в Excel держатся на честном слове: сбор данных из банка, 1С и CRM в одном месте и прогноз поступлений по вероятности оплаты, а не по дате «как договорились». Дальше человек всё равно решает, какой платеж двигать.
Что такое платежный календарь и зачем он нужен
Платежный календарь отвечает на один вопрос: хватит ли денег на счете в конкретный день, если сложить все ожидаемые движения. В отличие от отчета о прибылях и убытках, здесь не важно, прибыльна компания или нет — важно, когда деньги физически придут и уйдут. Компания может быть прибыльной по итогам квартала и при этом не наскрести денег на зарплату 5-го числа, потому что крупный клиент задержал оплату на две недели.
Структура одна и та же везде: остаток на начало дня, ожидаемые поступления (оплаты клиентов, кредиты, прочие доходы), ожидаемые списания (поставщики, зарплата, налоги, аренда), остаток на конец дня. Если остаток на конец дня уходит в минус — это и есть кассовый разрыв. Смысл календаря в том, чтобы показать его за несколько дней или недель заранее, а не в момент, когда бухгалтерия уже не может провести платеж.
Как его ведут в Excel и 1С — и где это ломается
В малом бизнесе платежный календарь почти всегда стартует как таблица в Excel: один лист на месяц, строки — дни, столбцы — статьи движения денег. Это работает, пока данные вводит один человек и транзакций немного. Проблема в том, что такой файл никогда не обновляется сам: кто-то должен вручную выгрузить банковскую выписку, свести её со счетами на оплату, добавить новые заявки от отделов — и делать это правильно каждый день. На практике так не выходит: файл обновляют раз в два-три дня, а к моменту, когда разрыв виден на экране, реагировать уже поздно.
В 1С ситуация лучше в одном: календарь строится из тех же документов, что и остальной учет — заказы клиентов, счета поставщиков, договоры с графиком платежей. Модуль «Казначейство» в 1С:ERP или 1С:УНФ автоматически подтягивает плановые движения и показывает свободный остаток. Но и здесь есть потолок: 1С хорошо знает, что должно произойти по документам, и куда хуже — что произойдет на самом деле. Она не учитывает, что конкретный клиент почти всегда платит на 5-7 дней позже указанной в договоре даты, а другой — заранее, если напомнить. Плюс живые деньги часто идут мимо документооборота: наличные, переводы через Kaspi, авансы, о которых знает только менеджер продаж и держит в личной переписке, а не в учетной системе.
Второй разрыв — между филиалами и юрлицами. Когда в компании несколько расчетных счетов, несколько ТОО или ИП в структуре, и часть операций проходит через Kaspi Business, а часть — через банк-клиент корпоративного счета, свести общую картину вручную почти невозможно. Финансовый директор либо смотрит на каждый счет по отдельности, либо тратит день в конце недели на сведение всего в одну таблицу, которая устареет уже к вторнику.
Что здесь автоматизирует ИИ
ИИ не решает задачу «нарисовать красивую таблицу» — с этим справляется и обычный отчет. Он полезен там, где нужно превратить разрозненные и не всегда достоверные данные в рабочий прогноз. Технически это чаще всего интеграция GPT-модели с существующими системами, а не отдельное приложение, которое финансовому отделу придется поддерживать самостоятельно.
Прогноз даты фактической оплаты. Вместо даты из договора модель смотрит на историю: как контрагент платил последние 12-24 месяца, есть ли сезонность, задерживает ли оплату систематически или только в декабре. На выходе не «оплата 15-го», а вероятностный диапазон — скорее всего 15-20-е, с уверенностью 70%. Вместо одной жесткой даты появляется коридор, и разрыв виден раньше.
Сбор данных из разных источников. Банковские выписки, 1С, CRM, счета в Kaspi Business, иногда просто скан счета в почте — модель читает документы и сводит их в один поток без ручного переноса. Та же логика, что в ИИ для работы с документами: не заменить бухгалтера, а убрать перенос цифр из одного места в другое руками.
Ранние сигналы о разрыве. Модель смотрит на календарь на 4-8 недель вперед и подсвечивает не только жесткий минус, а зону риска: остаток близко к нулю, крупный платеж поставщику совпадает с неподтвержденной оплатой клиента. Финансовый директор получает не пересчитанную таблицу, а список из трех-пяти дней, которые стоит проверить в первую очередь.
Черновик сценариев. «Что будет, если клиент X не заплатит в срок» или «что если перенести оплату поставщику на неделю» обычно считают вручную, копируя лист в Excel. ИИ собирает такой черновик за минуты, но решение — двигать платеж или нет — остается за финансовым директором: у переноса есть последствия за пределами таблицы, отношения с поставщиком и репутация.
Естественный язык поверх данных. Вместо поиска нужного столбца в громоздком отчете финансист может спросить: «сколько мы должны заплатить поставщикам на следующей неделе» — и получить ответ по текущим данным, а не по состоянию файла на прошлый понедельник.
Что ИИ не должен делать в платежном календаре
Модель не должна сама решать, кому платить в первую очередь, если денег на всех не хватает, — это управленческое решение с юридическими и репутационными последствиями, и оно остается за финансовым директором или собственником. ИИ также не должен быть единственным источником данных об остатке на счете: банковская выписка первична, прогноз вторичен. И вероятность задержки оплаты — это сигнал для внимания, а не основание считать контрагента неблагонадежным.
Отдельно стоит следить за качеством входных данных. Если в 1С заказы вносят с опозданием на неделю, а часть платежей вообще не документируется, никакая модель не даст точный прогноз — она обучится на неполной картине и будет уверенно ошибаться. Разговор про источники данных обычно упирается в тот же список систем, что и в статье про внедрение ИИ поверх 1С, WhatsApp и Excel: у финансового отдела почти никогда не бывает одной чистой базы, есть несколько разных систем, которые нужно свести без ручного переноса.
Пример: как это выглядит на практике
Компания с оборотом в несколько миллиардов тенге и сетью филиалов вела платежный календарь в Excel силами двух бухгалтеров, которые вручную сводили выписки по семи расчетным счетам. Разрывы обнаруживали за один-два дня — этого хватало разве что на срочный овердрафт или звонок ключевому клиенту с просьбой заплатить раньше.
После настройки ИИ-слоя поверх существующей 1С и банковских выписок горизонт видимости вырос до двух-трех недель: модель считала не дату по договору, а фактическую историю платежей по каждому крупному контрагенту. Финансовая команда не потеряла контроль над тем, кому платить в первую очередь, но перестала тратить два дня в неделю на сведение таблиц вручную.
Разрыв между «мы вроде используем ИИ» и «команда реально умеет с ним работать» закрывается и на стороне обучения: привычка проверять цифры через ИИ формируется быстрее, когда финансовая команда разбирает свои же счета и отчеты, а не абстрактные примеры из презентации. Похожий формат мы проводили для финансовой команды Казатомпрома — два дня разбора реальных рабочих сценариев: отчетность, контрагенты, транзакции, а не демонстрация возможностей ChatGPT в вакууме. Корпоративное обучение ИИ вообще имеет смысл строить на живых цифрах компании — иначе после тренинга люди не понимают, как применить это к своему отчету.
Как запустить пилот без замены всей системы учета
Не нужно сразу подключать ИИ ко всем счетам и юрлицам. Разумный первый шаг — один контур: продажи и дебиторка по одному филиалу, где разрывы случаются чаще всего. Дать модели историю платежей за 12 месяцев, банковскую выписку и текущие счета на оплату, сравнить прогноз с тем, что реально произошло, за 4-6 недель — и только после этого расширять на остальные счета.
Важно с самого начала договориться, кто смотрит подсвеченные риски каждое утро и кто утверждает перенос платежей. Без владельца процесса даже точный прогноз останется красивым отчетом, который никто не открывает.
Как понять, что автоматизация сработала
Три практических признака: горизонт, на котором виден разрыв, вырос с одного-двух дней до двух-трех недель; финансовая команда тратит на сведение данных часы, а не дни в неделю; количество экстренных решений — срочный овердрафт, звонок с просьбой ускорить оплату — снизилось за квартал. Если после внедрения финансовый директор продолжает вручную проверять каждую цифру в отчете, потому что не доверяет источнику данных, значит проблема не в модели, а в качестве данных на входе — и решать нужно её, прежде чем расширять систему.
FAQ
Платежный календарь и бюджет движения денежных средств — это одно и то же?
Нет. Бюджет ДДС — план на более длинный горизонт, обычно на месяц или квартал, с меньшей детализацией. Платежный календарь — оперативный инструмент на дни и недели вперед, где важна точная дата, а не общая сумма за период.
Нужно ли для этого менять 1С на другую систему?
Обычно нет. ИИ-слой можно поставить поверх существующей 1С и банковских выписок как источник прогноза и сводной картины, не меняя основной учет.
С чего начать, если сейчас всё в Excel?
С одного филиала или одного контура — продажи и дебиторка — и с истории платежей за последний год. Это позволяет проверить точность прогноза до того, как расширять его на всю компанию.
Сколько времени занимает первый пилот?
Обычно 4-6 недель хватает, чтобы сравнить прогноз с фактическими платежами и понять, стоит ли расширять контур.
Если платежный календарь в компании уже превратился в файл, который переписывают заново каждую неделю, разумнее не менять инструмент на более сложный, а добавить прогноз поверх того, что есть — и посмотреть, на сколько дней раньше стал виден следующий разрыв.