ADOPTION SCENARIOS FOR XBRL ON REPORTING CHAINS

X-DIS/XBRL project

Madrid, 26th of March of 2007

Eurostat Reference: X-DIS/XBRL

Software AG Reference: PHC6CE01/P7X-0001/1.02

Created / Updated / Revised / Approved
By: Software AG Team /
By: Giuseppe Sindoni (Eurostat Project Officer)
/ Confidential Document property of Eurostat /
ALTERNATIVES FOR ADOPTING XBRL FOR REPORTING
Eurostat reference:
X-DIS/ XBRL / Version:
01.02 / Creation date:
26-03-2007 / Page:
1
Software AG Reference:
PHC6CE01/P7X-0001
Content Table
Page
1.Glossary
2.Objectives And Scope of the Document......
3.Description of the Process......
4.Logical Reporting Procedure......
5.Reporting Chain Automation Process. Why XBRL?......
6.Physical Required Infrastructure......
7.Stage 1. Report Extraction......
7.1Process 11. Data Compilation......
7.1.1Manual Data Compilation......
7.1.2Pipelined Data Compilation......
8.Stage 2. Report Production......
8.1Process 21. Generation of the Report on Delivery......
8.1.1Manual Generation of Electronic Report......
8.1.2Manual Generation of XBRL report......
8.1.3Pipelined Electronic Report Generation......
8.1.4Pipelined XBRL Report Generation......
8.2Process 22. Validation of the XBRL Instance On Delivery......
8.2.1Manual XBRL Validation......
8.2.2Pipelined XBRL Validation......
9.Stage 3. Report Delivery......
9.1Process 31. Report Delivery......
10.Stage 4. Report Transmission......
11.Stage 5. Report Reception......
11.1Process 51. Report Reception......
11.2Process 52. Generation of Report on Reception......
11.2.1Manual Generation of Electronic Report......
11.2.2Manual Generation of XBRL report......
11.2.3Pipelined Electronic Report Generation......
11.2.4Pipelined XBRL Report Generation......
12.Stage 6. Report Processing......
12.1Process 61. Validation of Report on Reception......
12.1.1Manual XBRL Validation......
12.1.2Pipelined XBRL Validation......
12.2Process 62. Propagation to Suitable Backend......
12.2.1Manual Propagation......
12.2.2Pipelined Propagation......
13.Stage 7. Report Storage......
13.1Process 71. Data Persistence on NSI Backend......
14.Typical Configurations......
14.1No Automation......
14.2Generation of XBRL Report at NSI Side......
14.3Third Party Tools - Offline Report Generation......
14.4End to End Data Integration......
15.Further Processing of Received Data......
16.Defining the Suitable scenario......
17.XBRL Reference Architecture......
18.Future Works......
19.References......
20.Latest Changes......

1.Glossary

The following table offers a relationship of some frequently used XBRL terms:

Concept / Definition
XBRL / extensible Business Reporting Language - an XML based framework that provides the financial community with a method to prepare, publish in a variety of formats, extract and exchange financial statements - it is expected to have major implications for all concerned with presentation and analysis of company accounts. Development is led by a Steering Committee of over 100 organisations and corporations including the US Census Bureau. XBRL taxonomies already existed for some specific reporting schemes, such as US GAAP, and are under development for many others, including IAS and several national GAAPs.
XBRL report / It is the XML document compliant with XBRL spec, which contains the values (facts) defined by the taxonomy which it belongs to. Form the technical point of view, it is the XML document that can be validated against the xsd schema.
XBRL Taxonomy / XBRL taxonomies are "vocabularies" or "dictionaries" created by a group in order to exchange financial information.
NSI / National Statistics Institutions refers to the National body in charge for compilation and dissemination of statistical information at a country level. Depending on the country it can include the Statistical Office as well as Central Bank or Ministers as they Legal Framework assigns them competencies.
ESS / European Statistical System – includes NSIs, MemberState government departments and agencies engaged in statistical activities, central banks, international bodies active in EU statistics, etc
EU / European Union
EEC / European Economic Community.
NACE / Classification of Economic Activities within the European. Communities", known by the acronym NACE and originally published by Eurostat in 1970. The acronym "NACE" derives from the French title: Nomenclature générale des activités économiques dans les Communautés Européennes.
GL / A book of final entry summarizing all of a company's financial transactions, through offsetting debit and creditaccounts. It is usually base don a chart f accounts.
FR / Financial Reporting.
/ Confidential Document property of Eurostat /
ALTERNATIVES FOR ADOPTING XBRL FOR REPORTING
Eurostat reference:
X-DIS/ XBRL / Version:
01.02 / Creation date:
26-03-2007 / Page:
1
Software AG Reference:
PHC6CE01/P7X-0001

