Digital Financial Reporting

Complexity is the price business users pay for software developers not identifying and leveraging patterns when they create software.  Business professionals need to help software developers understand that these patterns exist and help them leverage these patterns in the software they create.  This is why professional accountants need to understand at least the basics of knowledge engineering in order to communicate this sort of information to software developers effectively. 

Business rule patterns is but one example of this phenomenon.  Software developers tend to build software so that applications are "more flexible" if they don't understand the requirements well.  This reduces the risk of software not working at all.  But this increased flexibility makes software applications harder to understand and therefore harder to use.  Flexibility where flexibility is not necessary is not a feature; it is a flaw.

Below is a business rules creation interface that I created using Microsoft Access.  I am using this to move from my old proprietary approach to articulating fundamental accounting concept relations impute and consistency rules to a new pure XBRL approach.

Here is ONE impute rule in the XBRL Formula syntax.  I will have one of these XBRL Formula linkbase files for every impute rule or consistency check rules in the set of fundamental accounting concepts.

Here are all the impute and consistency rules for one reporting style.  I used to create such rules by simply editing the XML files.  That might seem insane, but it helps one understand the XBRL Formula syntax very well.  But it gets old.

And so, I built a database, created a table to store the rules information, and then clicked a button in the database application and the XBRL Formula file, like the files above, are then all generated.  Here is that database table:

(Click image for larger view)

The table input format got old so I created an input form in the database to enter the rules.  Here is the Microsoft Access database form that I created:

(Click image for larger view)

The syntax for the actual XBRL Formula value assertion @test attribute is XPath 2.0.  One thing that XBRL did was as some people put it was "stand on the shoulders of giants".  That is why XBRL is seen as very funky by some people.  But that strategy is why XBRL leverages XML, XML Schema, XLink, XPath and other existing global standards provided by the W3C as opposed to re-inventing new standards.

How to use the XPath 2.0 syntax is well documented. It is also very powerful.  And that is why XBRL International leveraged XPath 2.0 syntax for the @test attribute.

While software developers might be comfortable with the XPath syntax, the average business professional will not be so comfortable.  And so, will business professionals need to rely on IT professionals to create business rules for them?  No.  First, that will never work because business rules need to be under the control of business professionals, not IT professionals.  See the Business Rules Manifesto.  Business professionals need to understand and control their rules and not rely on IT professionals.

So, how do you bridge that gap?  Force business professionals to understand XPath 2.0?  No.  The answer is to build better and smarter software.  Business rules have patterns.  I have identified 14 specific business rule patterns.  I have one additional pattern, "free form XPath 2.0".  Then, I built an interface that allows the user to edit business rules leveraging these known and common business rule patterns.

Here is an example of that interface: 

(Click image for larger view)

The result: business rules that are completely under the control of business users.  For the small percentage of business rules that do not fit one of the patterns, an IT professional can be called in to help the business professional if needed.

I put together a prototype for the XBRL US WIP/Surety taxonomy in which I created 42 business rules. Every one of those business rules fit into one of my patterns. I created a reference implementation for XBRL-based public company filings to the SEC, every one of the business rules fits into those patterns.  Same for the business rules of 75 reporting templates.

So, when you create business rules you do not need to understand the complex XPath 2.0 syntax or the XBRL Formula idiosyncrasies.  Patterns of the common business rules hide the complexity from the business professional.

But the most important thing to understand is that using XBRL Formula based business rules and an XBRL Formula processor or other mechanism to process the rules, you properly separate the business rules from software applications.  Hard coding business rules within software is not a good thing.  First of all, to change a rule you then require a software developer to code the rule. With XBRL Formula, no coding is involved.  Business professionals edit metadata.

Easier to use software and business rules under the control of business professionals is what is necessary to fix the ailing quality of XBRL-based public company financial filings to the U.S. SEC. This is whether the SEC requires or allows the XBRL Formulas to be submitted with a company's financial filings. Business rules are the only way to prove the XBRL-based information is expressed appropriately.

Patterns, frameworks, and theories help software engineers build better and easier to use software. Leverage patterns, frameworks, and theories.