Financial Statement is a Formal Semantic Structure
A general purpose (or special purpose) financial statement is a well-formed formal semantic structure. That formal semantic structure can be explained. A conceptualization can be created which explains that formal semantic structure. Further, a representation in software (i.e. implementation) can be created per that conceptualization. (See the Triangle of Meaning for more information.)
To be clear; by general purpose financial statement I mean the complete set of primary financial statements, the policies, the disclosure notes, and any supplementary information included. The general purpose financial statement might be compiled, reviewed, or audited.
I have used TurboTax as an example of how something like a financial statement creation tool could be implemented in software. These papers explain how this is done via TurboTax:
- Tax Knowledge Graph for a Smarter and More Personalized TurboTax
- Tax Knowledge Adventure: Ontologies that Analyze Corporate Tax Transactions
- Modeling the Tax Code
I have explained the conceptualization of a financial statement in my Logical Theory Describing Financial Report. I created a framework and method, which I call the Seattle Method, which can be used to create an implementation. The Seattle Method was created by reverse engineering thousands of XBRL-based financial statements submitted by public companies to the U.S. Securities and Exchange Commission (SEC).
A financial statement is a navigable graph of meaning once you have the structural insight. A financial statement has regularity which can be exploited. A financial statement explains the state (i.e. balance sheet) and changes in state (i.e. income statement, cash flow statement, statement of changes in equity) of the reporting economic entity. Information about business events is standardized into an organized set of financial statement line items that resolve to the accounting equation: "Assets = Liabilities + Equity" a.k.a. "Resources = Obligations to Third Parties + Obligations to Owners". Those Assets, Liabilities, and Equity are decomposable into standardized subcategories and standardized line items to enable cross economic entity comparison of those business events.
There is an important distinction which needs to be made. A financial statement is both a container and the contents within that container. The container is universally specified. The contents that go within the container are specified by a base financial reporting framework. A reporting economic entity can extend a base financial reporting framework to provide necessary or supplemental information however that extended or supplemental information must be properly anchored to the base financial reporting framework. For example, a base financial reporting framework will provide a report element to provide information about total revenues; but a reporting economic entity may provide information about revenues detail in a manner with is unique to that reporting economic entity but is properly connected to or "anchored" to the base reporting framework total revenues element.
I have provided several reference financial reporting frameworks and sample financial statements using my Seattle Method.
In fact, you can use the Seattle Method to create an entire "closing book" (a.k.a. closing bundle), audit bundle, or financial analysis models.
All these new accounting, reporting, audit, and analysis tools are based on global open industry standards.
Financial reporting frameworks like US GAAP, IFRS, and others are very similar to the tax code in many ways. Sure, there are differences; but there are also a lot of similarities.
Software can be used to prove whether a financial statement has been created consistently with the expected formal semantic structure of a financial statement. This "expected formal semantic structure" is defined by a financial reporting framework, such as US GAAP, IFRS or other such reporting framework. Internal management reporting or internal cost reporting frameworks can also be used, such as Activity Based Costing (ABC). This can be achieved simply by representing financial reporting framework rules using some knowledge organization system (KOS) that is interpretable not only by humans, but also interpretable by machines.
Software does not tell you if the financial statement is "likely correct" or is "probably correct" or other type of confidence score; software proves that the financial statement is correct per a complete set of rules which are governed and which are consciously designed to minimize epistemic risk. This software will be as reliable and trustworthy as a calculator.
Again, not "likely correct" or "plausibly correct"; provably correct. Not a prediction, resolvable proof with a trail you can follow to see, verify, and understand the proof. You will get a formal, documented record just like that "tape" from a calculator.
That software you will be using is a semantic parser that understands the formal semantic structure of a financial statement. The tool you will use is not like Microsoft Word or Excel which do not understand anything about financial statements at all. The software literally resolves the logic of the financial statement to determine if it is, in fact, logically consistent with what is expected. That proof is based on evidence.
Here is a very, very simple example. Here is the report. Here is the evidence. (Admittedly, the evidence needs to be better organized and better synchronized to the actual report. Also, that set of evidence is only scratching the surface of what is possible.)
What is even cooler is that the formal semantic structure can be proven to be correct; it can also be reliably queried. Oh, and it can also be dynamically pivoted. And, it is re-composable. More on these things later.
Coming in the future will be an anatomy of the well-formed formal semantic structure of a financial statement.
Additional Information:
Comments
Post a Comment