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

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

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные.

Простой вопрос: вы можете прямо сейчас, не открывая ничего, назвать, сколько денег придёт на счёт на следующей неделе и сколько уйдёт? Если нет — вы не управляете компанией, вы её сопровождаете. Извините за прямоту, но по-другому это не назвать.

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

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

Расходы компании составили 13,8 млн ₽ при выручке 12 млн ₽ за месяц — превышение на 15%. Дефицит кэша по итогам месяца — 1,8 млн ₽, и этой суммы не хватило даже на зарплаты. Формула здесь простая, и её стоит держать в голове дальше: дефицит месяца = расходы за месяц минус фактические поступления за тот же месяц. В нашем случае 13,8 млн минус 12 млн — те самые 1,8 млн ₽ дефицита, ни рублём меньше. Это не разовая авария, а результат того, что месяцами никто не сверял «прибыль есть» с «деньги есть». Вопрос «управленческий учёт — с чего начать» обычно всплывает, когда разрыв уже случился. Правильнее задавать его раньше.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если экстраполировать ту же логику на типичный отдел продаж: 8 менеджеров, средний чек 250 000 ₽, оборот около 12 000 000 ₽ в месяц — это примерно 48 сделок. Если 10% из них регулярно зависает в дебиторке дольше срока оплаты по договору, под риском оказывается около 1 200 000 ₽ в месяц (оценка, консервативно). Именно эту цифру должен видеть на экране финансист каждый день, а не раз в квартал в сводном отчёте.

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

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

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

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

С чего начать: четыре шага вместо интуиции

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

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

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

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

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

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

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

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

Руководитель маркетинга однажды за неделю решил задачу, которую два года не могли решить вручную: сопоставить сотни тысяч строк лидов с позициями в поиске и ключевыми словами. 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). При ставке ~1 000 ₽/час это 6 000–8 000 ₽ разово (оценка), без внешнего подрядчика. Для сравнения: не всякая автоматизация требует такого объёма — точечный триггер вроде уведомления о закрытии проекта реферала занимает около 20 минут и решает свою узкую задачу без отдельного конвейера.

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

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

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

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

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

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

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

И главное, ради чего всё это. Управленческий учёт — не бухгалтерия и не отчётность для банка. Это ваши глаза: без них вы принимаете решения на ощупь и списываете последствия на рынок, сотрудников или сезон. Читать три своих отчёта — такой же базовый навык руководителя, как считать маржу: вы не делегируете его финдиректору целиком, ровно как не делегируете умение говорить с клиентом.

Начните с одного отчёта — ДДС на четыре недели вперёд. Час работы, обычная таблица. Если через неделю вы поймаете хотя бы один платёж, о котором забыли, — считайте, что час окупился. У меня он окупился в первый же раз, и с тех пор я не понимаю, как жил иначе.

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

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

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

Управленческий учёт — это то же самое, что бухгалтерский?

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

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

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

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

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

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

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

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