Digital Financial Reporting

In his Harvard Business Review article, Why Technologists Should Think Like Biologists, Samuel Arbesman points out that one way they learn about a system is by examining when that thing goes wrong.  That is one way that I learned about XBRL-based digital financial reports.  By looking at basic, fundamental accounting concept relations that were not working as I would have expected.

This short article is worth reading.

This articleby Arnaldo Pérez Castaño provides a good introduction to artificial intelligence terminology.  An expert system is a branch of artificial intelligence.

First off, what is artificial intelligence?  Richard Bellman, from his book Introduction to Artificial Intelligence: Can Computers Think?, provides this definition:

Artificial intelligence is the automation of activities that we associate with human thinking and activities such as decision making, problem solving, learning and so on.

So how do you actually do that?  How do you get computers to automate activities?  That is what all these terms are about. How to implement the automation of activities in the form of software.  Here are some of the terms from the article referenced above that help you get your head around the capabilities of an expert system and how such systems might be implemented in software:

• Agent: An agent is an entity capable of sensing its environment and acting upon it.  An agent performs specific tasks on behalf of another.  In the case of software, an agent is a software program.  The main difference between a software agent and an ordinary program is that a software agent is autonomous; that is, it must operate without direct intervention of humans or others.
• Rational agent: A rational agent is one that acts so as to achieve the best outcome or, when there's uncertainty, the best expected outcome. Rationality as used here refers to making correct inferences and selecting the action that will lead to achieving the desired goal.
• Percept: A percept refers to the agent's perceptual inputs at any given moment.
• Percept sequence: The percept sequence represents the complete sequence of percepts the agent has sensed or perceived during his lifetime.
• Agent function: The agent function represents the agent behavior through a mapping from any percept sequence to an action.
• Reactive agent: A reactive agent is capable of maintaining an ongoing interaction with the environment and responding in a timely fashion to changes that occur in it.
• Pro-active agent: A pro-active agent is capable of taking the initiative; not driven solely by events, but capable of generating goals and acting rationally to achieve them.
• Deliberative agent: A deliberative agent symbolically represents knowledge and makes use of mental notions such as beliefs, intentions, desires, choices and so on. (This is implemented using a belief-desire-intension model.)
• Hybrid agent: A hybrid agent is one that mixes some of all the different architectures.
• Learning agent: A learning agent is one that requires some training to perform well, adapts its current behavior based on previous experiences and evolves over time.
• Non-learning agent: A non-learning agent is one that doesn't evolve or relate to past experiences and is hard coded and independent of its programming.
• Multi-agent system: When an agent coexists in an environment with other agents, perhaps collaborating or competing with them, the system is considered a multi-agent system.
• Coalition: A coalition is any subset of agents in the environment.
• Strategy: A strategy is a function that receives the current state of the environment and outputs the action to be executed by a coalition.
• Blackboard: A blackboard structure is a communication form that consists of a shared resource divided into different areas of the environment where agents can read or write any significant information for their actions.
• Coordination: Coordination is essential in mult-agent system because it provides coherency to the system behavior and contributes to achieving team or coalition goals.
• Cooperation: Cooperation is necessary as a result of complementary skills and the interdependency present among agent actions and the inevitability of satisfying some success criteria.
• Competition: Another possible model is that in which the agents are self-motivated or self-interested agents because each agent has its own goals and might enter into competition with the other agents in the system to achieve these goals. In this sense, competition might refer to accomplishing or distributing certain tasks.
• Negotiation: Negotiation might be seen as the process of identifying interactions based on communication and reasoning regarding the state and intentions of other agents.

Some people group all these into one big group, intelligent agent, but I think having this breakdown helps one understand the capabilities of agents.  Many people tend to overstate the capabilities of agents.  For example, the article mentions software having a conscience.  Saying stuff like that is not helpful and is generally hype. What I am sure of is that agents can perform useful work.

Here is a graphic of an agent:

From Wikipedia

Want to build an agent? Shoot me an email.

***** MORE ********

Different types of agents video.

Introduction to Intelligent Agents

Intelligent agents

Business rules can be categorized. The Business Rules Group provides a good summary of business rule categories.  But sometimes how terms are used differ between groups using such terms.  Below I have provided a set of business rule categories inspired by the Business Rules Group categories which is then reconciled to XBRL terminology.  This is my FIRST PASS at reconciling these terms.  I am soliciting feedback from others to get this correct.  Please consider this a DRAFT at this point!

