reportfactory© analytics is a filing and analysis platform designed for receivers of XBRL electronic reports. The software supports validation, processing and analysis of electronic reports via a fully customizable rule-based workflow.
The visual rule editor, a core feature of reportfactory© analytics, allows business users extensive and simple workflow implementation and control – without any developer support.
SCOPE OF APPLICATION & TARGET GROUPS
Typically, XBRL report receivers utilize filing interfaces for the reports’ reception. Once received, the reports go through a process of adaption to existing data models. Finally, the received and adapted reports’ analysis takes place. In certain scenarios, the analysis results need to be submitted to additional output systems for further use.
reportfactory© analytics supports the entire process – from reception and adaptation to processing/analysis of XBRL reports and further submission of the obtained results.
The rule-based processing workflow can be fully customized and controlled in order to meet the receivers’ requirements.
The standardization provided by the XBRL format allows for seamless usage across various audiences as any and all XBRL taxonomies are supported by the software.
Among others, the intended audience are authorities, regulators, business registers, banks, insurance companies, stock exchanges and financial portals.
GRAPHICAL RULE EDITOR
The visual rule editor is at the core of reportfactory© analytics. It allows business users to have complete control of the report processing, without involving IT/developers.
Creating any rule using the visual rule editor is simple – all items required to build it are presented as interlocking puzzle pieces that can be combined by drag and drop.
Visualizing the rule creation process, in addition to being intuitive, has the added benefit of making errors transparent as any incorrectly used items are immediately highlighted.
Each rule or a group of rules can be tested by executing them during their creation process. In addition, to the visualization of the rule execution results, the rule execution log provides an execution summary including the actual value assignments being used to simplify troubleshooting – both in the testing phase and in productive use.
- Rules for validation and consistency checks
- Transformation rules (used for mappings, key figure calculations etc.)
- Notification rules (eg. sending out emails)
- Workflow control rules (used for workflow state modifications e.g. approval for manual edits)
As rules can be created for different purposes (e.g. production and testing) and by different people or teams simultaneously, rules are organized in rulesets that can be exchanged, adapted and tested.
Rules and rulesets are versioned allowing for seamless collaboration as well as the ability to revert any changes. Rules can be filtered with predefined or user-defined categories.
COMPLIANT WITH XBRL STANDARD
We are using the XBRL formula engine of our own ABRA XBRL processor to process the rules automatically. The engine is integrated in various products, both ours and our customers’, and is capable of processing huge amounts of data.
Because the XBRL formula standard deals with international standards, the available function library for validation and processing XBRL reports is very well established.
The step-by-step processing of incoming reports can be completely controlled using special workflow rules. Users can utilize the pre-configured workflow, modify it partially or define a workflow from scratch including custom processing steps.
The following workflow is delivered by default. It can be fully customized through workflow control rules in conjunction with the detailed information on the current workflow state, that kept in the analysis taxonomy.
The description of workflow/
Data input / manual creation
Reports are either received via a REST API or are created manually. Once in the system, both received and manually created reports can be freely viewed and modified
Received reports are archived in their original state (i.e. as received)
Additional data that’s required for the analysis (e.g. customer data) is added to the report
The enriched reports are checked by executing individual rules against them. By default, processing is stopped for invalid reports
The received reports are mapped to an individual balance analysis structure
The sum positions in the individual balance analysis structure are calculated
KPIs / Rating
KPIs / ratios are defined and calculated in a multi-phased rating process
The processing results are validated by executing individual rules against them. Any detected inconsistencies (as well as custom error messages) are visually indicated and can be rectified in the report editor
Export processing results
Processing results can be sent to further analysis systems via a web service or in batch runs