2.Objectives And Scope of the Document

Within the scope of the XDIS/XBRL project, the feasibility of introducing the XBRL format to collect financial information of enterprises by the NSIs must be analysed. The possibility to extract information from enterprises in XBRL format, as well as the suitable format handling and integration within NSI systems must be demonstrated.

In the reporting process, the degree of automation of the market processes is a key point to allow companies save reporting burden and resources for their actual core business. However, this degree of automation lays on the evolution degree and directives powered by the regulators which are the actual triggers of this automation process.

The present document is targeted for NSI representatives to enjoy enough arguments to make the right choice on the selection of the degree of adopting XBRL for their reporting chain and schedule a suitable adoption plans according their necessities and the offering that they want to do to their reporters.

We depict the possible adoption scenarios to provide overall guidelines that allow NSIs understand the impact and requirements for each scenario and eases designing a suitable and feasible adoption strategy.

The document will work as a basis to state the problem, discuss the scenarios and implementations available on market. We also will provide links to companion documents explaining further the different aspects mentioned.

Every single situation is different and some aspects must be considered:

  • Country investment culture. No all the enterprises from Member States have the same investment culture, as some ones have a more extended information and knowledge economy.
  • Kind of reporters, banking reporters usually are more willing to investment
  • Automation degree of previous scenario and required steps for full XBRL adoption. Depending on the features of the reporting scenario previous to XBRL adoption, migration to enhance a full XBRL reporting chain will be a bit more difficult. The most automated is the process before, the easiest migration. The long term intended scenario will be ability of ERP software to produce XBRL data.

Therefore, each NSI willing to integrate XBRL on its reporting chain must identify their environment and design a customized strategy accordingly.

3.Description of the Process

At the broader picture the process of collecting data by the NSI from enterprises must be analysed. The picture below represents the actors and reporting flows involved in the information exchange.

It is important to clarify that the problem focuses on the path labelled as 1, which refers to the reporting of information from enterprises to the NSI.

The scope of the current document is discussing the possibilities for the NSI to create enterprise necessity to integrate XBRL in their reporting chain and the different stages for the mentioned adoption process. As a consequence, the scenario this document deals with is the reporting of a single enterprise to the NSI as commented in the next section.

4.Logical Reporting Procedure

The picture below depicts the stages of the reporting chain between an enterprise and a National Statistics Institution (NSI). We will consider the largest feasible transmission process, which is supposed to be from backend to backend, i.e. from the DBMS of the reporting enterprise to the DBMS of the NSI.

By identifying every of the possible abstract stages that compose the reporting chain, we can outline a reference Reporting Framework. Identifying the inputs and outputs and guaranteeing that they match as required, we can design and define a common scenario that highlights those aspects to be tracked for accuracy and validation.

On the other hand, it would provide a reference about what aspects to investigate in the reporting chain and a reference environment to bring the discussions further. In this way, the proposed discussions could be considered a seed to producing specifications for determining the necessities of reporting software and clarify the definition of implied processes.