• Definition of business terms: The very definition of business terms is a category of business rule.  Each term is a rule.  In XBRL, the report elements defined in an XBRL taxoomy schema is how business terms are defined.  Terms are essentially identifiers.   In XBRL, terms are grouped into one of the following categories of terms: Network, Hypercube (a.k.a. Table), Dimension (a.k.a Axis), Member, Primary Items (a.k.a. Line Items), Primary Item (a.k.a. a concrete Concept), and Abstract(a.k.a an abstract Concept or Primary Item).  Business professionals have to go through a process of naming things that exist in reality and giving them names as contrast to providing additional preferred labels for names that already exist.  These terms describes how business professionals think and talk about real world notions, ideas, and other such phenomenon. The definition of terms in the past have been documented in the form of human-readable glossaries. We now make these terms human-readable and machine-readable by defining them in XBRL taxonomy schemas.  Information technology professionals sometimes define terms in the form of an entity/relationship model.
• Structural assertions: This term appears to describe two types of structures in XBRL: what XBRL calls a "fact" and what XBRL calls "relations" (presentation, calculation, definition, XBRL formula).  Structural assertions can be documented as natural language sentences or described graphically has hierarchies as relationships, qualities, and other such structures. There are two important distinct types of structures in XBRL
  • XBRL Fact: A fact in XBRL is something that is reported within an XBRL instance. A fact is a structure comprised of other structures generally defined in the form of terms in an XBRL taxonomy schema but there are a few things defined in the XBRL instance itself (entity identifier, period, XBRL footnotes). So, a fact is a hard-coded structural assertion defined by the XBRL technical specification. A fact has an aspect model. This is the same as what I call the multidimensional model of XBRL.
  • Other XBRL relations: This category of structural assertions includes all other relations definable using XBRL including presentation, calculation, definition, and XBRL formula relations.
• Action assertions: Action assertions constrain or influence behavior in some way.  Action assertions cause things to happen or prevent things from happening.  They can also be used to make suggestions.  XBRL Formula provides for existence assertions, consistency assertions, and value assertions. (I think a value assertion is a derivation.)
• Derivations: A derivation is a mathematical algorithm or a logical inference (induction or deduction) that is used to derive, or what I have called impute, other structural relations (i.e. XBRL facts or other relations).  Derivations create new knowledge based on existing knowledge.  XBRL Formula has a mechanism for creating new facts.

A bit of clarification is helpful to make sure all of the above is clear.  The notion of derivations might not be familiar to some people or you might be familiar with it in different terms.  Here is some clarifying information that distinguishes between explicitly provided facts and derived facts (see here for similar information from the Business Rules Group):

• Base Fact: a base fact is a fact that has been explicitly reported in a financial report.  For example, if you report the fact "us-gaap:Assets" for a specific economic entity for a specific period.
• Derived Fact: a derived fact is a fact whose value is created by an inference or mathematical computation. For example, if the base facts "us-gaap:Assets" and "us-gaap:AssetsCurrent" are reported then the fact "us-gaap:AssetsNoncurrent" can be derived because of two pieces of information: (1) the values of us-gaap:Assets and us-gaap:AssetsCurrent are known and (2) the business rule "Assets = Current assets + Noncurrent assets" is known; so deductive reasoning can be used to obtain the derived fact "us-gaap:AssetsNoncurrent'.
• Derivation: a derivation is an algorithm used to infer or compute a Derived Fact. (i.e. a business rule).  In the derived fact example above, the derivation is "Assets = Current assets + Noncurrent assets". There are two types of derivations:
  • Logical inference: a logical inference is a Derivation that produces a Derived Fact using logical induction (from particulars) or deduction (from general principles). 
  • Mathematical inference: a Derivation that produces a Derived Fact according to a specified mathematical algorithm.

 So that is my first cut.  What are your thoughts?

This blog post summarizes the process of validating the mechanical rules of a disclosure within an XBRL-based financial report.  To understand that process, the first thing that you need to understand is the notion of what I call a block.

A block is a unit or fragment of a digital financial report that I came up with and gave a name so that I can refer to that part of a report. In order to understand the mechanical structure of a disclosure and verify that the mechanical structure is correct, you have to understand the notion of a block.  The document Understanding Blocks, Slots, Templates and Exemplars explains this in detail.

