Когда типовой 1С:ERP недостаточно для управленческого учета: как финансовому директору не переплатить за доработки

Начинаются доработки. Через год система обвешана «костылями», каждое обновление превращается в отдельный мини-проект, а бюджет заметно превысил первоначальный.

Проблема здесь не в ERP. Проблема в том, что инструмент выбрали до того, как сформулировали требования. В этой статье разберу, что умеет и чего не умеет типовая 1С:ERP в управленческом учете, где проходит граница между ней и 1С:Управление холдингом (УХ), и как финансовому директору подойти к выбору так, чтобы не переделывать проект на ходу.

Оговорка: речь об актуальных релизах 1С:ERP 2.5 и 1С:УХ 3.x на момент написания (октябрь 2026). Функциональность меняется от релиза к релизу, и критичные для вас сценарии стоит проверять на актуальном релизе, а не по статьям — включая эту.

Сразу расставлю акценты. 1С:ERP — сильная система оперативного, производственного и регламентированного учета: закупки, склад, производство, себестоимость, продажи, РСБУ. Для большинства компаний это надежный операционный «хребет». 1С:УХ — сильное решение класса CPM: консолидация, МСФО, корпоративное бюджетирование, казначейство, управление НСИ.

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

Прежде чем говорить об ограничениях, зафиксируем, что обычно входит в требования:

1.     Сходящийся управленческий баланс — актив равен пассиву по построению, через двойную запись, а не потому что кто-то постоянно ищет и устраняет расхождения.

2.     Расшифровка любой строки до первичного документа. Если дебиторка выросла на 40 млн — за несколько кликов видно, по каким контрагентам и документам.

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

4.     Многомерная аналитика. ЦФО × проект × продукт × канал × сегмент — сквозная, на всех участках учета.

5.     Распределение затрат по своим базам и в несколько ступеней, с возможностью видеть P&L «до» и «после»¹ аллокации.

6.     Оперативность. Отчетность на 3–5 рабочий день, а не после¹ закрытия регламентированного периода.

7.     Для групп компаний — единая управленческая валюта, межфирменные операции, исключение внутригрупповых оборотов, консолидация.

8.     Аудиторский след. Любая корректировка — кто, когда, на основании чего.

Автоматизация управленческого учета

Подобрать решение для автоматизации

Подробнее

Это основной вариант для компаний, которые не разворачивают отдельный финансовый контур. Данные собираются из регистров накопления (себестоимость, взаиморасчеты, денежные средства, доходы и расходы), а отчеты «Управленческий баланс», «Финансовый результат» и «Контроль баланса» сводят их по заданным правилам. Расшифровка до документа есть, но с нюансами - из отчета по финансовому результату ее не получить, нужно смотреть другие отчеты. Статьи активов и пассивов можно добавлять, для нестандартных операций есть документы «Прочие активы и пассивы» и «Отражение прочих доходов и расходов».

Что это означает на практике для финансового директора:

• Нет гарантированной двойной записи. Баланс и корреспонденции реконструируются по движениям оперативных регистров, а не формируются двойной записью на плане счетов. Отчет «Контроль баланса» покажет расхождение — но покажет его как ошибку, которую нужно найти и устранить. Разные регистры могут по-разному отразить одну и ту же операцию, и поиск источника расхождения — ручная работа. Часто довольно трудоемкая. Привычного финансисту инструментария (анализ счета, карточка счета по произвольному управленческому плану) здесь нет.

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

• Одна управленческая валюта на базу для оперативного управленческого учета (плюс валюта регламентированного учета).

• Ограниченные внутригрупповые операции. Открыли филиал в Казахстане? Типовой документ Передача товаров между организациями не работает с разными валютами.

• Аналитика зависит от участка. Финансовый результат можно получить по направлениям деятельности, подразделениям, менеджерам, заказам, сделкам... Но аналитика не произвольна – только та, что заложена в системе. В качестве аналитики статьи затрат можно выбрать только ту, что заложена разработчиками — и только одну аналитику.

• Финансовый результат только с НДС. Несмотря на то, что все данные есть, типовая конфигурация позволяет получать P&L только с НДС – весьма редкий вариант в наше время.

Вывод: вариант подходит компаниям, которым не нужен сложный P&L, ДДС, а методология близка к логике 1С. Если требуется собственный управленческий план счетов и произвольный набор аналитик, многовалютный учет или нормальная консолидация — этот путь ведет к доработкам.

Соблазнительный вариант: двойная запись, ОСВ, анализ счета — всё привычно. Но план счетов — РСБУ, аналитика — та, что заложена для БУ. Как только управленческая методология отличается от бухгалтерской (а она отличается почти всегда), механизм начинает буксовать: управленческие корректировки, записанные в регламентированный контур, искажают регламентированную отчетность, под ЦФО и проекты требуется доработка субконто, что может затронуть РСБУ — делать надо крайне аккуратно. Плюс отражение документов в регламентированном учете идет отложенно — оперативность ограничена.

Я не знаю компаний, которые бы реально использовали данный вариант на практике.

На первый взгляд – это самый адекватный вариант ведения управленческого учета в ERP. Есть несколько способов получения отчетности:

- параллельный учет, когда документы вводятся независимо от БУ

- трансформация отчетности, когда мы в отчетность РСБУ вносим необходимые корректировки

- трансляция операций, когда по таблице соответствий данные трансформируются из данных РСБУ.

- комбинированный метод указанных выше вариантов

Где ограничения:

• Типовая модель ориентирована на РСБУ. Со всеми вытекающими недостатками для целей УУ.

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

• Трудоемкость настройки. По моему опыту, заполнение факта и настройка закрытия месяца с распределениями в МФУ требуют значительных усилий, а функционал настройки трансляций операций сильно ограничен.

