Digital Financial Reporting

This blog post contrasts two different approaches to constructing XBRL taxonomies: bottom up and top down.

I don't know if you want to call these techniques, or strategies, or philosophies, or architectures.  And I don't know if "bottom up" and "top down" are the best choice of terms, but I will go with those terms now until I find something better.

By bottom up I mean that concepts are defined and relations between concepts are defined but the sets of concepts and relations are not explicitly defined.  The US GAAP XBRL Taxonomy and the IFRS XBRL Taxonomy both use this bottom up approach.

By top down I mean that the actual sets themselves are explicitly and uniquely defined and given names, and then the concepts and relations between concepts are defined.  The XASB reporting scheme uses this approach as does the old COREP and FINREP taxonomies.

Each approach has its pros and cons.  It is not the case that one approach is good and the other approach is bad; they are simply different approaches.  Most people creating taxonomies are completely unconscious that they even have a choice.

The primary advantage of the top down approach is that you can query reported information by the name of the set of information because each set of information is uniquely named and identified by a specific hypercube that is only used to report that specific information.  For example, if you open the XASB reporting scheme sample report that I created and look at the hypercubes (also called [Table]s) you will see that they are all unique.  If you contrast that to the Microsoft Corporation XBRL-based report submitted to the SEC and you notice how Microsoft uses the hypercube or [Table] us-gaap:StatementTable to represent many different disclosures; then you think about what it would take to query the balance sheet then you will understand the difference between the top down and bottom up approaches.

Now, you can "convert" a bottom up approach to a top down approach.  I have done that by creating the necessary machine-readable metadata.  That means that I can query bottom up or top down taxonomies.

Here are examples of both a bottom up taxonomy and a top down taxonomy where I have done exactly that, successfully queried sets of the report.  Notice in the two examples the list of "disclosures" and the business rules used to find the disclosure.  The key to understanding the difference is the composition of the business rules that are used to identify each disclosure within a financial report:

• Bottom up: XBRL-based financial reporting by public companies to the SEC. (This video uses this same summary of disclosures.)
• Top down: XBRL-based financial reporting per the XASB reporting scheme.

One "advantage" of the bottom up approach is that you don't have to explicitly define everything in the taxonomy in terms of the disclosure it represents.  This is not necessarily an advantage because if you make a mistake and leave something out, that error is not apparent.  To do this though, you have to understand 100% of the disclosures that will be provided.

Whereas the top down approach requires you to understand and explicitly provide for each disclosure up front and you simply build those sets one-by-one and piece-by-piece until you have the entire set of explicit disclosures provided for.

Another example of top down as contrast to bottom up is the extraction of information from reports: (pay particular attention to the mapping rules and impute rules provided in the VBA code of the Excel extraction tool)

• Bottom up: Extracting information from one reporting style related to XBRL-based reporting to the SEC.
• Top down: Extraction from one reporting style related to the XBRL-based reporting under the XASB reporting scheme.

This is an overview of what I call the XASB Reporting Scheme.  This is an imaginary reporting scheme which I am using to figure out the best technical approach to created an architecture for representing XBRL-based financial reports.  This is primarily to test financial reports but it is appropriate for general business reports also since a financial report is simply a rather complex business report.

I created this imaginary reporting scheme so that I could be completely unconstrained by the US GAAP XBRL Taxonomy and IFRS XBRL Taxonomy in figuring out the best approach to use.  The information below documents the existing prototype.

I will be updating this XASB reporting scheme based on some ideas from the European Single Electronic Format over the coming months. Ultimately, information from this prototype reporting scheme will make its way into the General Business Reporting XBRL Application Profile which Rene van Egmond and I have been maintaining.

You can view the information in each linked XBRL file in any off-the-shelf XBRL tool.  There are two software applications that leverage this metadata:  Pesseract which is a non-commercial but very comprehensive proof of concept and XBRL Cloud which is commercially available software.