So in short; a block is fragment of an XBRL-based digital financial report that shares the same concept arrangement pattern and member arrangement pattern.

I will walk you through an example of a block, explain the mechanical structure of a block, explain how to verify that mechanical structure, and explain how to identify and verify the disclosure that the block is representing within a financial report.  Finally, I will show that each and every part of an XBRL-based digital financial report can be verified and identified using this same mechanical approach.

So here is a block:

Block (a roll up)

The block above came from this report that was submitted to the SEC.  What do you know about the block above?  The block above is a Level 4 Detailed disclosure from a public company report. You can see that the block concept arrangement pattern is a ROLL UP because it has a list of items and that list of items "rolls up" to a total.  You might not realize that the SEC sort category is "Disclosure".  You would know that you would expect that XBRL calculation relations would exist to represent the mathematical computation of the roll up. You would expect that the roll up actually does roll up to the correct total (i.e. the detailed items add up to the total item).

Here is another block. This block below might look the same as the block above, but they are completely different blocks. The block below is a Level 3 Disclosure level Text Block.  The concept arrangement pattern is Text Block. This block likewise has the SEC sort categoryof "Disclosure". There are no XBRL calculation relations because this block is a Text Block, not a ROLL UP like the block above.

Block (a Text Block)

If you go to the SEC Interactive Data Viewer and look at the report, you will recognize that there is yet another block which has this same information.  This third block is the Level 1 Note level Text Blockand is represented by the concept "us-gaap:InventoryDisclosureTextBlock".  That block looks exactly the same as the block above, but note that the block above uses the concept "us-gaap:ScheduleOfInventoryCurrentTableTextBlock" which is a Level 3 text block whereas the concept "us-gaap:InventoryDisclosureTextBlock" is a Level 1 text block.

Now, ALL THREE OF THESE BLOCKS REPRESENT THE SAME INFORMATION!!!  The Level 1 Note level text block is the presentation of the information within a note.  But the Level 3 text block and the Level 4 detail both represent the same disclosure.

Here is that disclosure.  I gave the disclosure a name, I called it InventoryNetRollUp.  There are lots of other economic entities that report that same disclosure, here is a partial list.  I call other examples of the same disclosure by the name Exemplars.

If you look at the blocks of the economic entity above and the Exemplars, you see some patterns.  For example, every one of these uses the same text block concept "us-gaap:ScheduleOfInventoryCurrentTableTextBlock" and the same total concept "us-gaap:InventoryNet".  For all of these disclosures, the concept arrangement pattern is that of a ROLL UP.  You can see that information represented in human readable terms here:

Human readable business rules

It is harder for humans to read, but you can see that same information here in machine-readable XBRL.  Or, if you go back to this page and look toward the bottom under the heading "Business Rules for Disclosure" you can see another human-readable representation of rules that each and every disclosure of "Inventory, Net (Current), Roll Up" follow.

Now, the dislosure "Inventory, Net (Current), Roll Up" is a DIFFERENT DISCLOSURE from "Inventory, Net (NONCURRENT), Roll Up".  And there are lots of other inventory related disclosures.  And there are other disclosures related to other topics.

In fact, here is a lost of many of those other disclosures. I have 959 different disclosures.  Each of these disclosures works in the exact same mechanical way.  Now, I am NOT SAYING that I have 100% of all the disclsoures that public companies report.  And I am NOT SAYING that I have 100% of this metadata perfected.  I am saying is that I have a lot of metadata and this seems to work over, and over, and over in SEC filing after SEC filing after SEC filing.

Besides, if you think about it; how many roll ups of inventory would you expect to actually roll up, have the required XBRL calculation relations, use the concept "us-gaap:InventoryNet", and use the same Level 3 Text Block to represent the required Level 3 text block disclosure that is required and perhaps even the Level 1 Text block that is required for the note?  How about 100%!

And why would you expect some disclosures to not have these same mechanics?  Logically, all of this makes sense.  And so what about the public companies that do not follow these disclosure mechanics?  Well, either: (a) I have my disclosure rules wrong and they need to be fixed or (b) the filers are creating their filings inconsistently and they need to be fixed.

