|
|
-
What is an Information Model?
-
XBRL, like XML, Java, C# or any other programming language, has a huge
amount of flexibility. Flexibility is very powerful. However,
flexibility can also be very confusing. For XBRL, an Information
Model provides a clear, concise, consistent way to represent data.
Other terms that are related to an Information Model are "Architecture",
"Structure", "Pattern", "Pattern", and "Application Profile". The
goal of an information model is to make the XBRL relatively easy to
create, process and analyze. Generally speaking, an information model is a set of Patterns.
-
What is a Pattern?
-
A Pattern (sometimes called a Meta-Pattern) is the expression of a logical user-level notion. In the XBRL domain these tend to be related to financial notions, such as a "calculation", or a "movements analysis".
|
-
What is the U S GAAP Information Model?
-
During the construction of the U S GAAP taxonomy, the taxonomy team created an architecture document that specified an information model. Furthermore, the taxonomy team went to great lengths to ensure that the taxonomy was internally consistent using validation rules similar to the ones offered by XBRL Cloud. Finally, at that time, it was the hope and expectation by many that extension taxonomies would follow the architecture outlined by the base taxonomy. The Patterns defined in the U S GAAP Taxonomy Architecture are:
-
The Table Pattern
-
Technically, a table is a set of primary items that share the same set of dimensions. And what does that gobbledy-gook mean?
The simplest analogy is to think about a Microsoft Excel spreadsheet. You
might have a list linear list of numbers (say a list of shares issued).
However, you can break this down (by date, by geographic region, by
class-of-stock, etc.). What you really end up looking at is a two
dimensional "grid" (the rows and columns of the Excel
spreadsheet), or possibly something with more than two "dimensions" (break
downs) that can really only be visualized in a "pivot table".
If you have a linear list, you don't need a table. However, a
Table must be used to represent a two-dimensional grid or
n-dimensional pivot table. Note that there are many strong arguments that
support that everything should be represented as a table.
-
The Hierarchy Pattern
-
A Hierarchy is simply a collection of items to be shown together.
Often instead of a completely "flat" list, you might wish to show some
structure, or grouping. This grouping can be done in a hierarchy. One
analogy might be a directory browser, where the directories are nested,
and you have a "tree control" to expand the directories.
-
The Calculation Pattern
-
A Calculation is very similar to a Hierarchy, except that the items in any group must roll up. For example, "Assets" might consist of "Current Assets" and "Non-Current Assets". "Current Assets" might be a roll up of individual assets.
-
The Roll Forward Pattern
-
A Roll Forward, also known as a "Movements Analysis", is a change in value over time. A Roll Forward consist of a beginning balance, and change, and an ending balance. Typically the "change" is a rollup (a.k.a. a Calculation).
|
-
Why should I care about the U S GAAP Information Model?
-
The most important aspect of following the U S GAAP Information is that it will help people understand the XBRL you are filing. If your goal is to meet the absolute minimum bar (the SEC accepts your XBRL), then the XBRL Cloud validator holds no value for you. However, if you want to create high-quality XBRL that can be analyzed by others, then you should be following the U S GAAP Information Model. Here are some key reasons to follow the U S GAAP Information Model:
- It will be possible to "render" your XBRL. Please see the discussion above about tables. If you tell people that something is a grid or pivot table, then they will know it's a grid (worse if you tell them it's a grid and it isn't that's very, very confusing).
- Presumably, XBRL will eventually require an audit. Auditors will require documents that they can visualize, follow, and sign off on. There is no guarantee that following the Information Model will make your XBRL more auditable, but consistent well-built documents are much easier to follow than poorly structured documents.
- Finally, the XBRL should actually be easier to create: When you have the Information Model in front of you, you don't have to spend a lot of time figuring out how to lay out the XBRL: it's much more obvious.
|
-
Is there a standard for the U S GAAP Information Model?
-
The U S GAAP Architecture document describes
the U S GAAP Information Model. That
said, currently there is no "conformance
suite" or other standard for implementations
of the U S GAAP Information Model. Our
hope is that other vendors will eventually
follow suit. Furthermore, like the the
EDGAR Filing Manual Validation (for which
XBRL Cloud was also a leader), perhaps the
SEC will "raise the bar" for XBRL filings in the future.
|
-
Why should I use XBRL Cloud's U S GAAP Information Model Validator?
-
To the best of our knowlege, XBRL Cloud is
the the only Information Model Validator on
the market. Cliff Binstock, one of the
founders of XBRL Cloud was one of the
technical architects on the U S GAAP
taxonomy project; we have extensive
knowledge in this area that we want to share
with you. We take the same pride in our
U S GAAP Information Model Validator
that we take in the rest of our software.
Like the EDGAR Filing Manual Validator, we are completely transparent in how we evaluate SEC filings via the
EDGAR Dashboard.
|
-
What exactly does the XBRL Cloud U S GAAP Information Model Validator check?
-
Frankly, and intentionally, we don't yet implement all of the possible Information Model tests. Here's why:
- We believe that our customers (and people reading the EDGAR Dashboard) would be overwhelmed with the number of validation errors they would see if we implemented every rule
- Some rules are much more important than others; we have started with the really confusing and aggregious violations.
- Over the next year, We will offer different "levels" of Information Model conformance: the user can select (and the dashboard will reflect) the different levels. There will be multiple levels that range from the current low bar of just EDGAR Filing Manual Validation, to a very high bar of "strict" Information Model check that ensures 100% conformance with the U S GAAP Architecture.
To that end, here is the gist of the tests that are currently implemented:
-
Consistent Tables
-
Apparently, one of the most confusing aspects of the U S GAAP taxonomy is how tables work: These tests assure that that each presentation has a consistent set of [Table], [Axis], and [Line Items]. Furthermore, the presentation linkbase and the corresponding definition linkbase (i.e., hypercubes) should be aligned.
-
Presentation consistent with Calculation
-
This asserts that presentation
"totals" are backed up with a
corresponding calculation "total".
Conversely, calculation totals
should be represented somewhere as a
presentation total.
|
