BLOG:  Digital Financial Reporting

This is a blog for information relating to digital financial reporting.  This is my brain storming platform.  This is where I think out loud (i.e. publicly) about digital financial reporting. It is for innovators and early adopters who are ushering in a new era of accounting, reporting, auditing, and analysis in a digital environment.

Much of the information contained in this blog is synthasized, summarized, condensed, better organized and articulated in my book XBRL for Dummies and in the chapters of Intelligent XBRL-based Digital Financial Reporting. If you have any questions, feel free to contact me.

Difference between Taxonomy, Conceptual Model, Logical Theory

There is a difference between a taxonomy, a conceptual model, and a logical theory.  This is explained well in The Ontology Spectium by Dr. Leo Obrst.

This shows cost/benefit.

This shows differences in expressiveness.

See this paper.

Posted on Tuesday, December 11, 2018 at 07:11AM by Registered CommenterCharlie in | CommentsPost a Comment | EmailEmail | PrintPrint

Ten Common Mistakes Made When Creating XBRL Taxonomies

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)

Posted on Friday, December 7, 2018 at 07:14AM by Registered CommenterCharlie in | CommentsPost a Comment | EmailEmail | PrintPrint

Open Source Framework for Implementing XBRL-based Digital Financial Reporting

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?

Posted on Thursday, December 6, 2018 at 03:10PM by Registered CommenterCharlie in | CommentsPost a Comment | EmailEmail | PrintPrint

Understanding Block Semantics

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.

Posted on Wednesday, December 5, 2018 at 02:50PM by Registered CommenterCharlie in | CommentsPost a Comment | EmailEmail | PrintPrint

Forbes: The Four Letters Transforming The Municipal Bond Market And Government Finance

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.

Posted on Wednesday, December 5, 2018 at 07:04AM by Registered CommenterCharlie in | CommentsPost a Comment | EmailEmail | PrintPrint
Page | 1 | 2 | 3 | 4 | 5 | Next 5 Entries