Digital Financial Reporting

This PROOF BASELINE is an excellent learning tool.  For even more information please see this blog post.  The PROOF BASELINE is about getting the logic right.  Once you have the logic right, all you need is control.  Control is achieved through the use of rules. (This is the most current iteration of the proof baseline.)

• Technical syntax: Checks to be sure the XBRL technical syntax is appropriate.
• Model structure: Checks to see that XBRL presentation relations between report element categories are permitted.
• Roll up math: Checks to see if fundamental roll up relations expressed as XBRL calculation relations are valid.
• Roll forward and other math: Checks to see if all other mathematical relations expressed as XBRL formulas are valid.
• Type-subtype relations: Checks to see that "general-special" and/or "type-subtype" and/or "wider-narrower" relations are as expected.
• Disclosure mechanics: Checks essential report elements and related facts to see if disclosures are represented as permitted.
• Disclosure rules (reporting checklist): Checks disclosures to be sure required disclosures have in fact been effectively disclosed.

This best practice method can be used to verify that a financial report is a properly functioning system. There is still manual work necessary.

If you learn to create that PROOF BASELINE, you can very likely create any XBRL-based financial report.  To understand that representation, please read Intermediate XBRL-based Digital Financial Reporting. (Specifically, the documentation.) I will resync the documentation to the newest version of that PROOF BASELINE eventually.

You should consider trying to create what you can using Luca or my free open source tool.

The most challenging approach is to use the Inline XBRL or the PDF as your starting point to create the report. Alternatively, start by creating the model and the rules; then create the XBRL instance.

There is a difference between signal and noise.  Compare these three representations of one fragment of a financial report, the financial highlights:

1. Represented with a hypercube but no dimensions | (Get to full report)
2. Represented with a hypercube and four dimensions | (Get to full report)
3. Represented with a hypercube and twelve dimensions | (Get to full report)

Think about something.  Logically, what exactly is the difference between the representations with 0, 4, and 12 dimensions? 

The first representation is thrown in to round out the set of examples.  I could have shown another representation with NO HYPERCUBE.  So what exactly is the difference between a representation with NO hypercube and no dimensions and with 1 hypercube and no dimensions?  What logic does the hypercube provide?  The answer is that the hypercube only provides something to reference so that you can get to the representation itself which is identified by the hypercube.

The second representation was verified to be correct mathematically using XBRL Formulas. If you look at the validation result you can see there are 46 assertions which were used 96 times to verify information and that 100% of the results are "satisfied" meaning everything checks out fine.

The third representation is exactly the same as the second except for the fact that I added those additional dimensions to the financial highlights and to the balance sheet. See the presentation relations and the definition relations.  I then ran exactly the same verification rules to check and see if the math was still correct using XBRL Formula.  If you look at those results you notice that there are still 46 assertions, 96 were fired, and 96 were satisfied.

What is my point?  Logically, the XBRL Formula processor sees both the second and third representations as being logically the same.  Proof of this is the second and third representation validation results being 100% identical.

Why is this important?  Read through the list of XBRL dimensions in the second and third representations.  How helpful to you are the additional 8 in understanding the reported information?  The first four provide explicit and helpful information: what is the reporting entity, what is the legal entity, what is the report date, and what is the reporting scenario.  You can get away without the report date and the reporting scenario; those can be safely implied.  Maybe even the consolidated entity could be implied.

But customer, debt instrument, segment, director, related party, share ownership plan, reconciling item?  Those are details that are used on some other hypercube but are not relevant to the financial highlights or balance sheet.  Basically, those additional 8 dimensions are noise rather than signal.

Dimensions in XBRL work a certain specific way.  That way is specified.  Each regulator or other party implementing XBRL does not get to reinvent what dimensions are, what they do, or how they work.  All that is specified.

My little proof shows that most of this stuff works consistently across regulators that have implemented XBRL; a few things don't quite work correctly.

For more information please see my document Representing Structures.