Digital Financial Reporting

To better help business professionals understand the fundamental accounting concepts, I have created a Crash Course in the Fundamental Accounting Concepts:

Pretty self explanatory.

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.

As I have mentioned, the machine-readable fundamental accounting concept relations metadata had some deficiencies:

• Some metadata was not in an XBRL format
• Flexibility was not as good as it could be
• Maintenance was harder than it needed to be

And so, I created a pure XBRL working prototype of the fundamental accounting concepts metadata. The prototype metadata loads into XBRL software (i.e. is pure global standard XBRL), the metadata is significantly more flexible, and maintenance is significantly easier.

There is one insignificant validation issue which does not cause any processing problems, but it does cause a number of the XBRL processors I use to throw errors.  The issue is that I am loading two different versions of the US GAAP XBRL Taxonomy to get the mapping information that I want and the FASB creates new extended link roles each year but uses the same URIs.  I don't need two versions of the US GAAP XBRL Taxonomy going forward, so this error will go away when I update the mapping information over the next couple of months.

While I generated all of the report frames, or reporting styles, I only configured rules for one of those reporting styles at this point and I did not represent all the rules yet.  I want to check to see if everything is working correctly before I go hog-wild and do a bunch of work that I will ultimately need to fix.  So, I will use this partial implementation of one report frame, COMID-BSC-CF1-ISM-IEMIB-OILY-SPEC6; although that report frame is used by 2,174 or about 32% of all public companies reporting to the SEC using XBRL.

Here is the information you need to understand:

• Here is an XBRL instance that will load into XBRL processing software.  This is only used for testig the rules.  I tested this using XBRL Cloud's XBRL processor and XBRL Formula processor, the UBmatrix XPE XBRL processor and XBRL Formula processor, and the open source Arelle XBRL processor and XBRL formula processor. (I also loaded this into another XBRL processor and XBRL formual processor that I cannot tell you about yet; that also has a graphical user interface.)
• This is what the information that I am interested in validating for correctness looks like (below). This information was extracted from an XBRL-based public company financial report that I want to make sure is consistent with the basic, common sense, fundamental accounting concept relations. You can see those relations:

• In the OLD version of the metadata there were TWO problems.  First, all the rules were in ONE FILE. Second, the syntax of that file (click on the link) is not specified anywhere.
• I fixed this problem by doing two things.  First, I put each rule into a separate file. Here is rule 1, rule 2, rule 3, rule 4. You get the idea. Second, I changed to the XBRL Formula syntax for representing the rules.  While you might not like that syntax, it is a global standard; plus it is flexible, powerful, and does work.
• All the files that a specific reporting style are links to rules, not different versions of the same rule.  The schema links the rules together for a reporting style.
• Here is the schema for the one reporting style that I have partially created.
• Another thing that I am doing is making it so someone can work with a network independent from an entire set of networks that make up a reporting style (report frame code).  Besides, this is a way of easing away from physical report frame codes altogether.  A smart programmer can figure out the reporting style by testing which set of networks a public company uses.  This could take some time for people to figure out, so until then I will provide BOTH options.
• Finally, while I did provide a mapping file for the prototype; like I said the current mapping references two US GAAP XBRL Taxonomies (which I don't want to do and don't need to do now) and the mappings relate to an entire reporting style rather than just a network.  And so, what I want to do is provide mappings on a per-network basis in addition to by reporting style.

Execute the XBRL Formula-based business rules, here are the results.  And guess what, you get XBRL calculation relations also, see those here and here (two different software products).

And this means that all the metadata that I have can be represented using the XBRL global standard.  That includes XBRL Formula based metadata and XBRL definition relations based metadata.

Some people like to bash the XBRL Formula syntax as being too complicated or hard to understand.  Well, that syntax is not really a problem.  The problem is a lack of imagination of software vendors creating products business professionals can make use of.  This is an interface I created:

(Click image for larger view)

I don't show this as a stellar interface, that is only a working prototype.  I show it to demonstrate that you don't need to work directly with the XBRL Formula syntax or a syntax-focused tool.  A semantic layer makes it so business professionals never have to deal with XBRL Formula.

If you still don't understand why machine-readable business rules are important, go back and read this blog post.  Machine-readable metadata is important in our digital age.  Global standard XBRL based metadata seems like a great format to me.  If not XBRL, then what?  Python?  Really.  We will see how that works out.

Now, the decision as to which machine-readable metadata format is independent of the processor which might be used to make use of that metadata.  While what these processors can do is easy to understand, understanding the most appropriate way to implement such processors can be more challenging.  But I will cover this topic in another blog post.  So stay tuned.