25 компаний, 9 стран, 6 функциональных валют… Систему и процедуры подготовки отчетности легко можно было сделать сложными и дорогими. Но мы нашли простое с технической точки зрения решение, которое очень нравится нашим пользователям, а особенно специалистам по подготовке консолидированной финансовой отчетности по международным стандартам (далее по тексту — МСФО) и управленческой отчетности.

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

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

Что надо получить «на выходе»

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

Например, вот основные отчеты Google:

INCOME STATEMENT (часть отчета):

BALANCE SHEET  (часть отчета):

В целом, в этих отчетах нет ничего сложного — остатки на даты и / или обороты за периоды в разных разрезах по данным бухгалтерского учета и показатели, рассчитанные на их основе.

Кроме консолидированной финансовой отчетности по МСФО, мы формируем управленческие отчеты для руководителей.

Что такое управленческая отчетность? Это детализация отдельных показателей финансовой отчетности. Например, мы видим в МСФО отчетности, что сумма продаж за год составила 100 миллионов. У компании есть несколько разных направлений деятельности, и общая цифра продаж нам не скажет, какие из этих направлений хорошо развиваются, а какие плохо. Для принятия управленческих решений (например, какое из направлений закрыть, а в какое инвестировать дополнительные деньги, или кому сколько премии выплатить) и нужна управленческая, то есть детализированная отчетность. 

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

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

Мы готовим также локальную и налоговую отчетность. Она составляетя для каждой компании отдельно и не консолидируется.

Требования к отчетности, которые мы старались реализовать

• Согласованность и сопоставимость (сверяемость) показателей во всех отчетах. Цифры в разных отчетах должны совпадать между собой, а в тех случаях, когда они отличаются, должна быть возможность легко посмотреть, за счет чего. Не должно быть необъяснимых расхождений.
• Прозрачность и аудируемость цифр в отчетности — должна быть возможность просмотреть по каждой цифре детализацию до уровня операции — с номером, датой учета и прочими реквизитами, по которым легко найти операцию в учетной системе.
• У пользователей должна быть возможность самостоятельно, без привлечения ИТ специалистов, исправлять ошибки.
• Быстрое обновление цифр — после внесения новых данных компаниями группы обновленные консолидированные отчеты должны быть доступны в течении минут (не часов / дней).

Почему именно эти требования очень важны?

Согласованность данных и прозрачность (аудируемость) каждого показателя:  представьте, что в одном отчете вы видите сумму совокупных продаж 100 миллионов, а в расшифровке по странам общая сумма продаж — 146 миллионов… И никто не может вам внятно объяснить, почему такие разницы между отчетами. Или, например, невозможно расшифровать сумму продаж до уровня отдельных документов (с датами, номерами, суммами, клиентами), которые можно относительно легко проверить.

И в том, и в другом случае доверие к отчетам снижается. У руководства компании присутствует постоянный дискомфорт от того, что нет надежных данных, а у внешних пользователей отчетов (инвесторов, банков и т.д.) — подозрение, что для них «нарисовали отчетность» («cooking the books» / «window dressing»).

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

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

Выбор программ для автоматизации отчетности

Для финансового учета мы используем ERP Microsoft Dynamics NAV (далее по тексту — NAV), и в этой статье мы описываем его возможности. Большинство других популярных современных ERP систем достаточно похожи на NAV.

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

Когда проводок мало (не более нескольких десятков тысяч), можно все финансовые проводки скопировать из NAV в Excel, и сформировать отчетность с помощью Pivot Table. Если отчеты готовит один человек — очень неплохое решение.

Если данных больше, но с отчетами все еще работает один человек — можно расчеты делать с помощью Power Pivot, который является дополнением для Excel.

В нашем случае количество данных не очень большое, но может вырасти в будущем, и с данными должны работать несколько десятков человек. Необходимо более серьезное решение.

Mы рассматривали два варианта — LucaNet и Microsoft Analysis Services (часть Microsoft SQL Server).

Так как Analysis Services уже был в наличии (NAV работает с Microsoft SQL Server), мы выбрали его. Долгое сравнение не делали — просмотрели возможности LucaNet и не нашли ни одной нужной нам уникальной функции. Дополнительными аргументами являлось то, что Analysis Services — более универсальное решение, на рынке имеется огромное количество специалистов (намного больше, чем специалистов по LucaNet), и у нас есть опыт работы с ним.  

Analysis Services умеет работать в двух режимах — Tabular и Multidimensional. Так как у команды внедрения был опыт работы с Multidimensional, мы выбрали этот режим. 

В результате, основная часть нашей отчетности формируется с помощью OLAP куба, с которым пользователи работают с помощью Excel. Для пользователей это выглядит как работа с Pivot Table, что для них не представляет сложности.

Также мы используем различные отчеты, формируемые с помощью Reporting Services — еще одной составной части Microsoft SQL Server.

Подготовка данных для отчетности

Первичный учет и МСФО корректировки

Все компании группы из всех стран ведут учет в одной базе с интернациональной версией NAV (W1) без локализаций.

