Seeing Digital Financial Reporting Differently

Why does a butcher create a high level model of a pig?  Well, if you give the different cuts of pig meat a name, that enables a butcher to have a different conversation with customers than if the meat cuts did not have names.  Is there one global standard of pig meat cuts? Apparently not, a quick search of Google shows different graphics, but fairly similar. Cow meat cuts also have names, providing a higher level model of a cow that can be discussed.

The quick answer as to why there are names for the different cuts of meat of a pig, cow, and other animals is utility.  Those names provide something that you don't get if the names do not exist.

Conversations with others has revealed that I apparently, and uniquely, see XBRL-based digital financial reporting differently than others in four very specific and important ways.  Note that unlike many others; I am not trying to meet some regulatory mandate imposed by some regulator.  What I am trying to do is figure out how to employ XBRL-based digital financial reporting such that it is actually useful (i.e. BETTER, FASTER, CHEAPER).

Here are the five significant differences between my approach to XBRL-based reporting and the approach of others:
  1. Quality: To me quality is job one. That is the driving objective for all the other things that I do differently.  When others create a financial report they put "stuff" in the report and then they reach some sort of conclusion about whether that "stuff" is right.  They really have no logical basis for their conclusion.  When I work to verify financial report quality, I have a framework for doing so and I try and automate as much of the quality testing as I can.  (see point 4) I consciously create and provide a framework and proof of a report's quality.
  2. Complete: As part of my quality testing, I tend to like to be complete.  Every mathematical relation is consciously checked.  Not some, all.  Every high-level accounting relation is checked to be sure the report complies with those high-level associations.  I specify a complete logical schema, or as complete as automated software can get.  Then, everything else is checked manually.  This is a conscious process.  Why specify a complete logical schema?  Because then you understand the boundaries between what software can achieve and what you must do manually.
  3. Specify and Leverage High Level Logical Model: To achieve #1 and #2 above, I specify a high level logical model, a framework, that I can use for two things.  First, you can do more quality testing using that high level model because the model exists and is specified.  Second, when working with XBRL-based reports because of the high level logical model you can leverage that model in software, making using the software easier. To see this, read the Graph Hairball post.
  4. Leverage Lean Six Sigma Techniques, Principles, Philosophy: The focus of my MBA was what was referred to as World Class Manufacturing Techniques. Today that is called Lean Six Sigma.  Lean Six Sigma philosophy tend to work to prevent problems rather than fight the symptoms of problems.  Things should be done to consciously prevent mistakes from occurring.  This is as contrast to detecting mistakes and then fixing them or the failure cost of dealing with mistakes, both of which tend to be more expensive than simply fixing a system.
  5. Holistically: I look at the system holistically, not from the vantage point of one individual silo.
I took my approach XBRL-based digital financial reports, explained my approach, and gave that approach and framework a name.  I call it the Seattle Method.  I explained that approach to some people at OMG and they are using those ideas to create the Standard Business Report Model (SBRM).

To see what I do, consider having a look at my PROOF.  The raw material that shows the differences is there but not really explained.  Perhaps I will create a post that explains how to see what I am saying above.  Think "theory" and "proving the theory". That is in essence how PROLOG works.  In PROLOG you make a bunch of logical statements and PROLOG tells you if there are any contradictions.  A human has to figure out if there are missing logical statements such as missing rules.

Why do I seem to approach things differently?  Probably because I am a systems guy.  If you want to understand I would suggest the video A Theory of a System for Educators and Managers.

Additional Information: 

Comments

Post a Comment

Popular posts from this blog

Relational Knowledge Graph System (RKGS)

Image
Relational Knowledge Graph System (RKGS) is an interesting idea that combines the relational paradigm and the knowledge graph paradigm.  This documentation, Why RKGS , explains the idea. This gets even more interesting with the notion of "relational AI".  RelationalAI is described as follows by the company of the same name, Relational.ai : “RelationalAI is a cloud-based relational knowledge graph management system, with state of the art probabilistic processing and declarative reasoning at scale to make developing Data Applications a superpower for your business.” This notion of knowledge graphs represented in relational databases fits into my belief that knowledge graphs have two aspects: the expression SYNTAX and the logic of what is expressed or SEMANTICS. While the LOGIC of a knowledge graph is always the same regardless of technical syntax used to express that logic; there are many, many different technical syntaxes that can be used to represent a knowledge graph. There
Read more

Graph Hairball

Image
Knowledge graph system logic, the "things" and "relations between things" that  graph theory calls "vertices" (a.k.a. nodes, points, entities, things) and "edges" (a.k.a.  links, lines, relations, associations), looks like a big graph hairball as some people call it an example of which you can see here: Why?  This common view of a graph is because there has to be some "general view" of the information provided by the graph.  This is just like a general view of the information within a relational database is a table ; a set of ROWS and COLUMNS for exactly one table at a time. So what is interesting is that with a graph database the default view is everything in the graph of knowledge.  Whereas the default view of everything in a relational database is one table at a time. Further, it does not really matter whether the information that populates your knowledge graph comes from, say, CSV files, Excel, JSON, XBRL, RDF, PROLOG or whateve
Read more

PLATINUM Business Use Cases, Test Cases, Conformance Suite

Image
A brick wall is made of exactly two things: bricks, mortar. But a brick wall created by a master craftsman, or mason, and a brick wall created by a “weekend warrior” with no knowledge of masonry will be very different. Master craftsmen are created and that process takes time and effort. This blog post is a first prototype that brings several things together into one useful resource for business professionals.  It pulls together the human readable information of the Showcase of Reports   and the machine readable information of the Conformance Suite of XBRL-based Financial Reports Prepared using the Seattle Method .  Then, I want to incorporate the information found in these PLATINUM XBRL-based Financial Report Examples . The three resources can be useful and used independently; but they are even more useful when used together.  Business professionals really could not care a less about the technical details of getting some result that they want.  But technical professionals need to under
Read more