Digital Financial Reporting

This blog post pulls together into one place the information necessary to understand the framework and architecture that I use to create high-quality, high-fidelity, high-resolution XBRL-based financial reports.  These same ideas can be applied to general business reports, what I call fact ledgers, accounting process automation, AI assisted audits, etc.

It is true that right now, this information is not particularly well organized.  The reason for that is that I documented a lot of this as I was creating it.  The lab notes that I created where periodically summarized and synthesized into a set of documents.  I will go back and reorganize all of this at some point.  This blog post pulls the most important information into one place.

So WHY did I create what I created?  People have visions of "mirror worlds", "the finance factory", "financial transformation and the modern finance platform", "digital transformation", "continuous accounting", I could go on and on and on.  But all of this things are just visions.  How do you actually turn those visions into reality?

That is why I created what I created, to implement those visions.  WHAT I created is a best practices-based, global standards-based, and open source tool for implementing that vision for accounting, reporting, auditing, and analysis.  I am conscious of what it takes to make such a tool work effectively; this important information related to artificial intelligence and knowledge engineering. (Computer Empathy is an older version of that same information that has a little more detail in some areas.)

This global standards-based and open source tool was created using the engineering design process. Steps to create it were conscious, deliberate, and rigorous.  Brick by brick, the pieces were put together.

One of the primary requirements is that the tool had to deliver high-quality, high-resolution machine-understandable information related to accounting, reporting, auditing, and analysis.  Quality is paramount. The flexibility/variability inherent in this process has to be managed and controlled effectively so that quality remains high and reliable automated processes can be created.

Working top down, here is the most important information that is useful in understanding the approach that I am using to implement XBRL-based digital financial reporting:

• Example Implementation: This is an example implementation of a financial reporting scheme, FRF for SMEs, using this tool.  It helps you see the end result. (Note the bottom of the HOME page for example reports. Here are examples for five different financial reporting schemes. Here are some inline XBRL examples.)
• Framework and Theory: This is the framework and theory that was used to create the tool.
• Method: Included in that framework and theory is the method I used to create the example implementation.
• Technical Description of Framework: This document provides a technical description of the open source framework that is used to implement this tool for accounting, reporting, auditing, and analysis.
• Accounting, Reporting, Auditing, and Analysis Application Profile: This document provides documentation of the XBRL application profile that is used to implement the technical framework.  The XBRL application profile documents the restrictions imposed on the XBRL technical syntax use and approaches to using XBRL when alternatives exist.
• XBRL Technical Specifications: All of the above is built on top of and 100% consistent with the global standard XBRL technical specifications.  This includes XBRL 2.1, XBRL Dimensions, XBRL Formula, Inline XBRL, the XBRL Link Role Registry, and other supporting specifications.

Again, I am well aware that the organization of this information is not yet optimal. But this is what I currently have.  Over time I will further distill, organize, summarize, and synthesized this information such that it is more useful.  But, for now, this imperfect documentation gets the job done.  Now that I have the right software tools, I can create the correct documentation.

I have implementations that prove this approach in US GAAP, IFRS, XASB (a reporting scheme I created for testing purposes), IPSAS, and FRF for SMEs.  All of these implementations use exactly the same application profile.

All of what I have created can best be described as informally documenting a business report model.  But this is in the process of being formally documented.  What I have created will be “tuned” to adjust to the forthcoming OMG Standard Business Reporting Model (SBRM).  SBRM will formally document a logical conceptualization of a business report in both human-readable and machine-readable models.  I participated in creation of the SBRM RFP and I am on a team that is responding to that RFP.

There are now four software vendors that are consciously supporting my framework and architecture that I am aware of.   There could be more, I don't know. This does not count the software vendors that support SBRM in the OMG working group.