• Conceptual model: The XASB reporting scheme uses the same conceptual model as the US GAAP and IFRS reporting schemes.
• Conceptual model relations:  The XASB reporting uses the same conceptual model relations between entities in the model as the US GAAP and IFRS reporting schemes.
• General relations: General relations use the arcroles defined by the XBRL technical specification plus are supplementd by these additional relation semantics. Neither US GAAP nor IFRS taxonomies provide for these relations but both US GAAP and IFRS have these relations.
• Disclosure relations: Disclosure relations use the arcroles defined by the XBRL technical specification plus are supplemented by these additional relation semantics. These semantics are used to describe and check the structural relations of disclosures and to create a reporting checklist. Neither US GAAP nor IFRS taxonomies provide for these relations but  both US GAAP and IFRS have these relations.
• Model structure relations: Model structure relations, which are the relations between Networks, Hypercubes (Tables), Dimensions (Axis), Members, Primary Items (Line Items), and Concepts are to be represented in XBRL presentation relations are described by these relations semantics. The model structure relations of the XASB reporting scheme follows the implied rules of the US GAAP XBRL Taxonomy architecture for these relations.
• Reporting styles: XASB provides for any number of reporting styles.  Currently, only one reporting style is provided for in the XASB reporting scheme. However, reporting styles are modeled after the same approach used by XBRL-based financial reports submitted to the SEC which has about 100 different reporting styles.  The US GAAP and IFRS XBRL taxonomies do not support reporting styles, but both US GAAP and IFRS have reporting styles.  Reporting styles are made up of three pieces;
  • Mappings: Mappings are represented using XBRL definition relations.
  • Impute rules: Impute rules are represented using XBRL formula.
  • Consistency rules: Consistency rules are represented using XBRL formula.
• Type or class relations: XASB provides for any number of type or class relations.  Currently, only a handful of example type or class relations are provided in the XASB reporting scheme.
• Disclosure mechanics rules: XASB provides for disclosure mechanics rules. Currently, disclosure mechanics rules are provided for each disclosure represented in the XASB reporting scheme.
• Reporting checklist rules: XASB provides for reporting checklist rules. Currently, reporting checklist rules are provided for each of the disclosures represented in the XASB reporting scheme.
• Combined disclosure mechanics and reporting checklist: This XBRL taxonomy schema combines the disclosure mechanics and reporting checklist into one functional set.
• Disclosures: XASB provides for the notion of a disclosure.  Currently, the following prototype disclosures are provided for by the XASB reporting scheme.
• Topics: XASB provides for the notion of a topic.  Currently, the following prototype topics are provided for by the XASB reporting scheme.
• Topic and disclosure relations:  XASB provides for the organization of disclosures into topics.  Currently, the following is a prototype organization of the disclosures into topics for the XASB reporting scheme.

