Digital Financial Reporting

In their 2003 article Business rules validation - the standard the W3C forgot, Paul Warren, Gareth Reakes, and Alberto Massari point out that the W3C forgot something in the XML stack:  semantic validation.

Many business people and technical people tend to miss the importance of business rules or seem to fall back into old ways of thinking about business rules and how to enforce those rules and keep their information accurate.

Part of the reason for this is that may people confuse syntactic and semantic validation.  I know that I did.  In fact, it took me about six months to be able to use the two terms correctly.  I kept confusing the terms, not knowing which was which.

I am not going to go into the difference between syntax and semantics here.  There are plenty of places to dig into this.  The article pointed out above goes into this quite well, but it may not be understandable by a business reader.  But business reader:  it is important to gain an understanding of the differences.

I will point out a few examples of business rules before I get to the real points which I want to make.  Here are some examples of business rules:

• Assets = Liabilities + Equity (i.e. the balance sheet balances)
• The invoice total equals to sum of the invoice line item amounts.
• If you report Property, Plant and Equipment on your balance sheet, you need to provide some specific policies and disclosures relating to that line item.

Business people care deeply about these sorts of things.  Basically, business rules enforce the integrity of information.  They also care about costs and functionallity.

So what points do I want to make?

First, I wanted to reiterate what the article above states which is that XML does not have them.  Can they be created for XML?  Sure they can.  XBRL created business rules (XBRL Formulas).  Many business people and  even technical people don't realize that XML cannot articulate semantic meaning (i.e. business rules), thus the article above and why people tend to not understand the value of XBRL (i.e. it can articulate semantic meaning).  For XML to provide business rules, all that needs to happen is that either the W3C or someone create a process for expressing semantic meaning generally for XML, or each seperate XML implementation creates it on rules.

That is the second point.  Many people just assume that this is part of the deal and go ahead and build the business rules within their application.  What does that cause?  Well, it causes work (i.e. actually implementing that) and it makes it so the business rules cannot be exchanged between two applications.  If this approach is taken, business rules have to be created in two systems:  the system which generates the information and the system which consumes the information.  However, if the rules are expressed using XBRL you get two things.  First, you get much less expensive and more powerful validators.  Second, you can exchange the business rules along with the information which is being exchanged.

The third point relates to this second point.  XBRL Formulas has been discussed since about 2000 in the XBRL community.  There have been some prototype versions of business rules created by members of XBRL International.  The first prototype version was created by KPMG (David vun Kannon and Yufei Wang) for XBRL 1.0.  Many vendors have created their own proprietary versions of business rules, such as my employer UBmatrix whose proprietary business rules validation which is currently being used by the FDIC as we (UBmatrix and the FDIC) wait for the XBRL International specification.

Finally after years and years of work, XBRL Formulas 1.0 is in its second candidate recommendation.  A good size group has struggled to create this global standard specification for creating business rules, such an endeavor is not an easy task.

However, the benefits are substantial:

• There is a global standard way to express business rules.
• There is a global standard way of exchanging such rules.
• The business rules can be created separate from applications.
• One-to-one validation mechanisms are more expensive and generally less functional than rules engines which provide better leverage.
• XBRL validators (i.e. rules engines) are much cheaper and far more functional because there are more users across which the validation engine can be shared thus reducing the cost per user.
• You can validate semantic meaning when you exchange information.
• If XBRL validation does not meet 100% of your needs then sure, create that piece using whatever proprietary mechanism you may need to use.  But, XBRL Formulas provides a lot to leverage.

I will conclude this post by saying thank you to all those who have struggled long and hard to get XBRL Formulas where it is.  Your efforts are very much appreciated.  And thank you to XBRL International members who sometimes did not agree how to best create this global specification, but somehow managed to work through differences, eventually agree on something, and get business rules into the hands of us business users.  Cheers!