• Pessearct is a working proof of concept that a software engineer and I have created to test and prove this framework and architecture.  Pesseract is 100% consistent with this architecture, supports all five reporting schemes, and is an incredibly robust and useful application which is being used by some in the process of creating XBRL-based reports that are submitted to the SEC.  We are working to turn Pesseract into one or more commercial products.  Pesseract is free to download and use for noncommercial purposes.
• XBRL Cloud is about 98% consistent with this framework and architecture in terms of precision and completeness.  XBRL Cloud supports three of the five reporting  schemes that I have created and two of the reporting schemes, US GAAP and IFRS, are used to verify the quality of XBRL-based financial reports submitted to the SEC by public companies.  XBRL Cloud performs all the validation and processing for my quarterly quality measurements of XBRL-based financial reports submitted to the SEC.
• XBRL Query has been supporting this framework and architecture for about 9 months. If nothing else, this framework has contributed to the tuning of this high-quality open source XBRL processor.
• Lodgeit cut their teeth on XBRL in the Australia SBR project.  They totally get the vision and have contributed to my thinking in many ways. That is all I will say for now.
  

Three of the four above implementations support the common conformance suite provided for this framework.  The renderings of the pieces of a financial report are all very consistent and so the model of a business report looks literally identical in all three software applications.

This framework and architecture is based on the model of XBRL-based reports, both US GAAP and IFRS, that are submitted to the SEC.  As such, 100% of those creating XBRL-based financial reports for public companies COULD be consistent with all of this framework, but because they cannot process the framework rules they have to check their business report logic manually rather than using automated processes.  But, all of the approximately 20 software vendors are already consistent with most of this framework and architecture.

To be crystal clear here.  A best practice is a method or technique that has been generally accepted as superior to any alternatives because it produces results that are superior to those achieved by other means or because it has become a standard way of doing things.  This framework and architecture is about ONLY letting user use best practices and leveraging those best practices to create high-fidelity, high-resolution XBRL-based financial reports that are also high-quality.  No magic; conscious attention to detail; good engineering.

Theoretical, philosophical, or religious debates have no role in determining the best way to implement XBRL-based digital financial reports.  This is an engineering exercise.

In her book An Introduction to Ontology Engineering (PDF page 23), C. Maria Keet, PhD, provides discussion about what constitutes a good and perhaps a not-so-good ontology.  There are three categories of errors she discusses:

• Syntax errors: She discusses the notion that a syntax error in an ontology is similar to computer code not being able to compile.  For example, when an XBRL processor tells you that your XBRL taxonomy is not valid per the XBRL technical specification.
• Logic errors: She discusses the notion of logical errors within an ontology-like thing which cause the ontology to not work as expected.  For example, if you represented something in your XBRL taxonomy as a credit when it should have been a debit.
• Precision and coverage errors: Finally, Keet discusses the notions of precision and coverage when it comes to judging whether an ontology or ontology-like thing is good or bad and provides a set of four graphics that drive this point.  Precision can be low or high; coverage can likewise be low or high. For example, when you neglect to represent a rule and therefore something that should not be permissible is permissible because you neglected to include that rule. The fundamental accounting concept relations quality issues result from precision/coverage errors. (Others apparently call this "precision and recall". But I think that term is related to machine learning or pattern-based systems.  I am more focused on rules-based systems. In first-order logic they seem to use the terms "sound, complete, and effective".)

You get a good ontology when the precision of the ontology is high and the coverage of the ontology is high.  Precision is a measure of how precisely you do or can represent the information of a domain within an ontology-like thing as contrast to reality.   Coverage is a measure of how well you do or can represent a domain of information within an ontology-like thing.

The graphic shown below helps you visualize the notions of precision and coverage.  The "universe" (also called the universe of discourse or simply domain) is shown in light gray. The pink indicates the set of what you represented in your ontology-like thing. The green indicates what could possibly be represented using the language you are using (i.e. determined by where the language you are using sits in the ontology spectrum).

If you represent the things that you should represent (i.e. your coverage is good) and you do so such that the ontology-like thing accurately represents reality, then you get a good ontology-like thing.  But if an ontology-like thing cannot do what it should be able to do then it is a bad ontology-like thing.  And things can go wrong when you have high precision but not enough coverage or if you have low precision with high coverage or things can become really bad if neither your precision nor coverage are what you should have created given the goal you are trying to achieve.