Sample report: This XBRL instance for a sample economic entity reporting using the XASB reporting scheme is provided. This XBRL taxonomy for the BASE taxonomy and the COMPANY taxonomy are provided but NOTE that these taxonomies are not modularized correctly currently. (NOTE that neither the BASE or COMPANY taxonomy are modularized as I would deem appropriate currently.  These will be recast to be far more similar to the way XBRL-based reports are submitted to the SEC.  The current modularity is only for the convenience of the tools that I had to use to create the XBRL taxonomies.

Information extraction: This Excel spreadsheet is used to extract information from XBRL-based financial reports which are submitted to the SEC.  I want to create a similar tool that works for the XASB reporting scheme.  Here is the Excel spreadsheet that extracts information from an XASB reporting style report.  There is a wealth of information that can be gleaned from comparing these two extraction tools.

Repository: To test the ability to extract information from an XBRL instance created using the XASB reporting scheme, I created three additional XBRL instances by copying the the origional and then changing the file names, namespaces, and other information to make the XBRL instances and XBRL taxonomies unique.  The only data that is different is the entity name in each document.  Here is that prototype repository that contains four financial reports. (same thing in RDF format)

One significant difference between the XASB reporting scheme and the SEC and ESMA use of XBRL is that 100% of mathematical relations in an XBRL instance using the XASB reporting scheme are described and therefore can be valiated against business rules, generally XBRL formulas (GAAP and COMPANY).

Finally, the architecture above is driven by the desire to create a provably correct XBRL-based financial report as outined in the document Blueprint for Creating Zero-defect XBRL-based Digital Financial Reports. Further, it is driven by the desire to create a repeatable process for verifying such reports.

Here are actual validation results from XBRL Cloud: Disclosure mechanics and reporting checklist; Evidence package; Fundamental accounting concept relations for XASB currently exist only in newer format, need to create older version which XBRL Cloud supports; Type or class relations not currently supported by XBRL Cloud.

(Note that I have been maintaining and improving this XASB Reporting Scheme since about 2005.  The earliest publicly available version of this that I could find is this from 2008 which when what I now call the general profile was called XBRLS. The earliest private version of this was called 'Sample GAAP' and was from about 2006.)

Technology is rebooting accounting, reporting, and auditing.  XBRL-based digital financial reporting is only a part of that reboot.

The Center for Corporate Reporting used the phrase "digital switch-over" in the wake-up call they issued to their members, saying that they should rapidly familiarize themselves with new technologies useful in financial reporting.

Don't make the mistake of being simplistic about what this change is or what it means.  There are a lot of buzz words floating around like the Digital CPA.  The AICPA explains, What is a Digital CPA.  Marketing and sales people who don't really understand the change or what the changes really mean love buzz words.  Don't fall into that trap though.

There is a big difference between "simplistic" and "simple" explanations.  Simplistic is dumbing something down in order to make an explanation easier.  Simplistic ignores complexity in order to create an explanation which can get you into trouble.  Simplistic is over-simplifying.  Simplistic means that you have a naïve understanding of the situation.

Simple is something that is not complicated, that is easy to understand.  Simple means without complication.  An explanation of something can be consistent with the real world, consider all important subtleties and nuances, and still be simple, straight forward, and therefore easy to understand.

Explaining something in simple terms takes a lot of hard work.  You have to understand, synthesize, organize, summarize, and otherwise put together information that is useful to others. 

Creating simplistic explanations is not hard at all.  Those sorts of explanations are a dime-a-dozen. But those simplistic explanations will leave you unsatisfied and ultimately lead you down the wrong path.

What is the best way to understand these changes and what they mean? Read everything you can get your hands on. 

I have done the best that I can to explain the changes, the "digital switch-over", from my perspective: Getting Ready for the Digital Age of Accounting, Reporting and Auditing: a Guide for Professional Accountants.  That document provides the best explanation that I can synthesize, organize, and summarize in 15 pages.

At the end of that document is references to other documents that provide additional details, 187 more pages.

Those 187 pages come from a set of about 750 pages I have been collecting, synthesizing, organizing, and summarizing for about 15 years.  Intelligent XBRL-based Digital Financial Reporting is what I have come up with, you can download that information.

Know of something better?  Please make me aware of it.  Is something important missing?  Let me know and I will see what I can do to include it.  There is plenty of room for improving that information.

Just as it has for thousands of years, the institution of accountancy will emerge from the reboot better.  Different, but improved.

Accounting in Europe had no notion of the idea of ZERO until the middle ages. They learned about the concept of zero from Middle Eastern mathematicians and then incorporated that idea into accounting.  In 8500 BC merchants used bollae and tokens for accounting because numbers and writing had not been invented yet.  It was not until 3500 BC that clay tablets were used and writing and number systems started to emerge.  It would be another 500 years before writing and number systems were fully developed.  Double entry accounting was not documented by Luca Pacioli until 1400 AD.

And so now we are, perhaps, going back to tokens...electronic bitcoins and we may be using triple-entry accounting in digital distributed ledgers!  Reporting will evolve as will auditing.  Who know what will exist 5 years, 10 years, or 25 years from today.

CNTL + ALT + DELETE!

Are you ready for the "digital switch-over" for U.S. federal grant reporting?

The Data Foundation published the following report which is excellent information: Transforming Federal Grant Reporting: Open the Data, Reduce Compliance Costs, and Deliver Transparency. You can read most of the report on that link or you can provide your email address and download an easier to read PDF.

Here is my synopsis: The report describes the flaws in the existing document-centric federal grant tracking and management system and how an open data standard, such as XBRL, can both increase transparency within the system and reduce costs of compliance with federal grants and of operating and managing the system.

This is a description of the report provided by the Data Foundation:

In this report, the Data Foundation describes the flaws with the federal government’s current document-based grant reporting system and envisions an open data future for the way grants are tracked and managed.

The federal government continues to rely on outdated, burdensome document-based forms to track $662.7 billion in annual grant dollars - but open data could transform the system. Adopting a government-wide open data structure for all the information grantees report would alleviate compliance burdens for the grantee community, provide instant insights for grantor agencies and Congress, and enable easy access to data for oversight, analytics, and program evaluation.

The report explains that the grant reporting system is broken, in two distinct ways: first, it does a poor job of delivering transparency to agencies, Congress, and taxpayers; and, second, grantees sustain unacceptable costs of compliance. Replacing documents with data could address both problems.

Open data or structured information or XBRL-based information or whatever you want to call it is a very good idea. Imagine an "EDGAR"-type system (i.e. the SEC repository of public company financial information in XBRL) for all federal grants.  Imagine the ability to query that information using automated processes.  Imagine a similar system for the financial reports of state and local governments.  Think of the transparency offered to voters, government leaders, economists, financial anslysts, etc.  This can work.  The XBRL-based financial reports public companies are creating and submitting to the Securities and Exchange Commission are beginning to prove that.

The document points out that by replacing document-centric reporting with data-centric reporting using open data, "the government of Australia saves Australian companies over $1 billion annually, because the companies’ software can automatically generate and submit regulatory reports to multiple government agencies at once."

Undoubtedly, federal grant reporting will be part of the "digital switch-over".

So ask yourself some questions:

• What technical format will be used for all this "open data"?  Will it be XBRL-based open data or will it be some other technical format such as the Semantic Web Stack of technologies? Does it matter?  Should you have an opinion?
• Let's say that whoever is responsible for making that decision, I think it is the U.S. Treasury Department, picks XBRL.  What technical architecture will they use for XBRL? Will they use the Standard Business Reporting (SBR) architecture employed by the governments of Australia and the Netherlands?  Or, will they use one of the XBRL implementation styles of the US SEC, UK HMRC, or ESMA? Which is best? Why is it best?
• Who is going to create that "comprehensive taxonomy" that describes all of that open data?  Professional accountants maybe?  They are the ones that created the US GAAP XBRL Taxonomy and the IFRS XBRL Taxonomy.  How good are the US GAAP and IFRS XBRL Taxonomies?  Who decides how "good" they are?  The publishers of the taxonomy?  The users of the taxonomy?  How do you measure "goodness" of the taxonomy?
• Do you, or other professional accountants, have the appropriate skills for creating that comprehensive taxonomy?  Do you have the knowledge to even have an opinion as to how good a taxonomy is?  What skills or experience provided you with that knowledge?
• Will "open data" work?  How exactly do you know it will, or will not, work?  Was enough testing done to make sure that open data will work?  There are quality issues with the XBRL-based financial reports created by public companies.  Will those same issues be repeated in federal grant reporting, or will the issues be fixed?
• How well is open data really working in Australia and the Netherlands?  What public information exists to figure that out?

What is my point?  My point is that it is one thing to have a good idea.  It is another thing to actually implement that idea and make it work.  There is no magic here.  It takes skills, knowledge, good engineering practices, testing, attention to detail, domain knowledge, and other such things to make open data work the way we will want it to work.  In fact, it takes those same skills to decide and specify how it should work.

Ask yourself a question: Do I have the skills I need to do accounting, reporting, and auditing in the digital age?  What are those skills? How do I get the right skills.

Rene van Egmond and I have updated our General Business Reporting XBRL Application Profile to include ideas from the ESEF ESMA Reporting Manual.

This document is a side-by-side comparison of four financial reporting related XBRL-based architectures (US GAAP reporting by public companies to the SEC, UK GAAP reporting by companies to HRMC, IFRS reporting by listed companies to the ESMA, IFRS AU reporting to ASIC) to what I call the "general profile".

There are two uses for the general profile:

1. First, it documents somewhat of a "de facto standard" XBRL application profile for financial reporting.
2. Second, it documents an XBRL application profile that can be used for pretty much any sort of reportng scheme.  Rather than inexperienced people trying to figure out XBRL and repeating the mistakes of others; one can pick up this profile and use it as is or modify/tweak the profile to fit their needs.

To test this application profile, I created my own reporting scheme.

There are two software applications that specifically support this "general profile".  However, there are probably about 60 software applications that are very, very close to supporting the profile and they probably don't realize it.

Any software vendor that supports XBRL-based financial reporting to the SEC (about 6,000 public companies), XBRL-based financial reporting to the HRMC (about 1,200,000 companies), or will support XBRL-based financial reporting to the ESMA (will probably be about 10,000 listed companies) essentially report this "general profile".

The beginning of the "digital switch-over" for financial reporting is here.  There is a lot that general business reporting using XBRL can learn from XBRL-based financial reporting.