¶ XBRL
Figure X-1 XBRL is complex
XBRL (eXtensible Business Reporting Language) is challenging to comprehend, create, validate, and use effectively. Despite these complexities, it has become an increasingly important standard for regulatory-defined documents across financial and environmental reporting.
GLOMIDCO has been working with XBRL since around 2010. It started with a request to teach XBRL at an accountancy department of the applied university of Amsterdam. Within weeks it became clear that XBRL was not XML and it was nearly impossible to use it in any available middleware product available on the market. With a background in integration, GLOMIDCO's approach from day one has been to treat XBRL as a message in flight—one that can be validated, generated, and parsed using standard integration and middleware components.
¶ 1. Why DPM is not a good solution
Most XBRL creation solutions are based on a DPM (Data Point Model). In this approach, users fill spreadsheets or databases, and after data gathering, the XBRL instance is created.
If you prefer the DPM approach, you're on the wrong website!
GLOMIDCO takes a completely different approach and philosophy to handling XBRL.
DPM has significant limitations compared to GLOMIDCO's mapping-based filling approach:
See DPM approach vs mapping based solution for the WHY.
¶ 2. GLOMIDCO products
GLOMIDCO delivers a range of XBRL products that handle XBRL through STP (Straight Through Processing).
The core component is the GLOMIDCO XBRL Processor—a Java-based XBRL processor optimized for runtime performance. On a server with sufficient memory (we'll discuss memory considerations later), thousands of XBRL messages per second can be processed, enabling near real-time integration into most information flows within any organization.
Initially designed to work with middleware platforms like Tibco BusinessWorks (BW), webMethods Integration Server (IS), and MuleSoft, the XBRL Processor recently gained new capabilities. Last year, GLOMIDCO developed a mapping capability called UTL-X, which eliminates the need for expensive middleware and enables bidirectional mapping between any message format (XML, JSON, YAML, CSV) and XBRL—all based on STP principles with high throughput.
Beyond the XBRL Processor, GLOMIDCO has developed a complete stack of components for handling XBRL (all using the same XBRL Processor as the engine):
- For Tibco BW 5.x: An XBRL plugin enables drag-and-drop handling of any taxonomy. Out-of-the-box (OOTB) components include an XBRL router and XBRL2XML/XML2XBRL activities. A Taxonomy Package Editor (based on the Taxonomy Package standard) is integrated into the product. Additional activities for Global Ledger (XBRL GL) are included, along with an XBRL merge component to combine partially filled XBRL instances (for example, with COREP/FINREP, each table can be mapped separately and then merged together). The output side features comprehensive error handling and detailed validation reporting.
- For Software AG (now IBM) webMethods IS: An XBRL adapter has been developed, allowing XBRL packages (.tax files) to be placed directly into IS projects.
- For MuleSoft 3: A certified XBRL connector was developed and available in the official MuleSoft store for several years. As MuleSoft has evolved, a connector for the latest version can be delivered upon request.
- Latest development: An open-source mapping solution allows you to use the GLOMIDCO XBRL Processor without the costs of commercial middleware vendors. Reach out to learn more and explore the UTL-X possibilities.
See
- Planned is to embedd the GLOMIDCO XBRL plugin in SAP CPI. This is not yet released.
See SAP XBRL adapter
¶ 3. Mapping to and from XBRL to any target or source
The mapping capabilities can be viewed here
Back to home page