But wait, there is more!  If a public company has a inventory disclosure; what do you think the probability is that they have the line item inventory on their balance sheet?  And if the public company has the inventory disclosure and the line item inventory on their balance sheet; what is the probability that they have an inventory policy reported? This is the sort of thing I am talking about when I say Automating Accounting and Reporting Checklists.  Accountants check all these things today, but they tend to do it manually using memory joggers rather than machine-readable business rules.

You can articulate these rules in a machine-readable form.  Here you go. Each of those rules are articulated using the global standard XBRL format.  Here are proprietary relations that I createdto represent this knowledge in machine-readable form. Why are they proprietary?  Because I have not been able to convince XBRL International to put the relations into the XBRL International Link Role Registry(LRR).  But I am working on it.

And that is an overview of the mechanical rules of disclosures.  Stay tuned for more information should you be interested.

The Merriam-Webster dictionary defines anarchy:

a situation of confusion and wild behavior in which the people in a country, group, organization, etc., are not controlled by rules or laws.

Simply put, business rules prevent anarchy.

Ronald Ross, the father of business rules, tells a great story of how he figured out what business rules are.  The Business Rules Manifesto defines in detail what business rules are using 10 very specific articles.  The most succinct definition of business rules that I have come across is this:

Business rule: A formal and implementable expression of some business user requirement.

This definition of what a business rule is comes from the Business Rules Group which is a good source of information about business rules, particularly their Business Rules Manifesto.

Business rules can be grouped.  Different people group business rules into different groups such as "structural rules" or "behavioral rules".  Others break them down into "quality logic" and "business logic".  At their essence, business rules articulate information about something or about the relationship between one thing and some other thing. Some examples that can help you better understand exactly what they are:

• Assertions: For example asserting that the balance sheet balances or "Assets = Liabilities + Equity".
• Computations: For example, calculating things, such as "Total Property, Plant and Equipment = Land + Buildings + Fixtures + IT Equipment + Other Property, Plant, and Equipment".
• Constraints: For example, specific behavioral consraints that control when it is appropriate to create, update, or remove information.
• Process-oriented rules:  For example, the disclosure checklist commonly used to create a financial statement which might have a rule, "If Property, Plant, and Equipment exists, then a Property, Plant and Equipment policies and disclosures must exist."
• Regulations: Another type of rule is a regulation which must be complied with, such as "The following is the set of ten things that must be reported if you have Property, Plant and Equipment on your balance sheet: deprecation method by class, useful life by class, amount under capital leases by class . . ." and so on.  Many people refer to these as reportability rules.
• Instructions or documentation: Rules can document relations or provide instructions, such as "Cash flow types must be either operating, financing, or investing."
• Relations: How things can be related, such as whole-part relations.  For example, how the business segments of an economic entity are related.

Business rules shape or influence behavior. Business rules outline mandates, define policies, and provide guidelines.

Don't make the mistake of thinking that business rules are completely inflexible and that you cannot break rules.  Sure, maybe there are some rules that can never be broken.  Maybe there are some rules that you can break.  It helps to think of breaking rules as penalties in a football game.  As Article 9 of the Business Rules Manifesto states, business rules are of, by, and for business people; not IT people. 

• 9.1. Rules should arise from knowledgeable business people. 
• 9.2. Business people should have tools available to help them formulate, validate, and manage rules.
• 9.3. Business people should have tools available to help them verify business rules against each other for consistency.

There are many different ways of expressing business rules.  The more expressive the business rules are and the more business rules are represented in machine-readable form; the more reasoning capacity a software application can provide to its users.  Express enough information in the form of machine-readable business rules and you can create an expert system. Expert systems are tools that provide benefits.

One specific benefit of expert systems is the automation of certain manual tasks.  Not all tasks can be automated, but some can.  I talk about automating accounting and disclosure checklists which are used in the process of creating external financial reports or other regulatory reports.  Today, these sorts of checklists are human readable memory joggers.  Tomorrow, they will be machine-readable business rules that improve information quality and reduce the risk of noncompliance while decreasing the cost of compliance.

XBRL is an enabler.  To understand more about what XBRL is enabling, read my Conceptual Overview of an XBRL-based, Structured Digital Financial Report. Realize that digital financial reports is just one example of what XBRL is enabling.

Become an XBRL master craftsman.  Apply business rules appropriately and prevent anarchy.

Oh, and one more thing.  Noticed how many times I linked to the Business Rules Manifesto?  Please be sure to read that. It's important.