Как составить техзадание по консолидации

Консолидация финансовой отчетности Группы компаний по МСФО – сложная организационная, методологическая и техническая задача. Сжатые сроки и возможные уточнения исходных данных в ходе подготовки отчетности только усложняют процесс.

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

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

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

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

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

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

Получается, что опытные специалисты с высокой квалификацией (ACCA, DipIFR и т.д.) большую часть времени вынуждены раз за разом выполнять (к сожалению, с ошибками!) рутинные, хорошо алгоритмизируемые операции. Вместо того чтобы заниматься сложными, но штучными нюансами МСФО и анализом полученных результатов. Естественным образом встает вопрос об использовании специализированной промышленной системы.

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

• сбор данных (возможен полностью автоматически, если настроена интеграция с учетными системами);
• трансляция, в том числе в нескольких презентационных валютах;
• расчет и повтор различных трансформационных и консолидационных корректировок;
• формирование отчетов о сверке внутригрупповых оборотов;
• элиминация внутригрупповых оборотов;
• консолидация по различным периметрам/сегментам;
• формирование регламентированных отчетных форм и т.д.

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

Вместе с тем предусмотреть заранее все необходимые функции невозможно. В реальной жизни изменения происходят постоянно. Появляются новые операции, расчеты, отчетные статьи и корректировки, меняется структура Группы и отдельные МСФО. 

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

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

Наш опыт внедрения различных решений для консолидации показывает, что правильно построенная система консолидации – гибкая. Настройка системы консолидации в промышленных системах автоматизации (например, в Oracle Hyperion Financial Management или SAP Business Planning and Consolidation) имеет особенности, но обычно такие продукты позволяют получить гибкую, масштабируемую систему, которую можно поддерживать силами функциональных специалистов.

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

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

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

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

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

Конечно, не каждый расчет можно легко менять или добавлять в систему (это не всегда просто и в Excel), однако отдельные расчеты обязаны быть гибкими.

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

Новые отчеты требуются, как правило, для ответа на оперативные запросы бизнеса (например, анализ влияния корректировок на EBITDA). Такие быстрые, аналитические отчеты функциональные специалисты должны создавать на лету. Мы считаем такое требование обязательным. Без возможности создания аналитических форм система может использоваться для получения книжки отчетности по МСФО, но не станет инструментом для анализа данных.

Стандартные, фиксированные отчетные формы также должны иметь возможность меняться. Чаще всего требуется добавить новые элементы в справочники системы, и это должно происходить автоматически (хотя в некоторых случаях, например при добавлении новых статей, ручная корректировка допустима).

Модель данных системы консолидации определяется набором всех справочников (измерений) и их значений. В дополнение к набору обязательных измерений (например, Account, Entity и Period) решения для консолидации позволяют включать в модель данных необходимое количество дополнительных пользовательских измерений (например, возраст задолженности или валюту контракта).

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

Прямолинейный подход – включить соответствующие пункты в справочник Account (Счет/Статья), а именно: завести значение на начало периода, добавить статьи требуемых видов движений (например, поступление, выбытие, списание, обесценение и т.п.), завести значение на конец. Такое решение позволит построить требуемое примечание для конкретной статьи счета. Если потребуется сделать расшифровку для другой статьи, то придется добавлять новые элементы Account (рис. 1). Если выделить движения по счету в отдельный справочник, то этот справочник можно использовать для построения любого примечания по движениям в связи с тем, что варианты движений по счетам в большинстве случаев одинаковы (вероятнее всего, нужные значения движений по счету уже будут созданы для других счетов и можно будет их использовать). Кроме того, пользователи смогут анализировать счета по видам движений, определенные движения по разным счетам (см. рис. 2).

РИСУНОК 1. ДОБАВЛЕНИЕ РАСШИФРОВОК К СТАТЬЯМ

РИСУНОК 2. ВИДЫ ДВИЖЕНИЙ ПО РАЗНЫМ СЧЕТАМ

Если в системе настроена процедура переноса начального сальдо из прошлого периода (а она должна быть настроена), то выделение движения по счету в отдельный справочник существенно упростит настройку такой процедуры и сделает ее универсальной. Какие бы изменения ни произошли в модели, правило переноса значения «На конец периода» предыдущего периода на «На начало периода» текущего от этого не изменится.

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

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

Это расчеты:

• с использованием иерархий;
• динамические расчеты с использованием формул элементов;
• стандартные расчеты «из коробки»;
• готовые бизнес-правила, настраиваемые с помощью специальных таблиц;
• локальные расчеты в отчетных формах и т.п.

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

Но на практике не получается обойтись без ручного написания кода процедур расчета на внутреннем языке системы. Например, в системе Oracle Hyperion Financial Management таким языком является Visual Basic Script, в SAP Business Planning and Consolidation – внутренний язык script logic или процедуры на ABAP для особо сложных ситуаций. Изменения в этих процедурах вызывают наибольшие трудности по поддержке системы. И если не ставить задачу построить гибкие, настраиваемые расчеты, то поддержка изменений в промышленной эксплуатации может стать большой проблемой.

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

РИСУНОК 3. ДВА ВАРИАНТА РАСЧЕТА ПО СВОРАЧИВАНИЮ ОТЛОЖЕННЫХ НАЛОГОВ В EXCEL

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

Вариант расчета ниже для определения парного счета (обязательства для актива и наоборот) использует столбец В, сама формула расчета не содержит прямой ссылки на другой счет, она одинаковая для всех счетов активов или обязательств. Добавление новой группы отложенного налога не требует исправления в формулах – нужно просто добавить новые счета (строчки в Excel) и указать парные счета в атрибутах (столбец В).

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

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

Материал опубликован на портале «МСФО на практике», июль 2016 г.