Бюджет доходов и расходов: как собрать БДР с помощью ИИ

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

Разница видна на двух примерах. Купили оборудование за 6 млн рублей и заплатили сразу — в БДДС ушло 6 млн одной суммой в месяце оплаты, в БДР в этом месяце не появилось ничего, расход пойдёт частями через амортизацию несколько лет. Отгрузили товар в марте с отсрочкой до мая — выручка встала в БДР в марте, а деньги в БДДС придут в мае. Поэтому прибыльная по БДР компания может не иметь денег на зарплату, а компания с полным расчётным счётом — работать в убыток. Оба отчёта нужны вместе, и спорить, какой «главнее», смысла нет.

Дальше в статье — не про теорию бюджетирования, её в поиске достаточно. Дальше про то, как перестать собирать БДР руками: где конкретно уходит время, что из этого отдаётся ИИ, какими промптами и с какими проверками.

Где в сборке БДР уходит время

Если разобрать месячный цикл по шагам, картина почти везде одинаковая. Сам расчёт занимает минуты. Время съедает подготовка данных.

Сначала выгрузка. Данные достают из OLAP-куба или учётной системы, причём часто в два приёма — за текущий год и за прошлый, потому что целиком не выгружается. Получается файл на сотни тысяч строк, который Excel открывает медленно и пересчитывает ещё медленнее.

Потом разметка. К каждой строке нужно подтянуть аналитику: округ, объект, направление, статью БДР. Часть подтягивается через ВПР из справочного файла, часть проставляется руками — человек ставит фильтр, выделяет блок строк и присваивает значение. Это самый долгий и самый хрупкий этап: фильтр снят не полностью, значение проставлено на лишние строки, и ошибка всплывёт только на сверке.

Потом чистовик. Обработанные данные копируются в отдельный файл как значения, чтобы формулы не поехали. Потом сверка: сводные суммы по основным статьям сравнивают с P&L из учётной системы суммарно по группе округов. Если сходится — отчёт уходит дальше. Если нет — начинается поиск, где именно потерялись строки, и цикл повторяется.

И всё это — каждый месяц заново, теми же руками.

Что ИИ здесь делает, а что нет

Сразу про ограничение, из-за которого большинство попыток заканчивается ничем. Языковая модель не считает арифметику по вставленному в чат тексту. Она работает с текстом, и если попросить её просуммировать колонку из трёх тысяч строк, она выдаст правдоподобное число. Правдоподобное — не значит верное. В управленческой отчётности это худший из возможных сценариев: ошибка не видна, потому что порядок цифр правильный.

Рабочая схема другая: модель не считает, а пишет код, который считает. В ChatGPT есть режим анализа данных — можно прикрепить файл и попросить выполнить Python-код прямо в диалоге, результат придёт вместе с готовым xlsx. У Claude есть инструмент анализа, который выполняет код и разбирает приложенные таблицы. Gemini подключается к Google Таблицам, Copilot — к Excel. Инструмент вторичен, принцип один: считает код, модель только его пишет и объясняет.

Отсюда честное разделение. ИИ хорошо закрывает сопоставление названий — когда 180 строк справочника выгрузки нужно разложить по 14 статьям БДР. Хорошо пишет разовый скрипт разметки, который заменяет ВПР и ручные фильтры. Хорошо ищет расхождения между двумя таблицами и отбирает отклонения по заданным порогам. Хорошо превращает готовую таблицу отклонений в текст справки.

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

Шаг 1. Закрепить справочник статей

Автоматизировать нечего, пока правило живёт в голове. Если один человек относит доставку до клиента к коммерческим расходам, а другой — к себестоимости, никакой скрипт это не исправит.

Первый шаг — вытащить правило наружу. Выгружаете уникальные значения статьи из учётной системы (в Excel это «Удалить дубликаты» по колонке со статьёй) и рядом кладёте утверждённый справочник статей БДР. Дальше просите модель сопоставить одно с другим.

Ты финансовый контролёр. Ниже два списка.

Список А — уникальные значения колонки «Статья ДДС» из выгрузки
учётной системы.
Список Б — утверждённый справочник статей БДР.

