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

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

Типичная ситуация. Финансовый директор отлично понимает, как должен выглядеть P&L, какие ЦФО, как распределяются косвенные расходы. Это знание живёт у него в голове и частично — в Excel-модели. Подрядчик понимает, как работает система. Встречаются, обсуждают, расходятся довольными. Через три месяца оказывается, что «себестоимость» для финансиста — это прямые затраты плюс распределённые ОПР, а в системе настроили по учётной себестоимости; что «подразделение» в P&L — это ЦФО, а в документах 1С указано подразделение оргструктуры, и они не совпадают.

Каждое такое расхождение — переделка. Переделка после запуска стоит в 3–5 раз дороже, чем правило, записанное до начала. И главное: каждая переделка подрывает доверие — заказчик начинает думать, что систему «настроили неправильно», хотя на самом деле её настроили по неполному заданию.

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

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

• Периметр: какие юрлица, какие направления бизнеса входят в управленческий учёт, какие — нет.

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

• Валюта учёта и правило пересчёта, если операции в разных валютах.

• Сценарии учёта. Например, «Факт» и «Факт с НДС»: в первом НДС выделяется на отдельные счета, во втором — сидит в сумме.

• Периодичность закрытия и срок готовности отчётности: ежемесячно, к 5-му рабочему дню. Эта цифра определяет, какие данные успевают попасть в учёт, а какие придётся начислять оценочно.

• Допустимость ручных операций: можно ли вносить проводки руками, кто имеет право, как они помечаются.

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

Главное решение, которое отличает учёт от «отчёта»: управленческий учёт ведётся на плане счетов с двойной записью. Не потому что так привыкли бухгалтеры, а потому что двойная запись — единственный механизм, при котором баланс сходится по построению, а ошибка не может жить незамеченной. Об этом я подробно писал в статье про Excel: учёт без баланса — это учёт, который невозможно проверить.

Управленческий план счетов — не копия бухгалтерского. Он может быть построен на его основе (так проще бухгалтерам и финансистам), но должен отражать то, как компания смотрит на бизнес. В описании каждого счёта фиксируется:

• Код и наименование, признак активный/пассивный/активно-пассивный, забалансовый или нет.

• Валютный ли счёт (тогда обязательны валюта и валютная сумма), количественный ли (обязательно количество).

• Набор аналитик (субконто) — обычно до трёх-четырёх на счёт, с указанием, какие из них оборотные, а какие остаточные.

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

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

Раздел, который кажется техническим, но именно он определяет, какие отчёты в принципе можно будет построить. Для каждой аналитики фиксируется: что это (ЦФО, проект, статья доходов и расходов, статья ДДС, контрагент, договор, номенклатура, склад, сотрудник), какой тип значений и — главное — откуда она берётся в источнике.

Пример из наших моделей: аналитика «Подразделение» в управленческом учёте — это справочник ЦФО, а в источнике — справочник подразделений 1С. Они не совпадают один к одному: три отдела входят в один ЦФО, один цех разделён на два направления. Значит, нужна таблица соответствия и правило для случая, когда соответствия нет. Если этого не записать, система отнесёт расходы «куда-то», и P&L по ЦФО будет выглядеть убедительно и врать.

Здесь же — состав справочников. Статей доходов и расходов должно быть столько, сколько нужно для решений, а не столько, сколько накопилось в бухгалтерии за десять лет. Если в бухгалтерии 300 статей затрат, а в управленческом P&L 40 строк — нужна таблица соответствия 300 → 40. То же относится к статьям бюджета, если план-факт — часть задачи.

Самый объёмный раздел и сердце модели. Для каждого вида хозяйственной операции в источнике (поступление товаров, реализация, оплата, начисление зарплаты, амортизация, перемещение, списание…) описывается, какую проводку управленческого учёта она формирует: дебет, кредит, откуда берутся сумма, количество, валюта, каждая аналитика, по какому сценарию.

Общие принципы выносятся отдельно, чтобы не повторять их в каждой строке. Например:

• Счёт учёта ТМЦ определяется по виду номенклатуры; если не определён — транзитный счёт.

• Счёт учёта затрат определяется по характеру затрат, заданному в статье; если не задан — транзитный счёт.

• Счёт взаиморасчётов определяется по виду договора.

• Проводки с выделением НДС и без — в разные сценарии, исключения — в примечаниях.

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

И ещё одно: мэппинг — это документ, по которому потом можно проверить систему. «В модели написано, что аренда склада идёт на 25 счёт по статье «Аренда» и ЦФО «Логистика». В системе она ушла на 26. Ошибка настройки». Без модели этот спор звучит иначе: «а мы думали, что это общехозяйственные».

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

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

Это второй по частоте источник расхождений ожиданий. Финансовый директор «всегда распределял по выручке», но в его Excel-модели по выручке распределялись только три статьи из десяти, остальные — «по-разному, смотря что». Пока это не записано, система не сможет это повторить, а когда повторит — результат не совпадёт с привычным.

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

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

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

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

Раздел, с которого заказчик обычно хочет начать — и с которого начинать нельзя. Отчёт — следствие плана счетов, аналитик и мэппинга. Если описать сначала его, в середине проекта выяснится, что данных для половины строк нет.

Но описан он должен быть предельно конкретно. Для каждой формы — P&L, ДДС, баланс, отчёты по ЦФО и направлениям — фиксируются общие принципы (уровень формирования, валюта, периодичность, с НДС или без, исключаются ли ВГО) и построчно формула: «Выручка от реализации без НДС = кредитовый оборот 90.01 минус дебетовый оборот 90.03 по статьям доходов». «Денежные средства на конец периода = сальдо конечное по счетам 50, 51, 52, 57». «Валовая прибыль = строка 1 минус строка 2».

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

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

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

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

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

Функциональная модель — скучный документ. В нём нет красивых дашбордов, зато есть тридцать страниц таблиц с номерами счетов. Но именно он превращает «автоматизируйте нам управленческий учёт» из пожелания в задачу. И именно он делает возможным единственный честный способ приёмки: не «нравится — не нравится», а «соответствует модели — не соответствует».

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

Реклама: ИП Шарипов Руслан Рафикович, ИНН 780226784621, erid: 2W5zFGaAkr6