Taming XBRL: Analyst Notes
Since 2018, the Russian Central Bank (as a regulator) obliged non-credit financial institutions (NFO), i.e. all enterprises of the financial sector of the economy, except for banks, namely insurance, pension funds, prof. securities market participants, management companies, to report to it in a new format - according to the XBRL specification (rather than excel or xml).
The scope of the supervisory (statistical) reporting includes information on the founders and customers, insurance objects, premiums and payments, deposits and investments, counterparties, etc. etc. - really hundreds of thousands of facts. In this regard, in order to facilitate bureaucracy and adhere to the accuracy of the procedure, we’ll tell you about a project to automate the generation of reporting in XBRL by one large NFO based on the Fujitsu XBRL decision.
In addition to the regulator, the financial statements were transferred to the XBRL format, as they have potentially more recipients, as well as tax, exchange and tender platforms. It should be remembered that the ultimate goal of the Central Bank is to transfer to XBRL and banks in order to be able to monitor as quickly and as deeply as possible.
XBRL - eXtensible Business Reporting Language, or “Extensible Business Reporting Language”, is designed to simulate reporting forms and as a format for transmission to a regulator of indicators by accountable companies.
Traditionally, reporting forms were created by some people (the methodologists of the regulator - the Central Bank), filled with other people (accountants of accountable organizations) and checked by third people (ordinary specialists of the Central Bank).
The volume of reporting is increasing: the number of indicators has already grown to thousands, with it, it has become more frequent. For example, banks report to the regulator daily. In such conditions, it becomes more and more expensive to fill in and process reports manually, so it is advisable to use automation in these conditions.
The human-to-human interface is replaced by a machine-to-machine interface, where a mathematically precise specification of the format of the transmitted data, which is XBRL, is needed.
The first XBRL specification was created about 20 years ago by the American Association of Certified Accountants. The format is the same extensible (eXtensible) as the underlying XML; but if XML extensions are different markup languages, then XBRL extensions are models of different subject areas (“domains”). For example, the IFRS / IFRS model or the tax form model.
The basis of the XBRL language, like any language, is a dictionary, i.e. a list of words (“concepts”), written in Latin letters and having their own attributes (data type, belonging to the categories “as of date” / “for a period” and debit / credit, “abstractness” flag).
Then, using the vocabulary of the domain, all the forms that make up the reporting are modeled.
The XBRL model is in the simplest case a sequence of language concepts, i.e. given order of their passage. First, assets, then liabilities and capital; first cash, then deposits. The only way. Without gaps and without extra lines.
A typical form model is a combination of elements and analytical cuts along geometrical axes (X, Y and even Z) specified in a certain order.
The “superposition” of analytical sections and reporting periods is “decomposed” along the X and Y axes.
Before the advent of XBRL, indicators in forms were not named, and adding a new indicator made it difficult to compare the form over the old period and the new one.
In the same way, the inter-form controls tied only to the row and column numbers were “leaving” inside. With the new edits, the complexity increases nonlinearly. In XBRL, formulas in controls consist of named variables; therefore, the control ratio does not need to be changed at all when changing form layouts.
The usual vendor approach (most often, this is 1C franchisee, i.e., 1C partner companies) to adding exports to XBRL is to mark rows / columns in report layouts and, when exporting, issue a sequence of concept values - “facts”. The resulting instance (instance - “XBRL instance / report”) is then validated for XML conformance, XBRL (plus control ratios are checked for its facts) using free or commercial software (for example, Arelle or Altova).
The difficulty for such a vendor is that when creating an XBRL document (as a text file), all XBRL syntax rules should be observed: no duplicates of facts and “contexts” and, most importantly, taxonomy compliance. The facts in the created report should correspond to the taxonomy by name and type, the tables - by the presence of mandatory analytical sections. The picture is aggravated by changes in the taxonomy itself, which must be supported along with the previous versions (the Central Bank may at any time ask to retake reports for the previous period).
And if Russian companies are faced with the need to support XBRL in 2017, then Fujitsu has a much longer history of competencies in XBRL. It goes back to 2006, when all the companies listed on the Tokyo Stock Exchange (Tokyo Stock Exchange) obliged to disclose their key indicators in the XBRL.
Fujitsu has its own, certified XBRL processor used by regulators in many European countries, which allows you to load the taxonomy into memory and create an XBRL report not as a text file, but as a kind of document object model (DOM).
On the basis of this processor, a toolkit has been created that can be used by both accountable companies and regulators. The CBR also chose it to create a Russian taxonomy.
If we are talking about deeper integration with accounting systems (automatic conversion of financial statements into XBRL), then here we also use a more flexible and powerful 3-tier approach.
Accounting system developers are not required to mark up each report and maintain such markup. Usually, any report can be saved as an Excel file, but for us it is required to save it as a simple vector of “cells” (row-col-value). For example, the illustration below.
A table of 4 columns and 12 rows turns into 48 cells. This non-relational presentation format provides maximum flexibility. For each layout, you can further restrict the upload area, so as not to include the row and column headings of the table, the header and footer of the report, which additionally speeds up the transfer of data in the integration solution.
The second link in our architecture is the layout of the customer’s current forms. Due to the fact that there are a lot of different accounting systems (standard configurations and own developments of 1C, non-1C, such as SAP and Oracle), the reporting layouts differ and the coordinates will also differ. In general, each customer has their own layouts (example below).
The highlighted areas of the layout correspond to different elements of the taxonomy. Such markup is formalized in an elementary way - first in bird language, and then in taxonomy concepts:
Moreover, if from the customer to the customer the coordinates of the regions can change (the first 4 columns), then the taxonomy elements remain common to all. Therefore, the second link is also very light and flexible.
Moreover, if there are changes in layouts or taxonomies, we load the mappings as part of the configuration (there is versioning), without changing the code, and even without restarting the solution.
This mechanism allows you to mark up even those forms that can not be modeled using Table LinkBase - the most advanced extension of the XBRL standard.
The intersection of facts and mappings is used by the third link. With the help of an XBRL processor that keeps the taxonomy in mind, we create a model of the report document; and about all errors in the process we write to the log and warn the user.
If these are errors in the data (type or format mismatch, for example) - the accountant understands; if there are errors in mappings, the analyst understands. Thus, validation occurs at the earliest stage and at the level of individual forms (and not just the entire reporting). Of course, a report from the memory at any time can be saved to disk.
For users, the process looks as simple as possible. After the period is closed in the accounting system, the accountant generates a report. In one click, he sends it to XBRL, just as he can print. After that, in the web-based interface, the accountant sees the html-render of the same report (based on the TableLinkbase layer of taxonomy, to make sure that the data has "formed") and sees if there are any errors and if so, which ones.
The entire volume of reporting (N tables) can be divided by the manager between several responsible accountants and specialists. If some forms are missing in the accounting system, those responsible can download them from Excel, which are “cut” by a special software tool into a vector of facts, similar to illustration No. 3. When all the tables are “ready” without critical errors, the manager downloads the final report and uploads it to the personal account on the Central Bank website.
Here is a deeply integrated solution. Does not require additional stages of conversion and covers the entire volume of reporting.
Many vendors were forced to quickly include support for XBRL in their decisions, so I invite analysts and programmers to discuss urgent issues here.
The scope of the supervisory (statistical) reporting includes information on the founders and customers, insurance objects, premiums and payments, deposits and investments, counterparties, etc. etc. - really hundreds of thousands of facts. In this regard, in order to facilitate bureaucracy and adhere to the accuracy of the procedure, we’ll tell you about a project to automate the generation of reporting in XBRL by one large NFO based on the Fujitsu XBRL decision.
In addition to the regulator, the financial statements were transferred to the XBRL format, as they have potentially more recipients, as well as tax, exchange and tender platforms. It should be remembered that the ultimate goal of the Central Bank is to transfer to XBRL and banks in order to be able to monitor as quickly and as deeply as possible.
A brief introduction to XBRL
XBRL - eXtensible Business Reporting Language, or “Extensible Business Reporting Language”, is designed to simulate reporting forms and as a format for transmission to a regulator of indicators by accountable companies.
Traditionally, reporting forms were created by some people (the methodologists of the regulator - the Central Bank), filled with other people (accountants of accountable organizations) and checked by third people (ordinary specialists of the Central Bank).
The volume of reporting is increasing: the number of indicators has already grown to thousands, with it, it has become more frequent. For example, banks report to the regulator daily. In such conditions, it becomes more and more expensive to fill in and process reports manually, so it is advisable to use automation in these conditions.
The human-to-human interface is replaced by a machine-to-machine interface, where a mathematically precise specification of the format of the transmitted data, which is XBRL, is needed.
The first XBRL specification was created about 20 years ago by the American Association of Certified Accountants. The format is the same extensible (eXtensible) as the underlying XML; but if XML extensions are different markup languages, then XBRL extensions are models of different subject areas (“domains”). For example, the IFRS / IFRS model or the tax form model.
The basis of the XBRL language, like any language, is a dictionary, i.e. a list of words (“concepts”), written in Latin letters and having their own attributes (data type, belonging to the categories “as of date” / “for a period” and debit / credit, “abstractness” flag).
Then, using the vocabulary of the domain, all the forms that make up the reporting are modeled.
The XBRL model is in the simplest case a sequence of language concepts, i.e. given order of their passage. First, assets, then liabilities and capital; first cash, then deposits. The only way. Without gaps and without extra lines.
A typical form model is a combination of elements and analytical cuts along geometrical axes (X, Y and even Z) specified in a certain order.
The “superposition” of analytical sections and reporting periods is “decomposed” along the X and Y axes.
Before the advent of XBRL, indicators in forms were not named, and adding a new indicator made it difficult to compare the form over the old period and the new one.
In the same way, the inter-form controls tied only to the row and column numbers were “leaving” inside. With the new edits, the complexity increases nonlinearly. In XBRL, formulas in controls consist of named variables; therefore, the control ratio does not need to be changed at all when changing form layouts.
Fujitsu XBRL Solution
The usual vendor approach (most often, this is 1C franchisee, i.e., 1C partner companies) to adding exports to XBRL is to mark rows / columns in report layouts and, when exporting, issue a sequence of concept values - “facts”. The resulting instance (instance - “XBRL instance / report”) is then validated for XML conformance, XBRL (plus control ratios are checked for its facts) using free or commercial software (for example, Arelle or Altova).
The difficulty for such a vendor is that when creating an XBRL document (as a text file), all XBRL syntax rules should be observed: no duplicates of facts and “contexts” and, most importantly, taxonomy compliance. The facts in the created report should correspond to the taxonomy by name and type, the tables - by the presence of mandatory analytical sections. The picture is aggravated by changes in the taxonomy itself, which must be supported along with the previous versions (the Central Bank may at any time ask to retake reports for the previous period).
And if Russian companies are faced with the need to support XBRL in 2017, then Fujitsu has a much longer history of competencies in XBRL. It goes back to 2006, when all the companies listed on the Tokyo Stock Exchange (Tokyo Stock Exchange) obliged to disclose their key indicators in the XBRL.
Fujitsu has its own, certified XBRL processor used by regulators in many European countries, which allows you to load the taxonomy into memory and create an XBRL report not as a text file, but as a kind of document object model (DOM).
On the basis of this processor, a toolkit has been created that can be used by both accountable companies and regulators. The CBR also chose it to create a Russian taxonomy.
If we are talking about deeper integration with accounting systems (automatic conversion of financial statements into XBRL), then here we also use a more flexible and powerful 3-tier approach.
Accounting system developers are not required to mark up each report and maintain such markup. Usually, any report can be saved as an Excel file, but for us it is required to save it as a simple vector of “cells” (row-col-value). For example, the illustration below.
A table of 4 columns and 12 rows turns into 48 cells. This non-relational presentation format provides maximum flexibility. For each layout, you can further restrict the upload area, so as not to include the row and column headings of the table, the header and footer of the report, which additionally speeds up the transfer of data in the integration solution.
The second link in our architecture is the layout of the customer’s current forms. Due to the fact that there are a lot of different accounting systems (standard configurations and own developments of 1C, non-1C, such as SAP and Oracle), the reporting layouts differ and the coordinates will also differ. In general, each customer has their own layouts (example below).
The highlighted areas of the layout correspond to different elements of the taxonomy. Such markup is formalized in an elementary way - first in bird language, and then in taxonomy concepts:
Moreover, if from the customer to the customer the coordinates of the regions can change (the first 4 columns), then the taxonomy elements remain common to all. Therefore, the second link is also very light and flexible.
Moreover, if there are changes in layouts or taxonomies, we load the mappings as part of the configuration (there is versioning), without changing the code, and even without restarting the solution.
The choice of such an integration scheme was inspired by the “RC-coding” mechanism used in some European taxonomies. Along with “human” concepts, each row and each column of the report is also marked with numeric codes, i.e. all ranges are already numbered by the creators of the taxonomy. In the taxonomy of the CBR, this layer is also present, but not yet on all tables.
This mechanism allows you to mark up even those forms that can not be modeled using Table LinkBase - the most advanced extension of the XBRL standard.
The intersection of facts and mappings is used by the third link. With the help of an XBRL processor that keeps the taxonomy in mind, we create a model of the report document; and about all errors in the process we write to the log and warn the user.
If these are errors in the data (type or format mismatch, for example) - the accountant understands; if there are errors in mappings, the analyst understands. Thus, validation occurs at the earliest stage and at the level of individual forms (and not just the entire reporting). Of course, a report from the memory at any time can be saved to disk.
The core of the XBRL processor is written in Java, and we also write in Java. In general, all kernel methods are available through the API and for .NET.
Other technologies are fairly standard: React JS user interface; Therefore, accountants can work with the system simply through a browser (which is important in large companies, where there are strict security rules for software installations).
At the same time there is integration with Active Directory. Front and back are connected via REST API; It is also used for integration with accounting systems. Methods are automatically documented using Swagger.
For users, the process looks as simple as possible. After the period is closed in the accounting system, the accountant generates a report. In one click, he sends it to XBRL, just as he can print. After that, in the web-based interface, the accountant sees the html-render of the same report (based on the TableLinkbase layer of taxonomy, to make sure that the data has "formed") and sees if there are any errors and if so, which ones.
The entire volume of reporting (N tables) can be divided by the manager between several responsible accountants and specialists. If some forms are missing in the accounting system, those responsible can download them from Excel, which are “cut” by a special software tool into a vector of facts, similar to illustration No. 3. When all the tables are “ready” without critical errors, the manager downloads the final report and uploads it to the personal account on the Central Bank website.
In custody
Here is a deeply integrated solution. Does not require additional stages of conversion and covers the entire volume of reporting.
Many vendors were forced to quickly include support for XBRL in their decisions, so I invite analysts and programmers to discuss urgent issues here.