And so, precision and coverage matter when it comes to creating an ontology-like thing.  Representing information in machine-understandable for is not something that just happens.  It is a lot of work.  Balancing the objective you are trying to achieve, the language that you use, what you put into your ontology-like thing, and how well your ontology-like thing represents your universe impacts how well your system will work.

"In order to formalize a language, there must be a specification of the signs and symbols of the formal language, as well as a specification of the permissible manipulations of the symbols."

• Constant 
• Variable 
• Operations or Functions
• Predicates
• Logical Symbols
  • Connectors
    • Implication
    • Disjunction (or)
    • Conjunction (and)
    • Negation (not)
    • Logical equivalence (if and only if)
  • Qualifiers
    • There exists (existential)
    • For all (universal)
• Punctuation marks (left and right parentheses; comma)

I think I am trying to say the same sort of thing in my enhanced description of an ontology-like thing.  I pointed out the need for four things:

In my view, the signs, symbols, and formal language of a financial reporting scheme should be as high as possible.  Perhaps a sub-language is necessary to document the higher level language that you use; but I believe the stuff used in the “alphabet” should be used to define things like (I am thinking about the FRF for SMEs reporting scheme elements of a financial report which include things like: assets, liabilities, equity, revenues, expenses, gains, losses, net income, net cash flow, investments by owners, distributions to owners.)

You also need to define other logical terms such as:

• roll up (a + b + c + n = total)
• roll forward (beginning balance + changes = ending balance)
• adjustment (originally stated balance + adjustments = restated balance)
• set

Then, you also need to define permissable logical relations between terms (i.e. if you do not define what is permissable, then ANYTHING is essentially permissable).  These fundamental relations are permissable:

• assets = liabilities + equity (statement of financial position i.e. balance sheet)
• net income = income from operating activities + income from peripheral and incidental activities (statement of operations i.e. income statement)
• beginning equity + net income + investments by owners, distributions to owners = ending equity (statement of changes in equity)
• beginning cash and cash equivalents + net cash flow = ending cash and cash equivalents (statement of cash flow)
• net cash flow = net cash flow from operating activities + net cash flow from investing activities + net cash flow from financing activities

Because some additional terms were used in the definitions of the rules above, you also need to define those terms so that they can be used within the rules of permissable relations:

• cash and cash equivalents
• income from operating activities, note that income from operating activities = revenues – expenses
• income from peripheral and incidental activities, note that income from peripheral and incidental activities = gains – losses

And finally, for my needs, I want to go one level deeper in a few areas of those elements of a financial report and so I also define these terms which are either defined or implied per the FRF for SMEs conceptual framework:

• current assets
• current liabilities
• noncurrent assets (implied by definitions of “assets” and “current assets”)
• noncurrent liabilities (implied by definition of “liabilities” and “current liabilities”)
• equity in noncontrolling interest
• equity in controlling interest (implied by definition of “equity in noncontrolling interest and “equity”)

So that would be my definition of the high-level conceptual framework of the FRF for SMEs reporting scheme.  I have formally defined this financial reporting scheme using the language/syntax XBRL.  Here are those artifacts:

• Human readable version
• Terms (XBRL taxonomy schema which references labels to make the terms more approachable by humans and references to authoritative literature)
• Rules (XBRL formula)
• Facts (XBRL instance which pulls everything together; this is the same thing using Inline XBRL; this is what I wish the inline XBRL would look like; notice you can click on facts or report elements to get details; here are the raw fact tables; and here are the business rules in a separate summary)

Luca Pacioli documented the double-entry accounting model. That model is based on mathematics and mathematics is based on logic.  Don’t think of what I am trying to do as “document what the FASB or IASB or GASB or IPSASB had created” per some financial reporting scheme.

