Digital Financial Reporting

When creating a prototype I stumbled across something of interest which helps to show XBRL's ability to detect possible errors within a data set.  I am not saying that this is, or is not, an error.  But it does look like an error. I am trying to determine what is going on and am trying to find someone in the US Census Bureau who can help indicate what is going on.

So here is the deal.  The US Census Bureau makes summary financial information available for the US States. See the 2008 Annual Survey of State Government Finances here. More specifically, see under "Downloadable data" the summary table in Excel.  That is an Excel spreadsheet containing what amounts to an income statement for each US State, and an aggregation of the information for the total of the states in the column "United States".

I was using that data to create a demo and when I ran the XBRL validation against my data, I got some errors.  I will walk you through that in a moment.  But, here is an Excel spreadsheet which shows what could possibly be an error in the data.  If you don't have Excel, this graphic also shows the possible error.  What is going on is the line item "Insurance trust revenue" does not cross cast (i.e. the numbers for the individual states don't add up to the total in the United States column). That same discrepancy exists within Total revenue, of which "Insurance trust revenue" is part.

Now, I am not saying definitively that this is an error.  But, one of two things is going on.  (A) It could be an error or (B) the fact that the number does not add up like all the other columns is not documented within the data set.  It seems logical that others using this data might have the same question as I do given that all the other line items add up and given that it seems logical that everything should add up.

So why was I able to discover this?  Well, for my prototype, I was using that state financial information.  I created an XBRL taxonomy and in that XBRL taxonomy I created business rules which both document how things add up and allow me to verify that everything does in fact add up.  These business rules come in two forms. First, a set of XBRL calculations which show how the income statement adds up.  Here is a rendering which shows this.  Now, this is easier for a computer to read in the actual taxonomy. The result of running the XBRL instance information through the validation generates this report. That report shows first, how things add up and second the fact that the numbers do add up correctly in each of the 50 state income statements and in the total fur the United States as a whole.

The second test I ran is to use the fact that the 50 states do add up to the United States total, basically the relations shown here.  I created an XBRL Formula to express this relation, you can see that here but it looks rather ugly and I have not created a rendering of this. Computers can read business rules expressed in a global standard format and generate something like this, called a formula trace, this on generated by UBmatrix's XBRL processor.

This business rule generates this report which shows the descrepencies in the numbers. Now, you see four errors rather than two because I added two line items to the data set which calculated the net revenues over expenses and another concept showing the net Insurance trust activities.

Here is the bottom line.  I don't know if this is really an error or not, but the more important thing is that XBRL can document whether the numbers are supposed to add up and if the, in fact, do when the data is made available.  This report shows that the numbers foot. This report shows if the numbers crosscast (admittedly, this could be formatted nicer to make it more readable).  These reports are generated in off the shelf software.  The metadata communicating that the information adds up (or not) is made available with the information itself.  Here is the XBRL instance. Plug that into any off-the-shelf XBRL enabled tool and plug the XBRL formula in, and you will get the same result (the software does have to support XBRL Formula of course, many do).  That is right, not only can you validate the information, but the validation is portable between business software applications!

You can still get the data and read it, just like the US Census Bureau provides in in Excel.  This tool can be used to extract information using a very simple Excel macro. No XBRL processor was used, but that would make writing the already easy to write code (I wrote it, I am a CPA not a programmer) even easier.  (Note that there are a number of different formats you can extract the data from, find the tab "Financial - XBRL".)

Business rules are critical to creating quality XBRL.  They are not sufficient, but they are necessary.  And creating quality XBRL is important.  Consider the article X Marks the spot, for Errors published by CFO.com which says:

Early results indicate that filing financial statements in XBRL is far from simple.

Well, I see this slightly differently.  XBRL actually can be quite simple, if you understand the process (i.e. what the process is) and have good software to help you through that process and supports that process.

Today, most people don't seem to understand that process and software does not support that process in a workflow which is very helpful to business users.  I think that this is just part of the normal evolution which XBRL has to go through.

So, what is the process?  Well, I have a little work in progress which will eventually be articulated in a blog post.  You can see what I have so far at this URL. I will explain this in more of a narrative form later, but fur now if you choose to, you can figure out the entire process.  There are plenty of examples.

But the focus here is business rules and the role they play in the validation process. This is number 3 on the list above.

Business rules are expressed in XBRL using XBRL Formula. People have been discussing the need for XBRL Formula since the beginning of XBRL.  Over the years there have been proprietary versions of XBRL Formula and even some prototype implementations.  But now XBRL Formula is a global standard.

But, XBRL Formula and the business rules you can create with XBRL Formula is not used extensively in many XBRL taxonomies as of yet.  For example, the US GAAP Taxonomy does not provide business rules, yet anyway.  But, you do need them because whether you realize it or not, you have computations which XBRL calculations cannot handle.

For example, take a look at and consider the Movement in Property, Plant and Equipment [Roll Forward]in the US GAAP Taxonomy. This reconciles the beginning balance, the period increase or decrease to the ending balance of Property, Plant and Equipment.  The reason XBRL calculations cannot validate this computation is because XBRL calculations only work if every concept participating in a calculation is in the exact same context.  With a roll forward, you have three different contexts as each concept in the computation is in a different period.  Thus, you need XBRL Formulas to express this business rule.

