Digital Financial Reporting

I see the following 10 common mistakes made when people get together to create XBRL taxonomies:

1. Don't have clear, useful requirements: The first mistake that is usually made is that clear, useful requirements or principles are not created that drive decisions.
2. Confusing business domain tasks and technical tasks:  Business professionals should make domain decisions; technical professionals should make technical decisions.  Mixing these two tasks wastes time and leads to bad choices.
3. Don't treat project as an engineering task: Taxonomies need to thought about using engineering processes and techniques.  The engineering design process works to create things that work.
4. Little or no consideration given to existing taxonomies: Existing taxonomies have strengths and weaknesses.  If you understand those strengths and weaknesses, that information can be used to make the taxonomy you are creating better.  If you don't understand those strengths or weaknesses, then you probably should not be building taxonomies.
5. Don't use XBRL instances to judge if taxonomy works correctly: Ultimately, an XBRL taxonomy is used to build XBRL instances.  If XBRL instances don't work correctly, then the taxonomy is not constructed correctly.
6. Don't test nearly enough:  Related to #3, testing is important.  Most taxonomy projects test about 1% or less of what they should be testing.  Testing results should drive decisions, not personal opinions. (See #3, engineering design process; prototype, test, iternate, communicate)
7. Don't involve software vendors appropriately: Not involving software vendors, which create the software people using the taxonomy will interact with the taxonomy, appropriately is a big missed opportunity.  That said, most software vendors don't really understand how to engage properly in a taxonomy creation project.
8. Taxonomy pieces too big: Taxonomy pieces tend to be too large in taxonomies.  More smaller pieces that are well organized is better.  Remember, computers will be interacting with the taxonomy.
9. Don't understand the "model as dimension or primary item" quesion: Endless debates occur around the topic of whether something should be modeled as a dimension or modeled as a primary item in a taxonomy.  Taxonomy requirements and testing drives this decision, not personal choice.
10. Not understanding and mixing dimensional and nondimensional models: The multidimensional model is well understood.  The multidimensional model works well in XBRL that functionality is not open for debate.  Taxonomy creators need to first understand and then work within that model not fight with it.

If the engineering design process was followed, resulting taxonomies would be superior in terms of functionality. Managing a project where a lot of different people from different domains are involved is challenging.  If done right, good thing result.  If not, then this is what happens:

(Click image for larger view)

I have taken all the puzzle pieces that I have created over the past 10 years, organized them, documented the information, and the result is the Open Source Framework for Implementing XBRL-based Digital Financial Reporting.

The framework leverages the XBRL technical syntax to represent metadata which then enables the creation of a software ecosystem which supports high function and automated quality control.  While the framework is focused on the creation of financial reports, it also provides leverage for the extraction of information from those reports and then using that information for analysis.

Currently there are three software vendors that support this framework. If you want to see some basic things you can do wiith this framework, see this working prototype which provides source code or check out Pesseract.

I would not consider the documentation that explains what can be achieved by leveraging this framework to be particularly good at this point.  I will improve that over time.  But, for those that want to wade through the information, here you go.

If you are interested in being a consultant, helping others to implement this framework please contact me.

Ask yourself a question. What if I am seeing all of this correctly and foundational changes are coming to financial report creation?

Think about what it means if I am right about things like the utility of templates and exemplars in the process of creating financial reports.  Think about what it means if Blackline is right about the financial transformation and the modern finance platform.  Think about what it might mean if old-school processes of creating a financial report was replaced with new better, cheaper, and faster processes.

The painful, gruesome, grueling, barbaric process of re-keying of data may not come to an end, but the pain will be noticeably reduced over the coming years.

Do you think these changes are even possible?

I mentioned the notion of templates and exemplars.  I tried to explain the power of disclosures and showed how disclosures were related to templates and exemplers. I tied disclosures, templates, and exemplars into a bunch of other ideas and provided machine-readable metadata.

I mentioned that there was one more important piece of the puzzle, the notion of the Block.  Blocks are part of the "glue" that makes a lot of interesting functionallity work.