Справочники (списки поставщиков, покупателей, видов затрат и т.д.) централизованы и синхронизируются с помощью отдельного модуля Master Data Management, разработанного нашим подрядчиком.

Все данные в системе сохраняются в одинаковом формате (в виде финансовых проводок) и система автоматически контролирует, что проводки сбалансированы (дебет равен кредиту).

Основной план счетов системы — корпоративный (МСФО). Локальные счета — это отдельное измерение, которое присваивается каждой строке финансовой проводки. В большинстве случаев локальные счета настроены по умолчанию — привязаны к карточкам поставщиков, покупателей, товаров и т.д. В случаях, если локальный учет требует большей детализации, пользователи должны выбирать локальные счета вручную. 

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

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

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

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

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

Кроме счетов, для разделения между МСФО и локальным учетом мы используем измерение «тип проводки» с двумя возможными значениями — GENERAL и IFRS.

Если в локальном учете операция не нужна, а в МСФО нужна, она постится с забалансовым локальным счетом и типом проводки «IFRS».

Если в МСФО учете эта операция не нужна, а в локальном учете нужна, то к ней постится дополнительная отменяющая проводка — тоже с забалансовым локальным счетом и типом проводки «IFRS».

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

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

Это позволит нам отказаться от использования измерения «тип проводки» при первичном учете. В кубе это измерение останется, но будет присваиваться операциям не на основе измерения NAV. 

В таком случае в «основной» компании останется только локальный и налоговый учет.

Перевод из функциональных валют в валюту отчетности

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

В NAV в таблице финансовых проводок есть отдельные поля для сумм в дополнительной валюте отчетности (это стандартный функционал системы). Например, основная валюта отчетности для компании в США — USD, и все суммы в финансовых проводках в USD, а дополнительная валюта отчетности — EUR, и все суммы в дополнительных полях в EUR.

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

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

Консолидационные корректировки

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

Формирование отчетности

Общая схема обработки финансовой информации:

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

NAV сохраняет информацию о финансовых операциях (финансовые проводки с дополнительными аналитиками) в виде записей в таблицах базы данных.

Данные из таблиц NAV считываются, преобразовываются в вид, удобный для расчета куба и сохраняются в мини DWH (Data WareHouse — Хранилище Данных). Так как в этом хранилище сохраняются только финансовые проводки и связанная информация, называть его полноценным хранилищем неправильно.

Далее на основе этих данных рассчитывается OLAP куб.

В дальнейшем пользователи с помощью Excel подключаются к кубу и формируют все необходимые им отчеты.

Мы пробовали работать с кубом с использованием Tableau (используется в других подразделениях нашей компании), но пользователям не очень понравилось. Excel для финансистов привычнее.

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

Это осознанное решение, принятое по двум причинам:

• У бухгалтеров повышается ответственность за качество данных. Они не надеются, что кто-то вместо них исправит ошибки.
• Составление отчетности, проверка качества учета и корректировка ошибок — эти задачи выполняют обычные пользователи, а не ИТ специалисты, и у них должна быть возможность выполнять эту задачу. Если правила «очистки» будут спрятаны внутри ПО — пользователи не смогут самостоятельно находить и исправлять ошибки. 

Изначально мы думали, что для консолидации будет удобно собирать все финансовые проводки в одной компании и пользоваться стандартными отчетами NAV для формирования консолидированной отчетности. Мы создали отдельную компанию в NAV и настроили копирование туда проводок из всех компаний. На практике это оказалось неудобным, и мы отказались от такого варианта. Обобщенные данные из всех компаний прекрасно выводит наш куб. В нем же можно просмотреть детальные данные (финансовые проводки).

Пересчет куба выполняется автоматически каждую ночь. Но при необходимости мы можем вручную запустить пересчет куба со свежими (только что внесенными в NAV) данными. Пересчет куба занимает 10 — 15 минут.

Для тех, кому интересны технические детали:

Заключение

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

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

Надеемся, эта статья поможет вам эффективно решать задачи автоматизации отчетности.

Еще раз повторим ключевые особенности нашего подхода:

• Все виды учета, а также все корректировки, осуществляем в учетной системе в одном “регистре” (в главной книге). Не дублируем данные для учета по локальным стандартам, управленческого, налогового и МСФО учета.
• Во всех компаниях группы работаем с общими (одинаковыми) версиями справочников, имеющими отношение к финансовому учету (план счетов, аналитики, покупатели, поставщики и т.д.).
• Обеспечиваем “чистоту” (корректность) данных на уровне учетной системы, а не при загрузке в систему отчетности.
• Формируем консолидированную отчетность только на основе данных из учетной системы. Исходные данные для отчетности — финансовые проводки с дополнительными аналитическими признаками (измерениями). Не используем различные файлы Excel как источники данных.
• Не агрегируем данные при загрузке в систему подготовки отчетности. Каждая финансовая проводка (с уникальным идентификатором) представлена в отчетной системе как отдельная запись.

Сергей Устинов
Дарья Фадеева, FCCA

P.S. При подготовке статьи использовалось фото с сайта www.pexels.com.