Как автоматизировать управленческий учет, если есть только бухгалтерская база

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

Коротко, чтобы не возвращаться. Бухгалтерский учёт отвечает на вопрос «как отчитаться перед государством», управленческий — «как заработать». Отсюда расхождения, которые делают бухгалтерский P&L бесполезным для собственника:

• Статьи затрат — для налоговой классификации, а не для решений. Аренда склада и аренда офиса на одной статье; три разных направления бизнеса — на одном 90-м счёте.

• Нет ЦФО, направлений, проектов как сквозной аналитики. Подразделения есть, но они про оргструктуру, а не про ответственность за результат.

• Момент признания — по документам, а не по экономике. Услуга оказана в марте, акт пришёл в мае — доход в мае.

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

• Несколько юрлиц — несколько баз, внутригрупповые обороты никто не исключает.

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

Классика. Раз в месяц выгружаем ОСВ или карточки счетов, в Excel раскладываем статьи по управленческим строкам, добавляем то, чего в бухгалтерии нет, собираем P&L и ДДС. Так начинают почти все, и для компании с оборотом в пару сотен миллионов это может работать годами.

Где ломается — я подробно писал в статье про Excel-учёт, здесь — специфика именно бухгалтерского источника:

• Мэппинг живёт в формулах. Соответствие «статья затрат БУ → строка управленческого P&L» задано в ВПР, который знает один человек. Появилась новая статья в бухгалтерии — она тихо попадает в «прочее» или никуда.

• Нет расшифровки. Строка P&L не разворачивается до документа. «Почему выросли коммерческие расходы?» — идём в бухгалтерскую базу, ищем руками, сверяем с таблицей.

• Баланса нет или он не сходится. P&L и ДДС собираются из оборотов, баланс — из остатков, а связь между ними в Excel не поддерживается. Прибыль есть, денег нет — таблица не объяснит.

• Корректировки затирают историю. «Минус 300 тысяч, потом разберёмся» — правка в ячейке без следа. Через полгода никто не помнит, что это было.

• Скорость. Отчёт готов к 20-му числу, потому что сначала бухгалтерия закрывает месяц, потом финансист неделю сводит. Управлять по таким цифрам уже поздно.

• Несколько юрлиц — несколько выгрузок, ВГО исключаются вручную или не исключаются вовсе.

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

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

Это работает ровно до первого конфликта между требованиями бухгалтера и финансиста, а он наступает быстро:

• Одна проводка — одна методология. Если доход нужно признать в марте, а по документам он в мае, бухгалтер не даст изменить период. Если управленческая амортизация считается по пять лет, а налоговая — по десять, на одном счёте 02 это не уживётся. Любое расхождение между БУ и УУ требует либо параллельных проводок, либо компромисса, в котором проигрывает управленческий учёт.

• Аналитика ограничена. У счёта в типовой конфигурации максимум три субконто, и большинство из них заняты. Добавить «Направление» на 20, 26, 44, 90, 91 — значит перестроить типовые документы и отчёты, которые про это субконто не знают.

• Обновления. Каждое изменение структуры счетов и справочников — конфликт с типовым релизом. Через год база «снята с поддержки» со всеми последствиями.

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

• Бухгалтер становится заложником. Теперь от его аккуратности в заполнении управленческих аналитик зависит отчётность собственнику, хотя это не его задача и не его KPI.

• Несколько юрлиц — по-прежнему несколько баз. Консолидации нет.

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

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

Ключевое слово — документы, а не проводки. Транслируется не «Дт 26 Кт 60 — 100 000», а документ «Поступление услуг: контрагент X, договор Y, статья „Аренда офиса“, подразделение Z, сумма 100 000, НДС 20 000». Из него по правилам УУ формируется своя проводка: Дт 26.УУ (статья «Аренда», ЦФО «Административный») Кт 60.УУ (контрагент, договор), в сценарии без НДС — на полную сумму, в сценарии с выделением НДС — отдельно на 19-й. Правила заданы в таблице: счёт затрат — по характеру статьи, ЦФО — по таблице соответствия подразделений, счёт расчётов — по виду договора. Если правило не сработало — на транзитный счёт, который на конец месяца должен быть пуст.

Что это даёт по сравнению с первыми двумя вариантами:

• Своя методология без конфликта с бухгалтером. Период признания, амортизация, классификация статей — такие, как решил финансовый директор. Бухгалтерия не трогается, обновляется штатно.

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

• Расшифровка до первичного документа. Любая строка P&L — до проводки — до документа бухгалтерии, из которого она получена.

• Мэппинг — настройка, а не формула и не код. Новая статья в бухгалтерии — добавили строку в таблицу соответствия. Изменили правило — перетранслировали период.

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

• Несколько юрлиц — один управленческий контур, в него транслируются документы из нескольких баз. ВГО помечаются и исключаются при консолидации.

• Скорость. Трансляция идёт по мере появления документов, а не после закрытия месяца. Предварительный P&L виден на 2–3-й день, окончательный — когда бухгалтерия закрыла период.

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

Чтобы не казалось, что это серебряная пуля:

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

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

• Это не оперативный учёт. Контур даёт финансовую картину — P&L, ДДС, баланс. Склад в разрезе партий, производственный план, маржа по сделке в реальном времени — это задачи ERP, и подменять её управленческим контуром не стоит.

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

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

Сводная картина:

• Оборот до 200–300 млн, одно юрлицо, методология почти совпадает с бухгалтерской — Excel с наведённым порядком или дополнительная аналитика в БУ. Но с пониманием, что это временно.

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

• Проблема не в финансовой картине, а в операционке (склад, производство, продажи вслепую) — это задача ERP, и управленческий контур будет следующим шагом после неё.

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

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

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

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