Описание одного из алгоритмов формирования консолидированной

Преимущества консолидации, основанной на оборотах, по
сравнению с решением, в котором консолидация базируется на
остатках и оборотах
Основное преимущество — более простое проектирование, внедрение и отладка решения для
консолидации. По моей оценке, трудоемкость настройки такого решения и его поддержания в
работоспособном виде в 3-4 раза меньше, чем решение, в котором консолидация базируется на
остатках и оборотах. Это преимущество обусловлено использованием менее сложных структур
данных.
При работе только с оборотами основные рабочие данные — это одна таблица, в которую в виде
проводок (Дт-Кт) заносятся как исходные данные, так и результаты расчетов консолидационных
корректировок. Соответственно, алгоритмы расчетов относительно простые, что позволяет их
легко прописать и отладить - за счет этого снижается вероятность появления ошибок как при
проектировании решения, так и при использовании системы. Также за счет отсутствия
дублирования исходной информации полностью исключается риск внутренних противоречий в
отчетности (нет необходимости в различных проверках).
Это же преимущество (более простая структура данных) работает и для процедур выгрузки
информации из учетных систем и загрузки в систему консолидации. Все данные — одна плоская
таблица, которую легко обрабатывать. Кроме этого, нет необходимости менять формат при
изменении справочников или при появлении потребности в большей детализации некоторых
операций.
Второстепенные преимущества:
 более строгое соответствие МСФО (например, возможен пересчет прибылей и убытков в
валюту отчетности по курсу на дату операции),
 прозрачность (аудируемость) всех расчетов и реклассификаций (нет необходимости во
«входящих проводках», аудируемость расчета курсовых разниц и т.д.),
 больше возможностей для построения управленческой отчетности - легко можно перейти
на более частую подготовку отчетов (по неделям), строить более детализированные отчеты
(по ЦФО, проектам и т.д.).
Описание одного из алгоритмов формирования консолидированной
отчетности на основе оборотов
Преобразование исходных данных к требованиям МСФО и системы консолидации
Алгоритм преобразования может существенно различаться для разных компаний группы и зависит
от степени соответствия учетной политики компании Учетной политике группы и от используемого
компанией программного обеспечения. Подготовка данных может включать:
 Реклассификацию активов, пассивов, статей прибылей и убытков.
 Выполнение начислений.
 Согласование справочников.
 Мэппинг операций с плана счетов учетной системы компании на план счетов системы
консолидации. Под планом счетов подразумеваются не только финансовые счета, но и
аналитики, используемые для построения консолидированной отчетности (например, для
сегментации).
Эти преобразования могут выполняться:
 в рамках учетных систем компании,
 при выполнении процедур выгрузки - загрузки данных,
 в системе консолидации после загрузки данных перед выполнением консолидационных
