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

Это в значительной степени и абсолютно легально оптимизирует налоговые отчисления. Юридическое лицо не может быть центром управленческого учета, поскольку никак не отражает и не охватывает все то, что действительно касается бизнеса. А вот построить безопасную схему владения активами на юрлицах можно.

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

В данном кейсе мы столкнулись с больше сотни бухгалтерских баз на разных версиях 1С и даже с разными планами счетов (часть велась на плане счетов в соответствии с МСФО).

Задача была простой – ежемесячная консолидированная отчетность с возможность глубокого анализа деталей. Таким образом консолидировать необходимо было на уровне первичных операций, что и происходит в системе ТМА.

Поскольку на входе бухгалтерские базы, то для интеграции и интерпретации данных был взят модуль ACCCell (тогда мы его еще называли АСБУ).

Загрузка данных велась исключительно через файлы. Такой вариант не всегда удобный и не обеспечивает режим реального времени в отражаемых отчетов, но зато обеспечивает безопасность самым простым способом. А, как вы понимаете, когда идет речь о данных, которые становятся консолидированными и прозрачными, то безопасность стоит не на последнем месте.

Мы взяли данные за все последние 10 лет. Таким образом устанавливая систему управленческой отчетности, может проводиться довольно глубокий управленческий аудит и анализ успешности и состояния в целом холдинга и каждого подразделения в отдельности.

Большинство баз велось с квартальным закрытием, поэтому условия ежемесячной отчетности выполнить было невозможно. Пока бухгалтерия не закроет период, данные в системе некорректные. Ведь это не ТМА.

Чтобы выполнить условие собственника, пришлось переводить все бухгалтерии на помесячное закрытие, хотя по законодательству они могли закрываться раз в квартал. Так бухгалтерский учет стал немного подтягиваться к требованиям управленческого учета.

Эффект имел значительно больший результат. Поскольку период между процедурами закрытия периода уменьшился втрое, то и влияние фактора «студенческий синдром» в значительной степени уменьшилось. Они стали лучше отрабатывать по ходу учетного периода, поэтому времени на закрытие стало уходить настолько мало, что мы получали в систему ТМА данные уже через день после окончания календарного месяца.

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

С чем возникли сложности

В бухгалтерии крайне неаккуратно ведут учет аналитических признаков. Даже самое простое. Статьи движения денежных средств по 51 счету должны быть на втором субконто. Но для отчетности перед государством это не имеет никакого значения.

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

Бухгалтеры с молоком матери впитали правило жить по правилам, поэтому если эти правила будут жесткими и адекватными, то они будут выполнять их наравне с РСБУ. Но и этот процесс непростой. Создать правила и заставить всех их выполнять, подразумевает еще и достаточно жесткий контроль их выполнения.

В противном случае результата действительно качественного не будет.

Для выполнения задачи нам пришлось наполнять систему ТМА сверхгибкими инструментами. При настройке правил интерпретации исходных данных бухгалтерских проводок в управленческую бухгалтерию мы можем цепляться за мельчайшие признаки или набор признаков.

Пример крайне неаккуратного учета наименований договоров

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

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

Еще одна общепринятая боль — полный бардак в справочниках

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

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

Мы сделали такой инструмент на уровне ТМА.

Если в любом из справочников мы находим дубли, то достаточно кликнуть правой кнопкой мыши и выбрать команду «Совместить».

Как работает функция «совместить»

Таким образом, не трогая исходных баз и принципов, на уровне уже аналитической системы ТМА Управленческая бухгалтерия наводится порядок во всех аналитических справочниках. В случае аудита больших прошлых периодов, без этой работы никак не обойтись.

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

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

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