директор и машина · финансы · запись № 019 · 21 июля 2026 · Давид Герштейн

Управленческий учёт с нуля: три отчёта, без которых собственник слеп

Расходы компании заметно превышают выручку — на десятки процентов сверх плана. Дефицит кэша по итогам месяца — сумма, ощутимая настолько, что её не хватает даже на зарплаты. Формула здесь простая и её стоит держать в голове дальше: дефицит месяца = расходы за месяц минус фактические поступления за тот же месяц. Разрыв между расходами и выручкой (по среднему в вилке) почти совпадает с заявленным дефицитом. Это не разовая авария, а результат того, что месяцами никто не сверял «прибыль есть» с «деньги есть». Вопрос «управленческий учёт — с чего начать» обычно всплывает, когда разрыв уже случился. Правильнее задавать его раньше.

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

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

Три отчёта вместо одной большой таблицы в Excel

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

Три отчёта закрывают три разных провала. Без ДДС компания узнаёт о кассовом разрыве, когда платить уже нечем. Без П&У раздают бонусы из прибыли, которой на деле не было. А без контроля дебиторки и резервов живут по кругу: получили деньги — потратили — через три месяца клиент требует возврат, а денег уже нет.

ДДС: отчёт, который должен был предупредить за месяц

Финансовый директор рассчитал прибыль за период — заметную для компании сумму — и распределил её между сотрудниками. Тут же выяснилось: денег на оплату рекламы нет, коллеге пришлось вносить личные средства. Разбор показал — кассовый разрыв был виден за месяц-два до того, как случился. Резервный фонд под него никто не создавал.

Похожая история — с финансовым менеджером, который брал деньги под зарплаты и дивиденды, не зная о критических периодах цикла поступлений (четыре недели). Ошибка должна была быть видна уже 15 мая. Резерв на маркетинг не формировался никогда.

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

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

П&У: почему нельзя делить прибыль, которой ещё нет

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

Другая история — мотивация, завязанная не на тот момент. В одной компании спорили: начислять бонус в момент подписания договора с клиентом или дожидаться платежа. Решили — только по факту получения денег. Тот же принцип держит и весь П&У: доход признаётся, когда он реально случился, а не когда кто-то пообещал, что случится.

Отдельно в П&У ломаются необъяснимые скачки статей. Собственник потребовал к утру следующего дня детализацию расходов за два месяца — фонд заработной платы вырос на величину, сопоставимую с несколькими месячными окладами, без единого нового сотрудника на восьмидневке. Без П&У с разбивкой по статьям такой скачок замечают, когда деньги уже потрачены — не раньше.

П&У по одному усреднённому числу за квартал или за год маскирует ровно такие скачки. У руководителя производства средняя зарплата с января держалась на стабильном уровне, но в один из месяцев упала в несколько раз ниже среднего — почти в 4,7 раза, тогда как у другого руководителя в тот же месяц разрыв со средним составил около 1,9 раза. Если смотреть только на средний показатель, такую просадку не видно вообще; она всплывает лишь тогда, когда П&У строится помесячно, а не «в целом за период».

Третий случай — крупные маркетинговые вложения. Компания потратила заметную часть резервных средств на рекламные кампании, и встал вопрос: это текущий расход или инвестиция? Решили привязать к результату — если кампании окупились продажами, расход показывается в полном объёме вместе с доходом; если ушли в убыток, списывается на резервы, без искажения месячных показателей. Это и есть управленческий учёт в действии: не формальная бухгалтерская проводка, а решение, которое честно показывает, что произошло с деньгами и почему.

Резервы и дебиторка: цифры, которые должны быть на экране каждый день

Компания продавала услугу с маржинальностью 25–30% при выручке, которую сама услуга приносила в месяц, но цикл работы занимал три месяца до получения платежа, а расходы приходилось авансировать. Резервов не откладывали. В апреле лимит фонда оказался на порядок меньше реальной потребности. Договорились откладывать 30% от прибыли на резервы — но это решение пришло уже после того, как накопился долг перед поставщиком услуг, заметный для месячного бюджета компании.

Если прикинуть этот резерв в относительных цифрах (оценка, консервативно): прибыль в месяц при указанной выручке и марже 25–30% — это скромная доля от оборота. 30% от этой прибыли — совсем небольшая сумма в месяц. Разрыв между этим темпом накопления и разовой потребностью, которая на порядок больше, виден сразу:

Это ключевой вывод для любого расчёта резерва: сама формула «откладывать N% от прибыли» не работает без проверки, догоняет ли она реальный цикл платежей. Если цикл — три месяца, а резерв копится медленнее, чем растёт потребность, разрыв просто переносится вперёд, а не закрывается.