корректировок.
Пересчет в валюту отчетности
Каждая операция (проводка или агрегированные проводки за день) пересчитывается в валюту
отчетности по курсу на дату операции. Сальдо по каждой группировке «финансовый счет +
аналитика» по счетам активов и обязательств пересчитывается в валюту отчетности по курсу на
конец периода. Курсовые разницы относятся на счет в капитале.
Алгоритм простой и прозрачный, полностью исключены проблемы с курсами (нет необходимости
пересчитывать отчетность в случае резкого колебания курсов в течение отчетного периода).
После пересчета можно посмотреть оборотную ведомость по каждой компании до консолидации в
функциональной валюте и в валюте отчетности группы.
Корректировки при изменении эффективной доли владения
На дату приобретения/продажи доли компании рассчитывается и заносится в систему
консолидационная проводка.
Часть данных, необходимых для расчета (например справедливая стоимость), отсутствует в
системе, поэтому эта проводка рассчитывается и заносится в систему в ручном режиме.
В системе автоматически элиминируются все обороты до даты приобретения и рассчитываются
чистые активы на дату приобретения. Выполняется красное сторно всех операций, дата которых
меньше даты приобретения, и создается такая же проводка датой приобретения. После закрываем
на счет нераспределенной прибыли счета прибылей и убытков на дату приобретения — в
результате сальдо только на балансовых счетах.
На основе этих данных вне системы рассчитываем консолидационную проводку (инвестиции,
гудвилл, доля меньшинства, капитал) и заносим ее в систему.
Проводки по приобретению компании, выкупу доли меньшинства и прочих изменениях в
собственности рассчитываются и отражаются в системе один раз, в том периоде, когда менялась
эффективная доля владения - нет необходимости повторять их из периода в период.
В периодах, когда изменения эффективной доли владения не происходило, просто
рассчитываются курсовые разницы в рамках общей процедуры пересчета курсовых по активам и
обязательствам.
Выделение доли меньшинства в изменениях чистых активов
Для всех статей чистых активов дочерних компаний, у которых были движения за период,
формируется проводка датой конца периода с выделением доли меньшинства. Рассчитывается
сумма изменений и умножается на долю меньшинства (1 — эффективная доля владения).
Сверка взаиморасчетов и сворачивание внутригрупповых остатков и оборотов
Внутригрупповые операции не агрегируются. Для каждой внутригрупповой операции
(покупка/продажа или оплата) система консолидации находит соответствующую операцию у
компании - контрагента — по сумме в валюте операции, номеру документа, дате (если даты
совпадают по правилам учета). Если система не находит соответствующую операцию — выдает
сообщение об ошибке. Отпадает необходимость в «ручных» сверках компаний.
Для всех найденных внутригрупповых продаж и покупок:
• выполняется красное сторно проводок у покупателя и продавца;
• у продавца восстанавливается проводка Дт «Себестоимость» Кт «Товары» на сумму списанной
себестоимости, у покупателя создается проводка Дт «Товары» Кт «Себестоимость» на сумму
покупки (эта сумма больше на маржу продавца и может быть в другой валюте).
Для всех найденных платежей между компаниями:
• выполняется красное сторно проводок у отправителя и получателя;
• создается проводка Дт «Деньги» на сумму в функциональной валюте и валюте отчетности как у
получателя, Кт «Деньги» на сумму в функциональной валюте и валюте отчетности как у
отправителя и Дт или Кт «Курсовые разницы» в капитале на сумму разницы сумм в валюте
отчетности.
Элиминация нереализованной прибыли
Рассчитывается внешним алгоритмом, и на конец периода
«Себестоимость» Кт «Товары», а на дату начала следующего
«Себестоимость» (реверс).
Для простых случаев сумму нереализованной прибыли можно
консолидации. Простой случай – продажа товаров между двумя
выполняется проводка Дт
периода Дт «Товары» Кт
считать прямо в системе
компаниями группы без их
использования в производстве. Система рассчитывает остатки товаров на конец периода в разрезе
товаров и компаний. Для каждого ненулевого остатка по фифо восстанавливает приходы, которые
сформировали остаток на конец периода. Из этих приходов выбирает покупки у компаний группы и
рассчитывает нереализованную прибыль.
Пересчет в валюту отчетности после всех корректировок
В результате сворачивания внутригрупповых остатков и оборотов и элиминации нереализованной
прибыли остатки на конец периода в валюте отчетности могут быть не совсем корректными. Чтобы
исправить эту ситуацию, еще раз выполняем расчет курсовых разниц.
Формирование основных форм отчетности и раскрытий
Данные для построения консолидированной отчетности формируются с помощью алгоритмов,
аналогичных используемым в учетных системах для построения отчетов. Таблица рабочих данных
соответствует таблицам с проводками, используемыми в модуле GL распространенных ERP
систем. Никаких дополнительных пересчетов и проверок при этом выполнять не надо.
Типичные заблуждения
Автоматическая выгрузка данных из учетных систем — это сложно, дорого и не очень
надежно — проще, дешевле и надежнее заполнять пакеты вручную.
Чаще всего, когда начинают автоматизировать процедуры подготовки консолидированной
отчетности (в том числе выгрузку данных из учетных систем), уже есть отдел, который занимается
МСФО отчетностью и есть в большей или меньшей степени формализованные процедуры. В том
числе есть формат пакета сбора данных с активов. Практически всегда пакет сбора данных - это
Excel файл, формат которого рассчитан на ручную обработку (заполнение). Разумеется, часть
данных может заноситься в пакет копированием из отчетов учетных систем, но основная часть
заполняется вручную.
И именно формат пакета и приводит к сложностям. То есть утверждение: «Автоматическая
выгрузка данных из учетных систем в пакеты, ориентированные на ручную обработку — это
сложно, дорого и не очень надежно — проще, дешевле и надежнее заполнять пакеты вручную»
является абсолютно верным. Но так как специалисты, занимающиеся подготовкой отчетности, не
являются специалистами в ИТ и не разбираются в тонкостях технологий, происходит подмена
понятий — проблемы, связанные с выгрузкой в определенные форматы, переносятся на все
процедуры автоматической выгрузки.
Выгрузка только оборотов может привести к ошибкам, когда часть операций не выгрузится,
и это останется незамеченным.
Подобные ошибки возможны только в двух случаях:

