XBRL: Просто о сложном − Глава 1. Введение

http://www.batavia-xbrl.com/downloads/XBRLinPlainEnglishv1.3.pdf
  • Перевод

Комментарий от переводчика


В 2015 году Центральный Банк РФ запустил проект перехода некредитных финансовых организаций (НФО) на электронный формат представления отчетных данных в формате XBRL с 01.01.2018. Сроки уже подходят, а НФО только начинают осознавать масштабы грядущих изменений. Качественных материалов про XBRL на русском языке достаточно мало (могу разве что рекомендовать книгу XBRL для чайников, перевод которой был инициирован ЦБ, правда выполнен не в лучшем виде). Хочу восполнить этот пробел и предлагаю вашему вниманию свою адаптацию неплохой брошюры XBRL in Plain English от компании Batavia, которая рассказывает об основах XBRL.


Перевод веду от лица автора, немного дополняю текст полезными ссылками. Стараюсь придерживаться терминологии ЦБ РФ со ссылкой на оригинальные термины. Начну с первых глав, и если тема будет вам интересна, завершу перевод. Комментируйте, задавайте вопросы − расскажу все, что знаю.


Роман Удальцов




1. Введение


В этой главе представлена сама книга и основные понятия XBRL


1.1. Что ожидать


Если вы начали читать эту книгу, значит вы уже слышали о новом способе формирования бизнес-отчетности − XBRL. Если вы взглянули на спецификацию XBRL, то знаете, что она представляет собой 158-страничный документ, полный формальных определений. Такой документ нужен для корректного определения XBRL. Его можно считать расслабляющим чтивом на ночь для математиков. Но не для нас, нормальных людей.


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


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


Такими блоками будет обозначаться более глубокое погружение в детали (где это действительно необходимо)

Я также не буду дискутировать на тему таких базовых технических стандартов как XML, XML Schema, XLink, XPath, XPointer и т.д. Если вам не очень знакомы эти технологии, загляните на сайт W3C (World Wide Web Consortium) за списком рекомендованной литературы или в любую хорошую книжку по XML.


Эта книга основывается на спецификации XBRL 2.1 от 20.02.2013 с исправлениями от 25.04.2005. Если вдруг встретятся расхождения между книгой и официальной спецификацией, скромность требует от меня предположить, что это я ошибся, а авторы спецификации сделали все правильно. Я бы рекомендовал вам сделать аналогичное предположение.


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

1.2. Представляю вам XBRL


XRBL расшифровывается как Extensible Business Reporting Language (расширяемый язык деловой отчетности), что само по себе неплохо описывает суть: это язык отчетности, используемый в бизнесе. И он расширяемый. Все просто, да? Ну, может быть, потребуется немного больше объяснений.


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


Давайте прыгнем сразу в середину:… Business Reporting ...


1.2.1. Business Reporting (Деловая отчетность)


Мы все знаем, что бизнес формирует кучу отчетности:


  • налоговые декларации
  • ежегодные отчеты
  • внутренние показатели продаж
  • ...

Каждый отчет − это данные, представляющие собой набор фактов про содержимое отчета, таких как:


  • отчетный период
  • годовой доход
  • количество клиентов
  • количество продаж
  • инвентарные номера
  • ...

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


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


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


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


Стандарт XBRL также использует подобное разделение:


  • Определение того, что должно или может содержаться в отчете, описывается так называемой таксономией (taxonomy) − она определяет концепты (concept) в сфере бизнеса, по которым формируется отчетность.
  • Сами отчетные данные называются отчетом XBRL (instance document). Он содержит передаваемые получателю факты. Отчет ссылается на таксономию для придания фактам смысла. Каждый из фактов в пределах отчета связан с соответствующим концептом в таксономии.

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

Форма отчета выглядит следующим образом:

image

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

Пример заполненного отчета может выглядеть следующим образом:

image

Несложно заметить, что количество сотрудников увеличилось, но в компании работает как минимум один человек с недостатком математических навыков. В таком простом примере вряд ли кто-то посчитает 27 + 15 как 41, но в более сложных отчетах такие ошибки весьма вероятны, если все делается вручную.