As depicted above, the whole process can be split in 7 stages, depending on the status of the information is being reported. By creating this chained abstraction, we can highlight the features for each of the steps and design a migration mechanism from early manual processing to a final XBRL adoption all along the chain.

There are some important assumptions for exposing this Reporting Chain Reference Scenario (they will not be tested):

  • XBRL taxonomy definition is fully decoupled from the infrastructure. Therefore, we will suppose the XBRL architecture is already defined, known and available by all parties of the Reporting Chain. In order to extend information about the functional issues implied by the XBRL adoption, please refer to other documents within the project, e.g. deliverables on Tasks 1, 3, 5 and 6.
  • Data operationsbeyond of the enterprise’s DBMS to the NSI’s DBMS transmission are out of the scope covered by the present reporting chain. Actions performed on data before and after this process will be beyond the scope of this document. However, typical ETL (Extraction-transform and load) operations of the information can be accepted at the different phases.
  • The whole process will be analyzed only from the architectural/technological point of view. To be able to bring the discussions to business areas it would be necessary to assume further constraints on the system, so actual integration processes can be established between parties. This is, by now, beyond of the state of the arts. Considerations about process interoperability will be analysed on the Task 6 of the project.

5.Reporting Chain Automation Process. Why XBRL?

As commented, NSIs are the triggers for this automation process and burden reduction on reporting, so they are the ones that should design their customised adoption strategy, considering their self interest and also the interest of reporters.

At the long term scenario, the producer will be able to apply for semantically aware information as risk data, financial reporting data, fraud data, sustainability data, etc. when this stage is achieved the systems will become risky, fraud or corporate social responsibility aware. When this is achieved, an actual integration process will enhance systems to speak to systems around, and accommodate their process accordingly.

To achieve this process interoperability scenario, a couple of communication levels are required:

  • Technological communication implies sharing common data format that can be understandable by all market parties.
  • Business model communication implies sharing a common model on the business of every end to allow them cooperates at the IT systems level.

The beneficiaries of this automation are all parties:

  • NSIs as information consumers can obtain saving in data collection and quality improvement.
  • Enterprises since their reporting process becomes an automatic one, allowing dedicate resources for their core business.

XBRL represents the proposed format by the finance and accounting community to exchange financial information reporting on the market.

To accomplish this future picture, it is required that the works are launched to allow parties deals with the XBRL format. NSIs, as triggers of the adoption process, have the mission of designing the strategy to propagate the format downstream through the reporting chain, from the consumer back to the producer, to attain a full scenario of interoperability at the long term.

/ Confidential Document property of Eurostat /
ALTERNATIVES FOR ADOPTING XBRL FOR REPORTING
Eurostat reference:
X-DIS/ XBRL / Version:
01.02 / Creation date:
26-03-2007 / Page:
1
Software AG Reference:
PHC6CE01/P7X-0001

6.Physical Required Infrastructure

The core issue discussed in this document is understand the possible scenarios and product implementations available on the market, for every of the stages introduced in the previous section for adopting XBRL on the reporting chain.

The stages described could be achieved by different means creating a full set of tools available for each case. In order to classify them, we can find 2 dimensions:

  • How the task is performed, manual tasks or pipelined tasks i.e. chained with electronic output of previous stages.
  • How is the information supported, either a Paper Based filled questionnaire, an electronic format or an XBRL electronic format.

Paper Based / Electronic Format / XBRL Format
Manual
Performance
of Process / Classical usage of questionnaires
/ Manual handling of a electronic format / Manual handling of XBRL format

Pipelined
Performance
of Process / N/A (*) / Pipelined handling of electronic format / Pipelined XBRL handling

(*) As represented using paper in electronic pipelined performance is not considered.

From now on, we will expose the alternative implementations to achieve each of the previous stages. We will highlight the tools available on market for each of these situations to allow the NSIs fit on the suitable scenario.

7.Stage 1. Report Extraction