In the document Understanding Block Semantics I provide details of what Blocks are, how they work, and what they do.

If you are really trying to figure this stuff out, be aware of this page of my blog toward the bottom in the section "Information Specifically for Software Engineers".  I know that there is some redundancy and I know the set of information is not yet complete.  But I am getting there little by little.

The Forbes article by Barnet Sherman, The Four Letters Transforming The Municipal Bond Market And Government Finance, points out:

With accurate data comes extensive data functionality. There are nearly an endless number of applications for data to be used in. Software engineers can develop automated, repeatable processes so data can be analyzed, measured, ranked, benchmarked, managed, modeled, tested, shared, exchanged, outlined, mapped, sorted, templatized, searched, queried, predicted, charted, animated, mined, validated, machine-read, machine-learned, compared, reused, verified, categorized, structured, tracked, screened, referenced, stored and retrieved. Just for starters.

This is why I spend so much time and effort trying to understand why mistakes occur, figure out how to detect mistakes, figure out how to prevent mistakes, and otherwise contribute to the creatino of high-quality XBRL-based digital financial reports.

More information on state and local govenment use of XBRL can be found here:  Workiva and The Data Foundation have published another report, Transparent State and Local Financial Reporting: The Case for an Open Data CAFR, per the authors "outlines the steps necessary to create an infrastructure for open data CAFRs, anticipates challenges to open data adoption, and examines the impact currently-pending federal reforms could have on the process."

As I understand it there are about 90,000 state and local governmental entities in the United States.  Those entities tend to use governmental accounting standards provided by the GASB to create their financial reports.

If software engineers could get their act together in terms of ease of use and quality; then XBRL-based digital financial reporting could take off.  Until they do, it simply will not happen.  It should not because low quality information is useless. Metacrap is of no use to anyone.

Software vendors seem to be very short sighted.  Do you recognize that the market for creating financial reports is 25 million in the US alone?  XBRL-based reporting of public companies to the SEC is table scraps.

Metacrap is a derogatory term for metadata.  In his 2001 influential essay Metacrap: Putting the torch to seven straw-men of the meta-utopia, Cory Doctorow, a blogger and digital rights activist, pointed out a world of "exhaustive, reliable" metadata would be wonderful, but such a world was "a pipe-dream, founded on self-delusion, nerd hubris, and hysterically inflated market opportunities."

The utopia of the semantic web has not yet materialized.  Whatever Happened to the Semantic Web? 

So, what is the problem?  First, just as I mention in Computer Empathy that there are TWO categories of artificial intelligence, "generalized" and "specialized" (see page 21/22); there are likewise TWO categories of semantic web; "generalized" and "specialized".  Yes, same deal.

Having a generalized semantic web where everything universally works with everything else will not happen for many years, if it happens at all.

However, a specialized semantic web, say for financial reporting, is significantly easier to create. 

The biggest problem in creating a semantic web is overcoming the "metacrap".  Cory Doctrow offers this list of obstacles to realizing utopia:

1. People lie.
2. People are lazy.
3. People are stupid.
4. Mission: Impossible - know thyself. (i.e. people are lousy observers of their own behavior)
5. Schema aren't neutral.
6. Metrics influence results.
7. There's more than one way to describe something.

So, what if you could overcome these obstacles?  Not overcome it generally, but in a specialize system such as financial reporting?

If you want to see that happened, be sure to stay tuned.

There seems to be a debate over the use of XML or JSON.  The debate is misguided in my view.  Read Stop Comparing JSON and XML. This article, The Rise and Rise of JSON helps you understand why developers like JSON.  Software engineers can worry about syntax; use whatever syntax you might desire.  It is trivial to convert the XBRL syntax to JSON.  What is hard is figuring out the semantics.  OpenGraph, JSON-LD; it does not matter to me.  All of this level will be hidden from business professionals.

Using XML for Data; Why the RDF Model is Different than XML Model;