Похожая логика — в истории с клиентом, который внёс предоплату криптовалютой, а компания из-за курсовой разницы зачислила себе на счёт сумму примерно на 10% больше номинала. Клиент позже потребовал полный возврат в тот же день. Без готового резерва такой возврат — это всегда чей-то кассовый разрыв прямо сейчас. Решение вернуть около 82% от зачисленной суммы, удержав расходы и часть бонуса, — это конкретный пример того, как отсутствие заранее просчитанной политики возвратов конвертируется в потерю около 18% от суммы просто на урегулирование, вместо того чтобы урегулирование было прописано в регламенте заранее.

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

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

И отдельно — вопрос доверия к самим данным, из которых строится отчётность. В одной компании обнаружили: даты создания лидов в CRM самопроизвольно сдвигаются при синхронизации — от 18 до 36 часов. Попади такие искажения в ДДС или в расчёт выручки по периодам — отчёт врёт красиво и уверенно. Прежде чем строить управленческий учёт поверх CRM, стоит убедиться, что она сама не путает даты — я разбирал это отдельно, в кейсе про как CRM врёт с датами.

С чего начать управленческий учёт: четыре шага вместо интуиции

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

Решение свелось к четырём шагам, которые подходят как шаблон для запуска учёта с нуля:

• выгрузить закрытые документы за базовый период с расчётом себестоимости — это фундамент для П&У;
• выгрузить созданные сделки за текущий период — основа для ДДС и прогноза притока денег;
• сравнить помесячный прирост количества и стоимости, отдельно по регионам — здесь видно, где рост реальный, а где — статистическая случайность;
• выявить аномалии в удорожании отдельных статей — то, что в П&У выглядит как необъяснимый скачок вроде резкого роста ФОТ.

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

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

Начинать без месяца подготовки можно с малого: выгрузить ДДС за последние два-три месяца по факту оплат, сложить рядом П&У за тот же период по факту начислений, и отдельно вывести список дебиторки с датами возникновения. Это займёт день, а не квартал — и первую же неделю покажет, где деньги реально теряются, а не где кажется, что теряются.

ИИ в связке: как собирать три отчёта, а не сводить их руками

Руководитель маркетинга однажды за неделю решил задачу, которую два года не могли решить вручную: сопоставить сотни тысяч строк лидов с позициями в поиске и ключевыми словами. Excel такой объём не тянул, а модель справилась за неделю лучше, чем прежний ручной процесс за два года. Тот же принцип работает и в управленческом учёте: три отчёта — это не про креативность, а про объём строк, которые нужно сверить с планом и друг с другом. Это задача, которую не обязательно делать руками каждую неделю.

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

Механика конвейера простая, без экзотики:

1. Источник данных. Ежедневная выгрузка сделок, платежей и закрытых документов через Bitrix24 REST API (или amoCRM API) в Google Sheets, вкладка «raw_dds» — суммы, даты, статьи, счета.
2. Первичная проверка. Google Apps Script по расписанию отправляет строки за сутки в дешёвую модель — она считает отклонение факта от плана по каждой статье и помечает подозрительные строки.
3. Углублённый разбор. Строки с отклонением выше порога уходят в дорогую модель — она формулирует гипотезу причины на основе доступных данных, без домыслов, и просит уточнения там, где данных не хватает.
4. Результат. Помеченные аномалии падают во вкладку «anomalies» и дублируются уведомлением в Telegram-бот финансисту и собственнику.
5. Кто смотрит. Дебиторку и ДДС — финансист ежедневно, сводку по П&У и аномалиям — собственник раз в неделю, в фиксированное время, а не «когда будет минутка».

Промпт для первого шага — намеренно скучный и жёсткий, потому что задача не творческая, а счётная. На вход — JSON-массив строк расходов за период, на выходе — тот же массив с расчётом отклонения и пометкой аномалии:

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

Для каждой строки:
1. Посчитай отклонение факта от плана в процентах: (факт - план) / план * 100.
2. Если |отклонение| больше 15% — пометь anomaly: true.
3. Если anomaly: true, в поле comment коротко (1 предложение) укажи вероятную
   причину, опираясь только на данные из строки. Если причины не видно из
   данных — так и напиши: "требует уточнения у ответственного". Не выдумывай
   факты, которых нет во входных данных.

Верни строго JSON-массив с полями: date, category, plan, fact, deviation_pct,
anomaly, comment. Никакого текста вне JSON.

Модель на этом шаге — дешёвая (уровня GPT-4o-mini или аналогичного класса): задача построчная, без творчества, и счёт может идти на сотни строк в месяц. Дорогая модель подключается только к строкам с anomaly: true — обычно это 5–10% от общего потока, и именно там нужна более развёрнутая формулировка причины для отчёта собственнику, а не для очередной таблицы.

Пример входных данных (три строки из типичного месячного среза, суммы условные — для иллюстрации логики):

