Digital Financial Reporting

What I am trying to do is explain how a flexible yet finite logical system is represented in machine-readable form such that the rules-based (i.e. not patterns-based) finite logical system is sound, complete, and effective in terms of achieving some specific objective.  I am trying to describe a rules-based system (i.e. expert system) as contrast to a patterns-based system (i.e. machine learning). The system must be consistent, valid, complete, sound, and fully expressed.  The system must have the appropriate precision and coverage.

This description must be understandable by business professionals and by information technology professionals but reconcilable to the work of knowledge engineering professionals.

Here are the inputs:

Input #1: Definition of Ontology and Ontology-like Thing

The following is restated from my enhanced description of an ontology-like thing.

An ontology or ontology-like thing is a model that specifies a rich and flexible description of the important

• terms: (terminology, concepts, nomenclature; primitive terms, functional terms);
• relations: (relationships among and between concepts and individuals; is-a relations, has-a relations; other properties);
• assertions: (sentences distinguishing concepts, refining definitions and relationships; axioms, theorems, restrictions); and
• world view: (reasoning assumptions, identity assumptions)

relevant to a particular domain or area of interest, which generally allows for some certain specific variability, and as consciously unambiguously and completely as is necessary and practical in order to achieve a specific goal or objective or a range of goals/objectives.  An ontology-like thing enables a community to agree on important common terms for capturing meaning or representing a shared understanding of and knowledge in some domain where flexibility/variability is necessary.

Note that ontologies to not support mathematical computations.

"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)

Input #3: First Order Logic and Automated Reasoning in a Nutshell

C. Maria Keet's describes the semantics of a system on page 30 of her book (page 43 in the PDF) An Introduction to Ontology Engineering but she describes those semantics using rather technical terms that are not understandable to a typical business professional, the terms are not consistent with my Input #1 or Input #2; but it does seem to provide all the moving pieces of the puzzle.

Input # 4: Practical Logic for Business Professionals

First in Computer Empathy (on page 64) and then in Artificial Intelligence and Knowledge Engineering in a Nutshell (page 39) I tried to create a succinct summary of logic or what I called a "practical logic for business professionals".  But, I could not tell if I had all the moving pieces of the puzzle.  Anyway, this is a good start but I can now do better.

Input #5: Z-Notation

As I understand it, Z-Notation, which is an ISO standard, is one of the more power languages for representing a logical system.  However, Z-Notation is not machine readable; it is only readable by humans.  Z-Notation uses terms such as:

• States
• Dynamics
• Sets
• Subjects and predicates
• Logical negation
• Logical connectors
• Quantifiers

• the states it can occupy;
• the invariant relationships that are maintained as the system moves from state to state.

• the operations that are possible;
• the relationship between their inputs and outputs;
• the changes of state that happen.

This reference manual and this video are very helpful in understanding Z-Notation.

Input #6: Book of Proof

The Book of Proof, Chapter 2 - Logic, describes logical systems. Other chapters describes other detailed aspects of logical systems.

Input #7: UML Association/Aggregation/Composition/Generalization

In UML there are three primary types of relations:

• owners feed their pets; pets please their owners (association, "is-a")
• a "tail" is part of a dog and also a part of a cat (aggregation, compisition, "part-of")
• a "cat" is a kind of pet (generlization)

Input #8: Conceptual Graphs

Conceptual Graphs are said to have been introduced by John Sowa in 1984.  Conceptual graphs use the following terminology:

• Concept: Any distinguisable idea (see slide 15 in the presentation)
• Relation: A relationship between two or more concepts (see slide 16)
• Context: A context encloses an entire proposition (see slide 17)
• Logical operations: Logical operations including AND, NOT, FORALL (see slide 18)

These ideas are the basis for common logic as I understand it.

Input #9: ISO Common Logic and Simple Common Logic

ISO defines Common Logic.  But I see no high-level explanation of describing a logical system, but they do have a lot of "details".

Simple Common Logic (see here and see here) defines a set of term suscincty and also provides UML diagrams for those terms.  But the terms are hard for the average person to understand.

Input #11: ABox, TBox

ABox, TBox and this person uses RBox to define a knowledge base.  This article uses the term "formal specification for conceptulizations". That article also talks about why a world view is necessary to agree on processing of the stuff in the ABox and TBox. This is an excellent article on ABox and TBox and why you need to separate the two.

Input #12: OMG Ontology Definition Metamodel (ODM)

OMG defines an ontology metamodel and reconcilses UML to that model. ODM states (page 31)

