Digital Financial Reporting

The first iteration of what I call the "comprehensive example" is available on my web site. What the comprehensive example does is take all of the business use cases and puts them into one XBRL instance. The purpose of this is to test the interrelationships between the use cases and to provide something that looks enough like a financial statement so that it seems real, but is not as complex as a real financial statement so is easier to work with.

The comprehensive example puts all the issues of expressing information using an XBRL taxonomy and XBRL instance where you can see them. In its current form, you have to dig a bit because I have not provided a narrative which ties all the pieces together.  I have only provided the pieces themselves. But, should one roll up their sleeves and dig in, there is a lot to see and learn.

Here are the key points of this comprehensive example XBRL taxonomy and XBRL instance (all these are detailed on the overview page):

• Use case: This is a visualization of the use caseI am trying to express in XBRL.
• End result: This is the end result I was able to generated to meet the use case. This is what I call a "viewer" or a rendering of the exact same information auto-generated from only the XBRL taxonomy and XBRL instance.
• Metapatterns: The comprehensive example has come full circle. I used to create XBRL taxonomies by keying XBRL syntax into an XBRL application. That is the wrong way to work with XBRL. The right way is to add a business semantics layer above XBRL.  This makes generating XBRL easier for business users and it yields higher quality XBRL. The comprehensive example and business use cases proves the metapatterns. The metapatterns were derived from the business use cases and the comprehensive example. Basically, work with metapatterns, not XBRL. Generate the XBRL automatically from the metapatterns.

All the other things support the process of getting from the use case to the end result. The "other things" overcome all of the issues that I have run across. For example, the comprehensive example has 53 different information components.  I needed to put them into a sequence. I used an XBRL taxonomy definition linkbase to create an ordering of the components.  I call this the "flow" of the business report. You can see that flow expressed here. This is far better than ordering the extended links using numbers in the extended link description.  They are not all done yet, but I will have 100% of the computations in the XBRL instance verified (i.e. the data integrity is checked) using business rules.  See the results here and here. That is just a taste of what you can see on the overview page if you care to look.  Eventually I will create a narrative which connects things together better.

The most important thing the comprehensive example shows me is how to make XBRL work soundly and safely when leveraging XBRLs extensibility. The keys are being explicit, being consistent, and having a sound architecture.

These ideas are not the only way to tame the XBRL beast to get it to effectively and efficiently serve your needs. But, they are the best accumulation of techniques that I could put together based on what I have learned over the years about working with XBRL.

Check back for updates, I am still plunking away at this as time permits.

This is video introduction to HL7 (Health Level Seven). You may not care about HL7, but this iintroduction to HL7 can help you understand why XBRL is important.  HL7 and XBRL both help business systems interoperate with one another.

Meaningful interoperability between systems, how do you get there? Slides 4 through 6 explain three key things needed to achieve meaningful interoperability. The link on slide 6 takes you two a PDF which explains the three things needed for meaningful interoperability.

• Technical interoperability is concerned with the conveyance of payload. It neutralizes the effect of distance, is domain independent (OSI levels 1-6), and is fundamentally based on Information Theory - Shannon (1948).
• Semantic interoperability communicates meaning unambiguously, using Codes, Identifiers and Context. It is Domain-specific (OSI Level 7) and is needed to understand, interpret and use data.
• Process interoperability enables shared human understanding that is needed to coordinate work processes and enable business systems to interoperate. It is essential if interoperability is to provide any benefits in the work place.

The bottom line here is that business system interoperability means benefits to business in terms of efficiency.

Understanding the Three Levels of Interoperability