What I am doing is different.  It is my observation that the standard setters are leaving out important information out which makes the standards “open to interpretation” where they really should NOT be open to interpretation.  Essentially, the documentation the standards setters are creating in books have gaps.  They do not have the precision and coverage as is described in C. Maria Keet’s book An Introduction to Ontology Engineering. Precision is a measure of how precisely you do or can represent the information of a domain within an ontology-like thing as contrast to reality.   Coverage is a measure of how well you do or can represent a domain of information within an ontology-like thing.

Or, saying this another way, I am using (a) the conceptual framework defined plus (b) empirical evidence that exists and (c) professional judgement to create an interpretation, a best practice interpretation, that is “precise” and has full “coverage” and proving that model mathematically and logically. 

For what financial accounting need to deliver to business, we must have a system that is provably sound and clear.  The institution of accountancy is built on the framework and theory created by logic and mathematics of double-entry accounting first developed by a Florence bank in 1211 AD and documented by mathematician and Franciscan friar Luca Pacioli in 1494 AD.

Introducing politics or philosophy or religion into the logic and mathematics of how an accounting system operates is not appropriate.  This is not to say that it is wrong to use politics to decide what goes into some financial reporting scheme.  What goes into some financial reporting scheme should be driven by what the users of that financial reporting scheme was created for; its fundamental purpose.

HOWEVER, politicians, regulators, standards setters, and others cannot simply mess with the logic and mathematics of financial reporting.  Those rules are above their pay grade.  Those rules are driven by nature and can be observed and documented but the rules of math and logic cannot simply be changed on a whim.

=======================

Financial reporting comparability: toward an XBRL ontology of the FASB/IFRS conceptual framework

I have pretty much proven the conceptual model of a financial report bottom up.  Now I am going to also prove it top down.  What this achieves is enabling me to simplify the model and allowing only best practices proven by empirical evidence.

Financial reporting schemes are important, therefore they should be elegant to look at and easy to use.  The accounting equation is a simple, elegant, and very useful and proven tool.  Every financial reporting scheme builds on that rock-solid foundation.  But when basic relations and terminology are vague, ambiguous, or otherwise unclear then financial reports can end up being convoluted messes that are not useful.  In order for professional accountants to exercise good professional judgement accounting and reporting standards should be crystal clear.  Today, standards setters do a pretty good job, but there is room for improvement.

How do I know there is room for improvement?  Read on.

There are many different financial reporting schemes, for example: US GAAP, IFRS, FRF for SMEs, IPSAS, GAS.  Here is a list of financial reporting schemes.  Comparing and contrasting these is interesting and helps one tune my skills as a master craftsmen.

Each financial reporting scheme has a conceptual framework.  Here are the conceptual frameworks for the following financial reporting schemes: US GAAP; IFRS; FRF for SMEs; IPSAS; GAS.

I compared the high-level financial report elements for those five financial reporting schemes.  They are mostly the same in terms of the elements that they define.  But there are some differences.  Now, the definitions of the elements tend to be different even if the name of the element is different.

So, for example, here are the financial report elements defined by FRF for SMEs (to understand more about FRF for SMEs see here) either explicitly or implicitly within the definition of another element: (for specifics see here)

• Net Income
• Investments by Owners
• Distributions to Owners
• Assets
• Liabilities
• Equity
• Revenues
• Expenses
• Gains
• Losses

For quick reference, here are screen shots of the high-level elements of each of these five reporting schemes:

• US GAAP (or see pages 24–133 of the free PDF above); here is documentation from an intermediate accounting textbook.
• IFRS (or see page 2 of PDF above);
• FRF for SMEs (see page 21 in the free PDF above);
• IPSAS (or see page 15 in the PDF above but you have to register);
• GAS (see page 3 in the free PDF)