Задача: сопоставить каждое значение из списка А ровно одной статье
из списка Б.

Формат ответа — таблица из трёх колонок:
значение из выгрузки | статья БДР | уверенность (высокая / низкая).

Правила:
1. Использовать только статьи из списка Б. Новые не придумывать.
2. Если значение можно отнести к двум статьям или непонятно
   по названию — ставь «низкая».
3. Все строки с «низкая» продублируй в конце отдельным блоком
   «Требует решения человека» и в одну строку объясни, в чём
   неоднозначность.

Список Б (справочник БДР):
<вставить>

Список А (значения из выгрузки):
<вставить>

Модель разложит по очевидным совпадениям сразу, а спорное вынесет отдельно — обычно это 10–20% позиций. Этот короткий список и есть предмет для разговора с финансовым директором: пятнадцать минут решений вместо бесконечных разовых трактовок. Результат сохраняете как файл соответствия — он понадобится на каждом следующем шаге и переживёт следующий месяц.

Шаг 2. Разметка аналитик — кодом, а не фильтрами

Когда справочник соответствия есть, ручная разметка перестаёт быть нужна. Вместо ВПР построчно и выборок по фильтрам пишется скрипт, который делает это за один проход.

Промпт ниже даёт не только обработку, но и контроль — это в нём главное.

Во вложении два файла.

1. data.xlsx — выгрузка из учётной системы, лист «data».
   Колонки: Дата, Округ, Объект, Статья ДДС, Контрагент, Сумма,
   Признак (план/факт).
2. mapping.xlsx — справочник соответствия «Статья ДДС → Статья БДР».

Напиши и выполни Python-код, который:
1) приводит Дату к формату месяца YYYY-MM;
2) подтягивает статью БДР из справочника по точному совпадению
   названия, без подбора похожих;
3) строки, для которых совпадение не найдено, складывает
   в отдельный лист «не сопоставлено»;
4) строит сводную: строки — статьи БДР в порядке справочника,
   колонки — месяцы, значения — сумма, отдельно по плану и факту;
5) сохраняет результат в xlsx листами «БДР», «не сопоставлено».

До выгрузки выведи в ответ контрольные цифры:
- число строк на входе и после обработки;
- сумму колонки «Сумма» до и после;
- число строк и сумму в листе «не сопоставлено».

Если сумма до и после не совпадает — не сохраняй файл,
а покажи, на каком шаге потерялись строки.

Фраза «без подбора похожих» стоит там не для красоты. Модель по умолчанию старается быть полезной и сама сопоставит «Аренда помещений» с «Аренда» — иногда верно, иногда нет, и вы об этом не узнаете. Пусть лучше строка попадёт в «не сопоставлено»: этот лист вы просмотрите глазами за минуту, а тихо приклеенную не туда сумму не найдёте никогда.

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

Шаг 3. Сходимость с P&L — до отправки, а не после

Сверка сводных данных с P&L по основным статьям — тот этап, из-за которого отчёт возвращается на доработку. Его стоит делать сразу после разметки, пока свежа память о том, что и куда вы отнесли.

Два вложения:
- bdr.xlsx — сводная БДР по группе округов, которую собрал я;
- pl.xlsx — выгрузка P&L из учётной системы за тот же период.

Напиши и выполни код, который сопоставляет их по статьям
и периодам и выводит таблицу расхождений:
статья | период | сумма в БДР | сумма в P&L | разница | доля разницы
от суммы P&L в процентах.

Строки с нулевой разницей не показывай.
Сортируй по абсолютной величине разницы, по убыванию.

Если названия статей в файлах не совпадают дословно — не подбирай
похожие. Вынеси такие статьи в отдельный блок «не удалось
сопоставить» с суммами из обоих файлов.

В конце выведи: итог по БДР, итог по P&L, общую разницу.

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

Шаг 4. План-факт: отбор отклонений по правилам, а не по ощущениям

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

Порог надёжнее глаза. Задайте два условия одновременно — относительное и абсолютное.

Во вложении таблица план-факт за месяц: статья БДР, план, факт.

Напиши и выполни код, который добавит колонки «отклонение, ₽»
и «отклонение, %» и вернёт три блока:

1. Статьи, где отклонение больше 10% И больше 300 000 ₽
   одновременно. Сортировка — по абсолютной сумме отклонения.
2. Статьи, по которым стоял план, но факт нулевой.
3. Статьи, по которым есть факт, но плана не было вовсе.

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

Последняя строка важнее всего остального промпта. На вопрос «почему выросли расходы на логистику» модель выдаст складный абзац про рост тарифов перевозчиков и сезонность — не потому, что это правда, а потому, что так обычно пишут. Причину знает тот, кто работает с этой статьёй. Модель даёт список того, что требует объяснения, объяснение вы вписываете сами.

Пороги настраиваются под компанию: для округа с оборотом 50 млн разумнее ставить 500 тысяч, для отдельного проекта — 50 тысяч. Главное, чтобы порог был записан и не менялся от месяца к месяцу, иначе сравнивать нечего.

Шаг 5. Справка на оперком из готовой таблицы

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

Ниже — таблица отклонений план-факт за август. В скобках после
каждой строки — моя пометка о причине.

Собери справку на оперком, не больше одной страницы:
- «Итог по прибыли»: план, факт, отклонение в рублях и процентах;
- «Три главных отклонения»: по одному абзацу, сумма, процент,
  причина из моей пометки;
- «Требует решения на совещании»: пункты, по которым в пометках
  стоит знак вопроса, — сформулируй их как вопрос к конкретной
  роли (коммерческий директор, руководитель логистики).

Цифры бери только из таблицы, новых не добавляй.
Не используй слова «значительно», «существенно», «заметно» —
вместо них ставь сумму и процент.

Таблица:
<вставить>

Дальше справка идёт в совещание, и там появляется вторая задача — протокол. Если решения по каждому объекту или статье приходится потом расписывать вручную по отдельным чек-листам, это отдельная история, и она разобрана в статье про сборку протокола совещания. Общий отчёт руководителя по итогам периода собирается по схожей логике — про это есть разбор с готовыми промптами.

Что сделать, чтобы это работало каждый месяц

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

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

Второе — фиксировать версию справочника соответствия. Статьи добавляются, объекты открываются и закрываются. Если справочник лежит в одном месте и у него есть дата обновления, расхождения между месяцами объяснимы. Если у каждого своя копия — нет.

Третье — решить вопрос с данными до того, как он всплывёт. Управленческая отчётность содержит выручку по объектам, контрагентов и условия договоров. В личных тарифах ChatGPT и Claude использование переписки для улучшения моделей включено по умолчанию и отключается вручную в настройках — это описано в справке OpenAI по управлению данными, и проверить настройку стоит до первой загрузки файла, а не после. В корпоративных тарифах режим по умолчанию другой, но полагаться на пересказ не надо: читайте документацию и договор. Простой обходной путь на первое время — обезличивание: контрагенты и объекты заменяются кодами (К-1, О-17), расшифровка остаётся в вашем файле. Суммы и структура при этом не теряются, а чувствительное наружу не уходит.

Четвёртое — не пытаться автоматизировать весь цикл сразу. Возьмите один шаг, на котором уходит больше всего времени. Судя по формулировкам в анкетах, это почти всегда разметка аналитик — ВПР построчно и присвоение значений через фильтры. Закройте его, прогоните два месяца, убедитесь, что контрольные суммы сходятся, и только потом беритесь за следующий.

С чего начать на этой неделе

Возьмите последнюю сданную выгрузку — ту самую, с которой вы уже собирали БДР руками, и результат которой известен и проверен. Это важно: первый прогон нужен не для экономии времени, а для сверки с эталоном.

Выгрузите уникальные значения статьи, прогоните промпт из первого шага и посмотрите на блок «требует решения человека». Это займёт минут двадцать и сразу покажет, насколько ваш справочник однозначен. Затем прогоните разметку кодом и сравните контрольные суммы с тем файлом, который вы сдали в прошлом месяце. Сойдётся — можно переносить на боевой цикл. Не сойдётся — вы получили список мест, где правило не записано, и это тоже полезный результат: именно эти места каждый месяц съедали ваше время и в ручном режиме.