[
 {"date":"2026-06-30","category":"ФОТ","plan":950000,"fact":1850000,"comment":""},
 {"date":"2026-06-30","category":"Реклама","plan":501000,"fact":501000,"comment":"счёт на продвижение сайта"},
 {"date":"2026-06-30","category":"Архивный поиск","plan":86000,"fact":100000,"comment":""}
]

Пример ответа модели:

[
 {"date":"2026-06-30","category":"ФОТ","plan":950000,"fact":1850000,
  "deviation_pct":94.7,"anomaly":true,
  "comment":"требует уточнения у ответственного — рост почти вдвое без роста штата"},
 {"date":"2026-06-30","category":"Реклама","plan":501000,"fact":501000,
  "deviation_pct":0,"anomaly":false,"comment":"в рамках плана"},
 {"date":"2026-06-30","category":"Архивный поиск","plan":86000,"fact":100000,
  "deviation_pct":16.3,"anomaly":true,
  "comment":"отклонение выше порога, сверить объём заказов за период"}
]

Именно эти помеченные строки и попадают на экран, который видит финансист каждое утро, — примерно так выглядит вкладка «anomalies» после прогона того же примера (цифры условные):

Инженерная обвязка — без сервера и без отдельной команды разработки. Всё крутится на связке Google Apps Script (триггер по расписанию, ежедневно в 7 утра) плюс Google Sheets как хранилище и Bitrix24 REST API как источник. Ошибки — в отдельную вкладку «errors» с меткой времени и текстом ответа API; при неудачном запросе или таймауте модели скрипт делает до трёх повторов с паузой, а после третьего провала шлёт сообщение в тот же Telegram-бот, что и уведомления об аномалиях, — чтобы сбой конвейера не остался незамеченным неделю.

Экономика: что это стоит и что даёт

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

Разово: настройка выгрузки из CRM, скрипта и промпта — 6–8 часов работы (силами штатного разработчика или самого финансиста, если он умеет в Apps Script) — при обычной часовой ставке специалиста это укладывается в бюджет одного рабочего дня (оценка), без внешнего подрядчика. Для сравнения: не всякая автоматизация требует такого объёма — точечный триггер вроде уведомления о закрытии проекта реферала занимает около 20 минут и решает свою узкую задачу без отдельного конвейера.

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

Экономится время, которое сейчас уходит на ручную сверку. Оценка: сбор трёх отчётов вручную (выгрузка, сведение, поиск расхождений) — около 24 часов в месяц для одного финансиста. Автоматическая выгрузка и первичная фильтрация аномалий забирают у него рутинную часть, оставляя проверку уже помеченных строк — около 10 часов в месяц.

На диаграмме — время финансиста на сверку трёх отчётов: 24 часа в месяц вручную против 10 часов, когда выгрузка и первичная фильтрация аномалий автоматизированы.

Разница — 14 часов в месяц, то есть около 58% времени, которое раньше уходило на ручную сверку (оценка), высвобождается для другой работы финансиста — не считая главного эффекта, который в деньгах не измеряется так же прямолинейно: аномалия вроде резкого роста ФОТ или лимита фонда, упёршегося в потолок при реальной потребности в разы больше, видна не в конце месяца, а на следующий день после появления в данных. Это не гарантированная экономия конкретной суммы — это снятый риск того же порядка, что дефицит месячного бюджета или долг перед поставщиком из кейсов выше. Оцениваю вклад именно автоматизации сборки отчётов отдельно от прочих мер (пересмотра лимитов, регламента резервов) — это разные инициативы, и смешивать их эффект было бы нечестно.

Чек-лист: что сделать в понедельник

• Выгрузить ДДС по факту оплат (не по датам договоров) за последние 2–3 месяца.
• Собрать П&У по факту начислений за тот же период, отдельно пометив крупные разовые статьи вроде маркетинговых вложений.
• Составить список дебиторки с датами возникновения и суммами, отсортировать по сроку просрочки.
• Прописать резерв отдельной строкой бюджета (например, 30% от прибыли) — и сразу прикинуть, догоняет ли этот темп реальный цикл платежей, а не оставлять цифру «на глаз».
• Настроить хотя бы одну автоматическую выгрузку данных (CRM → таблица) вместо ручного сведения каждую неделю.
• Установить порог отклонения (например, 15% от плана) и получать уведомление об аномалии, а не искать её вручную раз в месяц.

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

Частые вопросы

С чего начать управленческий учёт, если раньше вообще не вели?

С ДДС за последние 2-3 месяца по факту — просто выгрузить, что пришло и что ушло по счетам. Это даст первую картину раньше, чем идеальная методология.

Чем ДДС отличается от отчёта о прибылях и убытках?

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

Как часто нужно смотреть на дебиторку и резервы?

Ежедневно, а не раз в месяц — иначе кассовый разрыв виден только тогда, когда его уже нечем закрывать.

#деньги #контроль и надёжность #аналитика и отчётность