1.2.2. Extensible (Расширяемый)


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


Предположим, что Европейский Союз определяет требования к отчетности для любого бизнеса в рамках ЕС.


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

XBRL позволяет поддерживать такие требования. ЕС создаст одну таксономию для определения требований к отчетности. Перевод технических концептов в таксономии на понятные пользователю термины содержится в так называемой базе ярлыков (label linkbase). Каждый язык внутри ЕС может иметь свою собственную базу ярлыков или можно создать одну общую базу, содержащую ярлыки для каждого языка. Обратите внимание, что при этом фактическое определение концептов не требуется повторять для каждого языка.


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


1.2.3. Language (Язык)


«L» в XBRL обозначает Язык. Язык XBRL обеспечивает способ выражения таксономий и отчетов XBRL в едином однозначном формате, что является необходимым требованием для обработки информации компьютером.


Язык XBRL основан на таких мировых стандартах как XML и соответствующих им спецификациях. В следующих главах об этом будет рассказано более подробно.





Поделиться публикацией
Комментарии 17
    0
    Вот именно что Extensible — теперь контролирующие органы смогут менять формат отчётности так часто, как захотят. тем самым «кошмаря» мелкий и средний бизнес.
      0
      Если я правильно понял, то как раз наоборот — это поможет избавиться от избыточности отчётных данных. Например, вместо нескольких отчетов (например, в ФНС, Росстат, etc) владельцы бизнеса должны будут предоставить 1 отчёт, из которого соответствующие структуры сами будут извлекать необходимые для них данные. Поправьте, если я неправильно понял
        0
        Совершенно верно, раньше отчеты собирались разными ведомствами и, что важно, в виде фиксированных отчетных форм.

        Теперь же участники финансового рынка будут передавать в ЦБ лишь полный набор фактов, из которых ЦБ на своей стороне соберет любую из отчетных форм (порядок визуализации отчетных данных в виде форм заложен в таксономию с помощью presentation linkbase, об этом будет рассказываться в следующих главах).
        0
        XBRL – это лишь стандарт.

        ЦБ, являясь регулятором финансового рынка РФ, в соответствии со стандартом XBRL разрабатывает Таксономию.

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

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

        Кошмарить будут не только мелкий и средний бизнес, а всех участников некредитного (а позже видимо и кредитного) финансового рынка, включая крупнейшие банки, страховые, НПФ и т.д. – но не чаще, чем дважды в год. Регламент внесения изменений в таксономию обозначен, к примеру, на слайде 12 этой презентации.
        0
        Не нужно пугать людей раньше времени. С 01.01.2018 ничего не будет. Все перенесли на «после 2018 г.» т.е. года полтора еще точно есть.
          0
          Поделитесь, откуда информация про после 2018?

          Возможно, у вас есть более достоверный источник информации, чем ЦБ РФ, но на последней встрече в ЦБ, как и на всех предыдущих встречах, моментом перехода страховых, НПФ, ПУРЦБ, инвестиционных фондов на предоставление отчетности в формате XBRL обозначалась дата 01.01.2018.

          Самые свежие материалы на сайте проекта – Презентация с заседания рабочей группы от 11.07.2017 (чуть более недели назад). План проекта вы можете найти на слайде 3, на нем отчетливо видна Подготовка отчетности в формате XBRL с начала 2018 года. В первых числах августа будет опубликован нормативный акт, регулирующий все вопросы подготовки отчетности в формате XBRL. Уверяю вас, в нем будут указаны те же самые сроки.

          Срок перехода на XBRL с 01.01.2019 установлен только для несущественной части НФО, включающей в себя страховых брокеров, спецдепы, микрофинансовые организации, ломбарды и т.д., подробнее см. слайд 11 здесь.
            0
            Прошу прощения, скорее всего, вы правы (если ЦБ в последний момент опять все не перенесет). Я как сотрудник кредитной организации (банка) со своей колокольни смотрю :) Для банков отчетность XBRL будет после 2018 года.
              0
              Всё так, кредитные финансовые организации будут переводить на XBRL после НФО, не ранее 2019 года, а может и позже. Я как сотрудник страховой компании немного завидую вам в этом плане :)
                0
                Ну, нужно же ЦБ на ком-то «потренироваться» :) За НФО сказать не могу т.к. имею только базовые представления о текущем положении дел с ПО в данных организациях. Учитывая, что в данном случае речь идет о целом ряде организаций, деятельность которых сильно различается, подозреваю, что и в сфере применяемого ПО «зоопарк» тот еще.

                Для банков переход на XBRL будет более простым, просто по причине достаточно ограниченного количества АБС (Автоматизированная Банковская Система) на Российском рынке.

                Конечно, в первую очередь «под раздачу» попадут те банки, которые используют «самописные» АБС (in-house разработки) и гибридные решения типа back office «из коробки» + «самописная» АБС, ну или экзотические зарубежные варианты типа Olympic. Однако, иметь в России собственную in-house development АБС могут позволить себе только очень крупные кредитные организации, а у них, как правило, есть большой локальный штат собственных разработчиков, так что большой проблемой для них это не будет.
                Остальная (большая) часть банков имеет АБС «из коробки» (Diasoft, ЦФТ, Афина и пр. список очень короткий). Тут все намного проще т.к. и поддержку XBRL они получат «из коробки» просто в рамках плановых обновлений АБС. Конечно, скорее всего, ряд АБС производителей не упустит возможности на этом немного «погреть руки», однако, большой проблемой для большинства банков это не будет.
                Что касается технической реализации, был я в 2016 году на одной встрече по данной теме, там так же присутствовали (помимо ЦБ) еще и представители производителей ПО: Diasoft, 1C и ЦФТ. Причем, они все в один голос заявили, что не видят большой технической проблемы в переходе на XBRL отчетность. Так, представители 1С и Diasoft сказали, что просто добавят модуль конвертер текущей отчетности в XBRL без каких либо серьезных изменений в ядре систем. Учитывая то, что (сильно утрируя) основная «фишка» XBRL это введение множества дополнительных производных\промежуточных показателей, данный подход кажется абсолютно логичным и прозрачным. А вот ЦФТ говорили о глубокой интеграции логики XBRL в ядро, наверное, для того бы в очередной раз продать подороже .

                В любом случае, пример с XBRL отчетностью, на мой взгляд, заставляет еще раз посмотреть в сторону и оценить плюсы именно проверенных отечественных решений «из коробки». Т.к. поддерживать собственные in-house разработки в таком быстро меняющемся мире становится все сложнее.
                  0
                  Вы очень точно обозначили складывающуюся ситуацию. XBRL покажет, насколько качественные ИТ-решения и процессы имеет каждая из компаний. Для НФО, у которых нет крутых core-систем (далеко не все крупные НФО решаются на их внедрение) это будет видно особенно отчётливо.

                  Если сильно упрощать, то XBRL выдвигает новые требования к собираемым данным, значительно более широкие, чем было до сих пор; и у тех компании, где бизнес- и системный анализ, сбор и обработка данных отлажены как швейцарский хронометр, не составит большого труда удовлетворить эти требования, ведь завернуть готовые данные в xml нужного вида – технически несложная задачка. Остальным же предстоит колоссальный объём методологической и технической работы по созданию процессов подготовки данных для передачи в ЦБ. Про Excel и ручной ввод можно сразу забыть – счёт идёт на десятки тысяч значений ежемесячно.

                  Но самое печальное то, что ЦБ уже год кричит на всех углах про XBRL, про то, что всем давно пора бросать все и заниматься проектом, а то не никак успеть к концу года – но многие компании до сих не в курсе происходящего. Что ж, как говорится – держитесь там!
                    0
                    http://www.cnews.ru/news/line/2017-02-13_d2_strahovanie_perehodit_na_platformu_tsftstrahovaya

                    http://www.rgs.ru/pr/news/kompaniya-rosgosstrakh-sdelala-vybor-v-polzu-tsft-251115

                    Вот и посмотрим, как у них получится :)
          0
          Пресс-релиз Банка России:

          Банк России опубликовал предварительную версию финальной таксономии бухгалтерской (финансовой), надзорной и статистической отчетности страховых организаций, негосударственных пенсионных фондов и профессиональных участников рынка ценных бумаг для их перехода на XBRL (eXtensible Business Reporting Language, расширяемый язык деловой отчетности).

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

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

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


          31 июля 2017 года
            0

            XBRL — это просто формат. Сейчас страховые компании, например, через Пикософт формируют XTDD отчетность… Ну не будет Пикософта, будут другие инструменты меппинга на технологический формат. Таких тулов и в мире полно, и наши появятся. Вот некоммерческий проект с меппингом отчетности на XBRL есть — http://xbrl.org.ru. И это не считая бухгалтерских систем и АБС, где вендоры будут встраивать XBRL экспорт. У таких систем другая будет проблема — данные из разных систем надо свести в непротиворечивый и согласованный датасет и только потом этот датасет в XBRL сконвертировать, что не позволяет меппинг на 100% out-of-the-box реализовать.

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

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

              Техническая сторона вопроса – конвертация массива отчетных данных в привязанный к таксономии XBRL-отчет – выглядит сравнительно проще.

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

              P.S. Указанный вами проект видимо не очень активен – выложена пара утилит (менее функциональный аналог Arelle и какой-то конвертер), перепост новостей.
                0
                Не могу полностью согласиться. Модель данных в XBRL таксономии Банка России для некредитных финансовых организаций (НФО) за малым исключением полностью повторяет текущие требования надзора НФО и 100% соответствует требованиям Отраслевых стандартов бухгалтерского учета (ОСБУ). В том числе, в таксономии можно найти и визуализацию в виде, похожем на «классические» формы отчетности (Table Linkbase, Dimension Tables).

                Таким образом: «С XBRL ситуация сложнее – объем данных несоизмеримо больше» — в текущей таксономии XBRL ЦБ это не так.

                Про этот небольшой проект — не совсем так, Arelle — только инструмент просмотра, а тут один из тулов — это попытка реализации конвертера из Excel в XBRL, что в мире только за деньги.
                  0
                  Разве сегмент НСО (надзорно-статистическая отчётность) таксономии НФО входит в состав передаваемых через Пикософт данных? (сам не знаю, поэтому спрашиваю) Даже если входит, Table linkbase я видел пока только в БФО сегменте.

                  НСО частично заполняется из счетов ЕПС и символов ОФР (но и там есть нюансы вроде разбивки счета/символа на несколько концептов по дополнительным аналитическим признакам. Кроме того есть концепты, факты по которым формируются только вручную (вроде Среднесписочной численности).

                  Так или иначе, основная моя мысль была в том, что прежде чем использовать XBRL-коробку (будь то новый модуль бухгалтерской учётной системы или АБС, либо отдельные решения вроде упомянутого вами конвертера), надо потратить немало времени на анализ соответствий между формами Пикософта/данными в системах компании и конвертами своей точки входа таксономии.

                  Да, под аналогом Arelle я имел в виду SXV XBRL Viewer.
                    0
                    Надзор субъектов страхового дела входит в Пикософт, в который заложена куча контрольных соотношений к этому надзору, не все из которых, кстати, сейчас заложены в таксономии XBRL для этого рынка.

                    Могу ошибаться, но надзорка в таксономии весьма субъективно связана с ЕПС и символами, так как технически (на уровне контрольных соотношений) она ближе к блоку ОСБУ (по таксономии опять же). Сейчас непонятно, как будут распределены между собой пакеты отчетности БФО и надзора в рамках XBRL. Следим за новостями с фронтов…

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

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

                    А в целом все верно. Вы правы. Это все боль для рынка даже в текущем варианте. А ранее в базовой и тн расширенной таксономиях были идеи еще и модель данных существенно детализировать. Это совсем бы всех подкосило, но вовремя отказались…

                    Отдельно про Table Linkbase — посмотрите, как оно в надзорном блоке. Есть мысль, что эту часть таксономии можно утилизировать для автоматизации.

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

            Самое читаемое