I forget the number of [Roll Forward]s which exist in the US GAAP Taxonomy, but it is a substantial number as these types of reconciliations are common in financial reporting.  There are other types of computations which XBRL calculations will not handle, the [Roll Forward] is only one example to make the point.

You can see a more specific example of a roll forward (another term for roll forward is movement analysis) here in this set of examples.  Look at number 4.  Here is a PDF rendering of a simple movement (or roll forward) example in PDF, in the XBRL instance, the XBRL Formula, and the detailed validation output.

The XBRL Formulas looks complex, but because, for example, the US GAAP Taxonomy has a consistent way to express the information model for a [Roll Forward], a software developer can actually automate the process of creating a formula for every [Roll Forward] in the US GAAP Taxonomy.

There really is no reason to have to verify computations like these manually, computers are much more accurate than humans.  XBRL US will likely provide XBRL Formulas for every [Roll Forward].  Until they do, you still need to verify your computations.  You really don't want to show up with this type of error in something like XBRL Cloud's list SEC filer errors now would you.

Further, people have been talking about using business rules to automate as much of a financial statement disclosure checklist as possible for years.  Thing like "If you have the line item 'Property, Plant, and Equipment, Net' on your balance sheet, then you must have...."  You get the idea.  These types of "if-then" statements are quite easy for an automated process to check.  You will never be able to automate the detection of every possible error, but you can leverage XBRL to both improve the quality of what you do today, and you certainly can reduce the cost of getting to that quality level.

Business rules will even become more powerful as taxonomies become more like ontologies.  But that story is for another blog post.  Stay tuned for details!

My blog has a page which is dedicated to business rules.  What this post and the next several posts does is help business users understand what business rules are and why they are important.  I am in the process of updating the XBRL Formulas information from the candidate recommendation (CR4) to the actual released version of XBRL Formulas.  This will be done over the next several weeks.

The ability to express business rules is probably the single most powerful feature of XBRL (other than the fundamental ability to express business information in a standard structured format).

The term "business rules" can be defined in many ways. A good resource for understanding exactly what business rules are is the Business Rules Group.  You can see this URL for more information.

There really is no standard definition for what a business rule is.  Here are some definitions which others use to help you get a sense for what business rules are:

• A formal statement that defines or constrains some aspect of a business that is intended to assert business structure, or to control or otherwise influence the behavior of the business
• A way of expressing the business meaning (semantics) of a set of information
• A formal and implementable expression of some business user requirement
• The practices, processes, and policies by which an organization conducts its business

Business rules exist in the form of relationships between pieces of business information. Some examples can help you better understand exactly what they are:

• Assertions: For example asserting that the balance sheet balances or Assets = Liabilities + Equity.
• Computations: For example, calculating things, such as Total Property, Plant and Equipment = Land + Buildings + Fixtures + IT Equipment + Other Property, Plant, and Equipment.
• Process-oriented rules:  For example, the disclosure checklist commonly used to create a financial statement which might have a rule, "If Property, Plant, and Equipment exists, then a Property, Plant and Equipment policies and disclosures must exist."
• Regulations: Another type of rule is a regulation which must be complied with, such as "The following is the set of ten things that must be reported if you have Property, Plant and Equipment on your balance sheet: deprecation method by class, useful life by class, amount under capital leases by class . . ." and so on.  Many people refer to these as reportability rules.
• Instructions or documentation: Rules can document relations or provide instructions, such as "Cash flow types must be either operating, financing, or investing."

Today, it is quite common that business rules are application specific.  But what if business rules were not locked into a specific software application? What if these rules could be exchanged along with the information.  That is the power of business rules.  What the exchange of business rules allows is the efficient and effective automation of information exchange across business systems.

If you have ever received an Excel spreadsheet from someone and had to rely on the information in that spreadsheet for something important but you really were not sure about all those cell formulas in the spreadsheet you will understand what I mean.  Imagine if you could have insight into all those formulas in your terms, rather than rely on formulas provided by the spreadsheet creator.

More to come...

If you believe that XBRL provides benefits only to consumers of business information and the the creators of business information gain nothing from its use, think again.  One way to see the benefits of XBRL to users is to look at business rules.  A good source of information about business rules is the Business Rules Group, particularly their Business Rules Manifesto.

Business rules are commonly defined as:

A formal and implementable expression of some user requirement.

Business rules are implemented in XBRL using XBRL Formulas.  XBRL Formulas became a recommendation just a few weeks ago, but has been around and on the minds of the creators of XBRL from its inception.

If you don't understand what business rules are, you cannot possibly understand XBRL or its true value to both creators and consumers of business information.  Business rules benefit business information which is expressed and the processes used to express business information.

While the XBRL taxonomies such as the IFRS and US GAAP do not provide business rules with the taxonomies today, you will definitely see them in the future.

If you don't understand business rules, a good place to start is by reading that Business Rules Manifesto.  It will give you a good sense for what business rules are and what benefits they provide.