Now, at the very highest level, all financial reporting schemes are fundamentally the same and use the accounting equation: Assets = Liabilities and Equity. (If you don't understand this, watch this video.)

Financial reporting schemes are fundamentally based on the accounting equation and double entry bookkeeping which was invented in about 1211 and documented in 1496.

So why is any of this important? First, it is important to understand that the elements of a financial report are interrelated.  You cannot change any one single number and expect the report to "tick and tie" and "cross cast and foot".  There are roll up and roll forward relations that tie all the report pieces together.

Unmodified CORE-00: I represented the high-level financial report elements of FRF for SMEs in XBRL without modifying the concepts, I call CORE-00. Here are the high-level concepts of FRF for SMEs. That is just a flat list of the report elements. (Raw XBRL | Inline XBRL | Human Readable)

Enhanced CORE-01: But, I want to represent all of the relations.  To do that, I had to enhance the FRF for SMEs high-level elements, adding two elements: Liabilities and Equity and Net Cash Flow.  I am not sure why FRF for SMEs did not define net cash flow. In fact, the only reporting scheme which defines Net Cash Flow as a high-level element is IPSAS. Here are the now 12 high-level elements.  And here are the balance sheet, income statement, cash flow statement, and changes in equity. (You can browse around and have a look at what you want using this link.) (Raw XBRL | Inline XBRL | Human Readable)

Now, don't be pedantic and miss the point. We are looking at the bigger picture here folks!  The point is (a) that there are mathematical relations that inter-related all of the four reports and (b) all my mathematical computations work as was expected.  You can see the relations by looking at the report, but here is a separate summary of all those mathematical relations.  Yes, I agree that it barely looks like a set of financial statements.

Further Enhanced CORE-02: So, I don't exactly know how the FASB, IASB, GASB, IPSASB, or other standards setter determines where "high-level elements" end and "lower-level elements" begin.  But, for what I am trying to do, I need just a little more detail.  And so, I added a few more elements so the total is now up to 23.  But I don't think that anyone would dispute any of these additional 11 concepts that I added.  Here is a list of my further enhanced core elements of a financial report. Note that the statements are looking more like a financial report:  Balance sheet, income statement, cash flow statement, changes in equity. Again, you can browse all the pieces here and you can look at the mathematical relations here. (Raw XBRL | Inline XBRL | Human Readable)

Accounting Equation (Very basic example): XBRL instance | Human Readable

Conceptual Framework (Enhanced example): XBRL instance | Human Readable | Taxonomy | Assertions

BOTTOM LINE: And so I can keep doing what I am doing until I create 100% of the disclosures that would be created when reporting under FRF for SMEs (which I am actually doing) and as I am doing that, I am proving that all of the expected relations are is as expected.  Further, if this works for FRF for SMEs, then why in the world would it not also work for US GAAP, IFRS, IPSAS, GAS, or any other financial reporting scheme?

Why are getting reports right so critical?  Well, if the reports do not fundamentally work correctly than what value do XBRL-based digital financial reports have to anyone?  The SEC mandating public companies to provide XBRL-based financial reports is one thing.  If they don't work correctly and/or don't provide benefits to the report creators, why waste your time with XBRL-based reports?  Sure, those mandated to provide the reports will jump through the required hoops they need to jump through for a regulator; but no one else will use them.

Secondly, by understanding the high-level model one can then create software that takes advantage of that model and makes the entire process of creating such reports easier for professional accountants.

INTERESTING OBSERVATION: Finally, I have an interesting observation.  When you (a) look through the conceptual frameworks created by standards setters and more importantly (b) compare the different conceptual frameworks created by different standards setters you start to really see the many, many inconsistencies, flaws, poor organization, and other such issues in these important financial reporting schemes.

Sorting through these important accounting standards is not about professional judgement.  Many accountants think that they are exercising judgment when working through the inconsistencies and flaws.  But that is not exercising judgement.  Exercising judgement is about understanding the real and clearly stated differences between, say, a "current asset" and a "noncurrent asset" and then applying professional expertise to determine the proper classification.

There are a lot of reporting and accounting mistakes in the financial reports created by US public companies.  The accountants that create those public company reports are the best of the best.  And given the amount of scruteny public company reports get (i.e. they are publicly available); if public company reports have mistakes, where do you think the private company financial reports might be in terms of quality?

Anyway, that is all for now.  Stay tuned to watch a new era of financial reporting appear right before your eyes!