This stage is required by all the companies that hold an automated reporting process. It aims to accomplish all the required information in a single point to enable the next stage of report production.

The input of this stage is either a group of employees aware about the required data or persistence systems which collect transactional information as common DBMS, Legacy Systems as CRM or ERP, DWH or Data Marts. Information can be extracted from them either by manual processes or with some electronic querying capabilities to persistence systems.

The output is the required information collected at a single physical point ready for further stages. The format can be either a paper based format, an electronic format or XBRL inside of a DBMS, DWH, Data Marts or a File in the file system.


7.1Process 11. Data Compilation

The process is created to guarantee that the data is compiled in electronic format somewhere in the company’s infrastructure. Depending on how the data is collected we have several possible implementations as described below.

Sometimes this compilation of information at a single point is not just targeted for reporting issues but also designed for other issues related with the enterprise activity. In turn, data warehouses are, by nature, designed to collect in a single data model all the enterprise’s information ready to be consumed by applications upstream.

Depending on where the information lays and on the evolution of the IT systems on the providing enterprise, we can find several evolution stages:

  • Manual data compilation, where the data is compiled from the people in charge. This is the case for e.g. traditional paper based questionnaires. Even with companies having the information stored in data sources, reporting savings can be achieved with this scenario,
  • Pipelining from data sources, where the data is stored and available on software persistence stores.

The transition from Manual Data Compilation to Electronic Data Compilations is an expensive task that goes beyond of XBRL adoption since it requires information to be stored on electronic format and in many occasions, redefining the enterprise processes.

Manual
Data
Compilation / Electronic
Data
Compilation
Stage A / Target

7.1.1Manual Data Compilation

When the information does not lay on electronic systems, the compilation process is not automated in the reporting company, the data is not collected from the one stored on backends.

It such cases, manual processes are involved to elicit the data from the people in charge of the core process. In these cases, some kind of Team Collaboration software (a.k.a. groupware software) can be helpful to dispatch to each Team Member the request about their data of interest.

In other cases, questionnaires move hand to hand on the company so each Team Member can fill their data.

7.1.2Pipelined Data Compilation

This task will be only targeted for enterprises intending end to end interoperability between their backends and NSIs backends. Therefore, enterprises which make up the questionnaires by hand are out of the scope covered by this stage.

For this scenario the assumptions applies having a set of data sources (legacy systems, data warehouses o DBMS), not matter their nature, which actually hold the information required for disclosure.

Considering the typical data infrastructure in a company integrated by:

  • Transactional data collected from the daily operations of the company, e.g. Legacy Systems, DBMSs or mainframes.
  • Central persistence stores designed to accomplish a reference point or collect all the company’s information, e.g. Data Warehouses.
  • Informational data as snapshots of the main data stores extracted to feed analytical systems targeted for tracking the company’s evolution, e.g. Data Marts.

As depicted in the figure, this persistence stores are connected by middleware software holding an integration pattern.

Both, Enterprise central data and Informational data hold the information required to fill the financial reports information to compile. We consider that Transactional data is too raw for feeding financial reporting systems, as the financial reporting is an aggregation of daily operations.

This exchange of information within the enterprise’ systems can be accomplished by different functionalities, depending on the mentioned integrated pattern:

  • ETL for the EAI integration pattern, which includes the tasks related to data extraction, transform and load (ETL) covering functionalities such as data profiling (analysing), cleansing (parsing, correcting, standardizing), augmentation, merging, consolidation.
  • Messaging for Messaging Oriented Middleware (MOM) as e.g. ESB.

Because of the high data transference required, this data transition process can be an error prone and a validation is necessary.

8.Stage 2. Report Production

This task will be only targeted for enterprises intending to deliver an XBRL report to NSIs. This stage refers to generate a valid XBRL instance from the data source ready to be distributed.

Therefore, the input of this stage is the data required to create the report, either in electronic format laying on file systems or persistence storage. The output is a well formed report in an electronic format, ideally XBRL.