BLOG: Digital Financial Reporting
This is a blog for information relating to digital financial reporting. This blog is basically my "lab notebook" for experimenting and learning about XBRL-based digital financial reporting. This is my brain storming platform. This is where I think out loud (i.e. publicly) about digital financial reporting. This information is for innovators and early adopters who are ushering in a new era of accounting, reporting, auditing, and analysis in a digital environment.
Much of the information contained in this blog is synthasized, summarized, condensed, better organized and articulated in my book XBRL for Dummies and in the chapters of Intelligent XBRL-based Digital Financial Reporting. If you have any questions, feel free to contact me.
Entries in SEC XBRL Logical Model (3)
Seeing the SEC Logical Model In Action
OK, building on the last post where I provided a high level summary of a logical model of SEC XBRL filings, here is an implementation of that logical model so you can better understand it:
- SEC XBRL filing and taxonomy prototype. This shows you what an SEC XBRL filing would look using only explicit tables, no implicit tables.
- Relations info set. This is an info set of the relations information. Basically, this is the information communicated within an XBRL taxonomy distilled down to its essence.
- Tables info set. This is an info set of the reported information. Basically, this is the information communicated within an XBRL instance, putting all the tables together with their axes, distilled down to its essence.
These info sets are not new, I copied them from the info sets I created for the Business Reporting Logical Model but, like the PDF in the last post, changed the terminology to match the US GAAP Taxonomy and SEC XBRL filing terminology.
To render the tables info set so that a human can read it, you use the tables info set plus the relations info set. To see this, try looking at the XBRL instance in the Firefox XBRL Viewer add on.
Summary of Logical Model of SEC XBRL Filing
Business users and software vendors will eventually realize that there is a logical model which the US GAAP Taxonomy and SEC XBRL filings follows. Exposing this logical model to business users hides the more complex and technical syntax of XBRL from those users. This blog post summarizes the logical model which exists for SEC XBRL filings, in my view and per the FASB US GAAP Taxonomy Architecture.
This PDF shows a visual representation of that logical model. This really should be in UML, but I don't know UML well enough to create that or I would.
This is a summary of much of the key terminology used in that logical model diagram:
- Networks. A network is a way to break an SEC XBRL financial filing into smaller pieces. There are two reasons why you might need to break a financial filing into pieces: because you want to or because you have to. The SEC Interactive Data viewer renders these networks in specific ways using the number and category of the network for ordering. Creating a network causes a section to appear within the navigation pane on the left hand side of the SEC XBRL previewer.I said that there were two reasons to create networks: because you want to create a section and because you have to create a section. The primary thing that a network does is it separates things which would otherwise collide.
- Tables. A table is used to combine things which go together. There are two types of tables: explicit tables and implicit tables. Tables are comprised of axis and line items, which we will discuss in a moment. The line items of a table have common axis. A table has one or more axis and line items. You can use a table from the US GAAP Taxonomy or you can define your own tables. This is done by creating a table, for example "Debt Instruments [Table]". There is another way you can create a table which is to use what amounts to a "default table". A default table is everything which exists in a network which is not in an explicit table. Explicit tables give you more explicit control over how things show up in the SEC Interactive Data viewer.
- Axis. An axis is a means of providing information about characteristics of the line items within a table, be that table explicitly defined or implicitly defined. Explicitly defined [Table]s are the only tables to which you can add axes. All tables, be they explicitly defined or implicitly defined, have two axis which will always be there: Entity and period. The entity axis, or entity identifier, always exists for an explicit or implicit table and the entity axis is always the SEC filer CIK number. The period axis, or reporting period, always exists for an explicit or implicit table. Other explicit axis which can be defined might include things such as:Class of common stock [Axis] or Subsequent event type [Axis].
- Domains. An axis always has exactly one domain. A domain is one of the possible values of an axis. A domain can have one of two meanings: total of the member or it may simply be a place holder. For example, say you have the axis "Regions [Axis]". That axis might have the domain "Regions, All [Domain]" which represents the total of all regions, the sum of all the members. Whereas, suppose you had the axis "Subsequent event types [Axis]". Subsequent events are never aggregated, but you would still need to provide a domain such as "Subsequent event types, all types [Domain]", although that domain would never actually be used within a report.
- Members. A domain may, or may not, have members. Members are the possible values of an axis also (the domain is also a possible value as stated above).
- Line items. Line items are concepts which can be reported by an entity, they can contain values. Line items is a special type of axis. Because line items can report values, they have data types such as string, number, etc. They may also have a balance type (debit or credit), a period type (as of a point in time, for some period, etc), and a few other characteristic which we will get into when we cover the details. Line items contain concepts. Concepts can be concrete meaning that they can be reported or abstract meaning that they are never reported, they are only used to organize the concepts contained within a set of line items.
- Information models. Concepts are not interspersed randomly, they have patterns. Said another way, concepts are organized into different information models. The common information models include: [Roll Forward], Roll up (often referred to as a calculation), Hierarchy, Adjustment, Grid.
- Financial integrity (business rules). Taking the notion that concepts are not randomly placed within a set of line items further than just the information model; certain information models have financial integrity. A balance sheet always has "Assets" and "Liabilities and Equity". A balance sheet always balances. The line items of Assets will always foot. The line items of "Liabilities and Equity" will always foot. These characteristics are expressed using business rules.
- Fact. Concepts are reported as facts whose characteristics are described with axis within an SEC XBRL filing. Facts have values, they have axis which describes its characteristics. Facts may be numeric or non-numeric. Numeric facts have an amount, non-numeric facts are made up of textual information. Facts are an intersection of axis and line items (remember that line items are a special type of axis) and a value. A fact is associated with a concept, they reference a concept within the set of line items. Facts are associated with axis, they reference a set of axis within an implicit or explicit table.
- Fact Value. Facts have a value which can be numeric or non-numeric. An important non-numeric value type is a narrative or [Text Block] which is a fragment of escaped XHTML.
- Fact attributes. If the fact is numeric, it has two attributes which describe additional information needed by numeric facts: units and decimals (rounding). Units provides information about this units of the numeric fact such as monetary, shares, or some other units. The decimals (rounding) provides information as to the number of decimal places to which the number is accurate, such as to the thousands, millions, billions, hundredths, etc.
- Footnotes. Facts may also have footnotes (comments, don't confuse this with notes to the financial statements) which provide addition information about the fact.
The graphic depicts what we will discussed, showing the relationships between the components. There are many different ways to depict this information, the most formal being UML (Uniform Modeling Language). UML is a standard way of depicting this information. However, we are using a less formal approach to articulating this information to make it easier for business readers to understand the relations. UML provides additional details, but is harder for business readers to understand.
Summary narrative of logical model
An SEC XBRL-based financial report can be logically broken down into sections. These sections are called tables. A table can be organized within a network. Networks organize where tables show up in software applications such as the SEC Interactive Data viewer application. There are three categories of networks: Document, Statement, and Disclosure. The numbers within the network names determine the ordering of the networks within software applications.
Tables are groupings of facts which appear in a financial report for some specific purpose. Facts within a table have similar characteristics. These characteristics are articulated using an axis. Line items are a special type of axis. Line items contain concepts. These concepts can contain values.
Axis cannot contain values, rather their values are the domain or the member. Axis always has a domain. A domain may be a total of all members or it may only be a placeholder and never used to report information. There are two special types of axis which do not have a domain: entity and period. Numeric values have two additional attributes: units and decimals. Units explains the units of a numeric value and decimals explains the rounding of a numeric value. Values may also have footnotes which provide additional information about a specific value or a set of values.
Facts reported do not have random relationships, the relationships between facts have patterns, this is referred to as an information model. A table may contain numeric concepts with information models such as roll ups, roll forwards, grid, adjustments, complex computations. Or if the numeric information has no relationship or textual information is reported, the information model is simply a hierarchy. Financial integrity takes these relations a step further and ensures the financial information within one table ticks, ties, foots and cross casts. Additionally, financial integrity ensures that one table properly relates to other tables.
For more detailed information and an example see my next post.
SEC XBRL Logical Model, Proof that Using XBRL Can Be Easier
I think that I have definitive proof that SEC XBRL can be made vastly easier than it is today. So what is the proof? OK, here you go:
- SEC XBRL Logical Model: The SEC has no real official logical model of the business semantics used in XBRL filings. But, that does not mean that a model cannot be created. In fact, anyone desiring to make XBRL easier for business uses to make use of will implement a logical model. Creating or extending XBRL taxonomies and building your SEC XBRL filings at the XBRL syntax level in your application? That is because your software vendor has not implemented a logical model.
- SEC Semantics and Business Reporting Logical Model Semantics Mapping to the XBRL Syntax: This is a mapping of the semantics of SEC XBRL filings (cross referenced to the Business Reporting Logical Model) to the XBRL syntax implemented by the SEC.
- Straw man Implementation of the Business Reporting Logical Model: This may be hard for people to grasp, but let me do my best to explain. This straw man implementation of the Business Reporting Logical Model basically implements the "stuff in the boxes" of that logical model. I made the straw man implementation work the way I would expect to work in my prototypes. The SEC XBRL Logical Model simply changes two things: the names of the boxes and the XBRL syntax used to implement it.
Truthfully, I don't know if most people will see what I am getting at here. I am going to go one final step. That step is to modify my hypercube viewer application (see the straw man implementation) and then run one or two of the better SEC XBRL filings (i.e. they are building [Table]s correctly) and see what it looks like in my hypercube viewer. I may not even need to modify the hypercube viewer.
The only problem with this is that now each vendor who implements a logical model to make XBRL easier for business users will do so in a proprietary manner because there is no global standard business reporting logical model yet. Well, it just may be that this is part of the evolution XBRL will need to go through.