• Консолидации нет. Групповая консолидация с долями, гудвилом и элиминациями — функциональность УХ / ERP.УХ.

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

УХ закрывает то, чего нет в обычной ERP: консолидация с исключением ВГО, доли владения, гудвил, полноценная мультивалютность, сбор данных от «дочек» на разных системах (включая не-1С), корпоративное бюджетирование, казначейство, управление НСИ.

При этом важно понимать модель. УХ может работать в трех режимах: как CPM-система сбора и консолидации форм, как трансформационный контур поверх ОСВ дочерних обществ, и как транзакционный контур — с трансляцией проводок на план счетов МСФО и параллельным учетом отдельных объектов (ОС, аренда, финансовые инструменты). Учетное ядро — «1С:Бухгалтерия 8 КОРП».

Что из этого следует для управленческого учета:

• УХ не ведет первичный операционный учет производства, продаж и закупок. Управленческие и МСФО-данные формируются из учетных источников — своих или внешних. Оперативность определяется регламентом загрузки и готовностью данных в источниках. Еженедельный управленческий баланс технически возможен при соответствующей периодичности, но типичный проект консолидации ориентирован на месяц.

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

• Управленческая логика, отличная от МСФО (трансфертные цены, внутренние ставки, собственные правила распределения), реализуется через настройку правил трансляции, корректировки и бюджетные модели. Это возможно, но требует специалистов по УХ и методологического проекта.

• Это решение корпоративного класса: методология, интеграция, сопровождение. С соответствующей стоимостью. Для среднего бизнеса с одной-двумя компаниями оно, как правило, избыточно.

Связка ERP + УХ есть как единый продукт «1С:ERP. Управление холдингом». Единая база снимает интеграционные разрывы, но повышает требования к производительности и тестированию при обновлениях. Кроме этого, у продукта высокая цена как в части внедрения, так и в дальнейшей поддержке. Кроме этого, часть указанных выше ограничений сохраняется.

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

• P&L с НДС и без НДС одновременно. Про то, что без НДС финансовый результат не получить , уже писал выше. Иногда собственник хочет видеть оба варианта – на переходный период. Учет на регистрах ERPдает результат только с НДС, второго параллельного варианта не предусмотрено. Баланс тоже, соответственно, в типовом варианте – только с НДС.

• Директ-костинг для себя, полная себестоимость — для головного офиса. Один и тот же факт, но два набора правил закрытия месяца. В ERP можно по-разному настроить распределение в управленческом и регламентированном учете, но две управленческие модели параллельно — уже нет.

• Многоступенчатое распределение по своим базам. Сначала общие расходы делятся по подразделениям пропорционально выручке, затем внутри подразделения — по отработанным часам. Транзитные статьи в ERP есть, но произвольные базы и цепочки правил — ограничены.

• Распределение с условиями. Проектная организация: пока проект идет, фактические затраты закрываются пропорционально плановым; когда проект закрыт или выручка достигла 95% плана — закрываются полностью. Условной логики такого рода в типовом закрытии месяца нет.

• Два периметра консолидации. 14 юрлиц; для одного отчета «своими» считаются 5 из них, для другого — все 14. Один факт, разные правила исключения ВГО. В ERP консолидации нет, в УХ параллельное ведение двух периметров — возможно, но с оговорками.

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

Я не против доработок как таковых. Я против доработок, которые идут поперек архитектуры. Разница принципиальна.

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

• Затягивают проект. То, что в подходящем инструменте настраивается, в неподходящем — программируется, тестируется и отлаживается.

• Удорожают владение. Чем больше изменена типовая конфигурация, тем больше объем тестирования при каждом обновлении релиза. Через несколько лет расходы на поддержку доработок становятся заметной статьей ИТ-бюджета.

• Создают зависимость от конкретной команды, которая знает, «как оно устроено».

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

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

Правильный порядок — обратный тому, который встречается чаще всего. Не «купили ERP, теперь думаем, как в ней вести управленческий учет», а:

1. Определите, какая отчетность нужна бизнесу. Не «всё и в разрезе всего», а конкретный набор форм: для собственника, для совета директоров, для банка, для операционного менеджмента. С периодичностью и сроками. Если управленческий баланс нужен на 5-й день — это требование, которое отсекает часть вариантов.

2. Опишите методологию. Статьи, правила признания, базы распределения, периметр консолидации, управленческая валюта, отличия от РСБУ. Это документ, который должен написать финансовый блок, а не внедренец. Но грамотный внедренец может помочь его написать, задать нужные вопросы, подсветить неоднозначные правила и формулировки.

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

4. Только теперь выбирайте инструмент — и проверяйте сценарии на демобазе, а не по презентации.

5. Проведите пилот на реальных данных до подписания полноценного договора на внедрение. Сквозной пример, закрытие месяца с правкой задним числом, расшифровка строк «НЗП» и «Расчеты с ВГО» до документа, аллокация расходов УК по двум разным базам. Пилот требует подготовки НСИ, примеров операций и критериев приемки — но это несопоставимо дешевле переделки на этапе опытной эксплуатации.

У каждого инструмента своя ниша и своя модель использования. ERP — операционный и производственный учет плюс финансовый контур с ограничениями по методологии; УХ — консолидация и корпоративная отчетность; специализированные решения — управленческая двойная запись с гибкой методологией. Беда начинается, когда инструмент выбирают по принципу «у нас уже есть ERP» или «УХ — это солидно», а требования формулируют постфактум.

Типовых возможностей не хватает не потому, что ERP или УХ «не умеют управленческий учет». А потому, что конкретная методология, аналитическая размерность, периодичность и архитектура данных могут не совпасть с моделью, заложенной в продукт. И лучше выяснить это до старта, чем через год, вложив миллионы в неподходящий продукт.

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