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.