Если алгоритмы выгрузки данных ориентированы не на ключевые финансовые данные
(проводки), а на документы, формирующие проводки. В таком случае всегда есть
вероятность, что в учетной системе будет учтен документ, который не будет предусмотрен
алгоритмом выгрузки, и, соответственно, не будет выгружен.

Если алгоритмы выгрузки нацелены на выгрузку данных по определенным признакам.
Например, из движений по расчетному счету сперва выгружаются все оплаты от
покупателей, потом платежи поставщикам, потом выплата зарплаты и т.д. Если при
разработке алгоритма забыли об определенном типе операций (например, оплата за
интернет) или процедура выгрузки не смогла классифицировать некоторую операцию
(например, есть оплата, но нельзя определить, к какому типу относится), то такие операции
действительно могут быть пропущены.
Все эти ошибки обычно свидетельствуют о неправильном проектировании алгоритмов выгрузки, и
могут быть исключены на этапе проектирования.
Разумеется, существуют некоторые ситуации, когда нельзя полностью исключить возможность
появления ошибок. Например, при использовании в качестве источника данных систем без
двойной записи (широко используемая конфигурация «Управление Торговлей» 1С не содержит в
себе бухгалтерского модуля - проводок и двойной записи). Но в любом случае использование
подобного рода систем для составления консолидированной МСФО отчетности несет в себе
большие риски, даже без учета ошибок выгрузки данных.
Чем выше уровень агрегирования, тем меньше данных надо хранить и обрабатывать
системе консолидации, соответственно, тем дешевле обойдется решение (менее
мощный сервер, меньше места на дисках).
Предположим, есть холдинг из 100 компаний. Каждая компания в день генерирует 100'000
проводок. Итого в день 10'000'000 проводок. 365 дней в году — 3'650'000'000 проводок (три с
половиной миллиарда). За 5 лет — 18 миллиардов проводок. Каждая проводка занимает примерно
1 килобайт памяти. Итого за 5 лет — 18 террабайт данных. Это база данных среднего размера.
Особенности использования этих данных таковы, что для их хранения прекрасно подойдут
относительно недорогие SATA диски для основного массива данных и небольшие по размеру SSD
диски для агрегированных данных. Сервер баз данных с дисковым массивом необходимой емкости
и достаточной для обработки таких объемов данных производительностью стоит примерно 10'000
– 15'000 долларов США (лето 2013).
Если ориентироваться на обработку только агрегированных данных, можно выбрать сервер за
4'000 – 8'000 долларов США (лето 2013), то есть экономия составит максимум 7'000 долларов
США.
На практике разница будет намного меньше или ее не будет вообще, ведь при желании можно не
хранить в основной базе данных детальные данные, а удалять их сразу после обработки в архив. К
тому же надо учитывать, что у подавляющего большинства компаний количество операций (и
объемы данных) в несколько раз меньше, поэтому экономить на объеме обрабатываемых данных
(за счет агрегирования) не получится.
А вот издержки от работы с агрегированными данными возрастут. Написание процедур выгрузки,
которые сразу агрегируют данные, несколько сложнее и, соответственно, дороже. Но главная
проблема агрегированных данных — сложность отладки. Например, при ошибке мэппинга
возможность сразу увидеть, на каком именно документе (проводке) алгоритм дал сбой, позволяет в
несколько раз ускорить поиск ошибок в учетных данных или алгоритмах выгрузки.
Таким образом, учитывая, что обычно стоимость работ в несколько раз превышает стоимость
оборудования, намного дешевле сразу ориентироваться на работу с максимально
детализированными данными.
Пример
Рассмотрим условный пример - как будет осуществляться консолидация с предлагаемым
подходом.
Есть следующие компании:
A — функциональная валюта евро (Нидерланды), валюта отчетности доллар США, курсы Форекс
B — функциональная валюта рубли (Россия), курсы ЦБ РФ
C — функциональная валюта гривна (Украина), курсы НБУ
На 31.12.2012:
А — 1'000'000 евро на счете в банке
В — 100'000 рублей на счете в банке и товар item01 в количестве 100 штук на сумму 500'000
рублей
С — 400'000 гривен на счете в банке
Январь
А
16.01 компания А купила 80% В за 400'000 евро (тут же заплатила)
25.01 компания А купила 70% С за 400'000 евро (тут же заплатила)
В
14.01 продала покупателю C0301 товар item01 в количестве 30 штук на сумму 250'000 рублей
(деньги поступили на р/с в тот же день)
15.01 купила у поставщика V015 товар item02 в количестве 50 штук на сумму 100'000 рублей
(деньги ушли с р/с в тот же день)
22.01 продала покупателю C0200 товар item01 в количестве 60 штук на сумму 700'000 рублей и
item02 в количестве 40 штук на сумму 180'000 рублей (деньги до конца месяца не поступили)
С
15.01 оказала услуг покупателю C0100 на сумму 80'000 гривен (деньги до конца месяца не
поступили)
Февраль
В
13.02 продала покупателю С0002 (под этим номером записана компания С) товар item01 в
количестве 10 штук на сумму 5'000 евро и item02 в количестве 10 штук на сумму 2'000 евро (деньги
до конца месяца не поступили). Курс ЦБ РФ 40,3873
28.02 Курс Евро 40,0420 (ЦБ РФ)
С
13.02 купила у поставщика V001 (под этим номером записана компания В) товар item01 в
количестве 10 штук на сумму 5'000 евро и item02 в количестве 10 штук на сумму 2'000 евро
(деньги до конца месяца не перечислены). Курс НБУ 10,740993
28.02 Курс Евро 10,468432 (НБУ)
Март
В
12.03 получила от покупателя C0200 880'000 рублей на р/с (за продажу в январе)
28.03 получила от С0002 (под этим номером записана компания С) 7'000 евро на р/с (за продажу в
феврале) Курс Евро 39,6559 (ЦБ РФ)
31.03 Курс Евро 39,8023 (ЦБ РФ)
С
14.03 получила от C0100 80'000 гривен на р/с (за продажу в январе)
20.03 продала покупателю С0150 товар item01 в количестве 10 штук на сумму 80'000 гривен и
item02 в количестве 10 штук на сумму 30'000 гривен
26.03 получила от покупателя С0150 110'000 гривен на р/с
28.03 купила на межбанке 7'000 евро за 73'010 гривен (курс 10,43) и перечислила их поставщику
V001 (под этим номером записана компания В) Курс Евро 10,205462 (НБУ)
Выбор уровня детализации данных для консолидации
При разработке форматов выгрузки/загрузки данных практически всегда возникает вопрос — какая
степень детализации исходных данных оптимальна?
Существует множество вариантов, начиная от максимальной детализации (детализация до
отдельных проводок) до максимального агрегирования данных (детализация до оборота по счету и
аналитикам за период в целом) и множества промежуточных вариантов (например, обороты за
день).
На практике, для решения этого вопроса, можно воспользоваться простым правилом:
 если предполагается автоматическая выгрузка/загрузка данных — выбираем
максимальную детализацию (до проводок) — это наиболее простое и дешевое решение;
 если предполагается ручное заполнение пакета данных — по умолчанию выбираем
минимальный уровень детализации (обороты за период в целом), и при необходимости
повышаем степень детализации для отдельных типов операций, для которых это
необходимо (например, внутригрупповые обороты).
При этом можно обрабатывать в одной системе консолидации данные с разной степенью
детализации. Например, часть компаний группы автоматически выгружает данные с детализацией
до проводок, а часть заполняет пакет вручную и заносит обороты за период в целом.