An ontology defines the common terms and concepts (meaning) used to describe and represent an area of knowledge. An ontology can range in expressivity from a Taxonomy (knowledge with minimal hierarchy or a parent/child structure), to a Thesaurus (words and synonyms), to a Conceptual Model (with more complex knowledge), to a Logical Theory (with very rich, complex, consistent, and meaningful knowledge).

Input #13: John Sowa

John Sowa has a plethora of extremely useful information.

Input #14: OMG's Semantics of Business Vocabulary Rules (SBVR)

OMG provides a standard called Semantics of Business Vocabulary Rules (SBVR).  As I understand it, SBVR is consistent with Common Logic, just as ODM is.

This presentation provides a good overview of SBVR.  There is a connection between SBVR and business rules, see this business rules mantra.  Also, note this business rules manifesto.  Also, note this classic paper on business rules.

This is a nice high-level statement and an example of the level of informatoin I am trying to convey: "Rules build on facts, and facts build on concepts as expressed by terms."

Input #15: Prolog

Prolog defines this terminology

OUTPUT: (Trying to make this understandable to business professionals)

This is my first attempt to synthesize all three of these inputs into a succinct explanation of how a finite logical system can be described in machine-readable for such that the information is machine-understandable and is safe, reliable, and predictable and therefore useful:

• Theory: A theory is a consistent, set of models.  A theory is a finite logical system.
• Model: A model is a consistent, set of structures.
• Structure: A structure is a set of terms, relations, and assertions represented using some vocabulary. There are IS-A structures and HAS-PART structures.  (A V-structure consists of a non-empty underlying set ∆ along with an interpretation of V. An interpretation of V assigns an element of ∆ to each constant in V, a function from ∆n to ∆ to each n-ary function in V, and a subset of ∆n to each n-ary relation in V. We say M is a structure if it is a V-structure of some vocabulary V.)
• Vocabulary: A vocabulary is a set of terms, structures, functions, relations, and constant symbols.
• Formula: A formula is a statement that is consistent with a vocabulary.  (Let V be a vocabulary. A V-formula is a formula in which every function, relation, and constant is in V. A V-sentence is a V-formula that is a sentence.)
• Sentence: A sentence is a grammatical unit of a statement.  (Note that not all sentences are statements.)
• Statement: A statement is a proposition, claim, or assertion of a fact about the universe of discourse.
• Term: A term is a primitive or complex (functional) ideas that are used within some domain. Terms include constants and variables.  Defining a term is a type of statement.
• Assertion: An assertion is a statement which distinguishes on term from another term or otherwise refines the definition of or relations between terms.  An assertion is a specification for a permissible manipulation of a structure, vocabulary, model, or formula.  An assertion can take the form of an axiom, a theorem, or a restriction.
  • Axiom: An axiom is a sentence which describes self-evident logical principles related to a domain that no one would argue with or otherwise dispute.
  • Theorem: A theorem is a statement which makes a logical deduction which can be proven by constructing a chain of reasoning by applying axioms or other theorems in the form of IF…THEN statements.
  • Restriction: A restriction is a statement is a special type of axiom or theorem imposed by some authority which restricts, constrains, limits, or imposes some range.

What is becoming quite evident is that what is needed is a model of how to properly construct such a model. Whether you use the XBRL technical syntax, or RDF/OWL/SHACL, or some other technical syntax to represent such a system; the semantics of the system need to good.

If anyone has any input or is aware of an existing understandable explanation of this information please ping me.

(This is the improved version of the above.)

##########################

Framework for Ontology Evaluation

Ontologies, Taxonomies, and Bears --  Oh my! (very good description of what an ontology does)

A History of Set Theory

Logic Gates

Describing Logic Gates Algebraically

Logical systems

FOL and Prolog

Software Requirements and Specifications (See the introduction)

Science and Sanity

Logic and Reasoning

These two papers discuss the notion of a matrix-based accounting system:

The first paper provides an example based on three transactions.  Here are the transactions:

• XBRL Instance
• XBRL taxonomy schema
• Human readable (presentation relations) (XML Infoset of the same information)
• XBRL Cloud Evidence Package

Here is a good human readable rendering of the information in the XBRL instance:

(Click image for a larger view)

You can create exactly the same sort of XBRL instance using typed members rather than explicit members which might be a good idea because the chart of accounts would likely be potentially large and quite variable.  You can assign properties to the [Member]s of the Debit [Axis] and Credit [Axis].  Interesting stuff.

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