Digital Financial Reporting

In the article Disclosure management: Streamlining the Last Mile, Mike Willis of PriceWaterhouseCoopers makes the statement that leading implementations of disclosure management applications are seeing 30% enhancements in report assembly and review efforts.  How?

By empowering reporting professionals to more efficiently and effectively assemble and review relevant information. This allows them to spend more time analyzing, communicating about performance and assessing risk than assembling and reviewing reports.

The article also makes a case for reporting templates and points out the benefits of standardization where standardization can be effectively applied.

Bottom line is that this article is a must read if you want to understand the future of external and even internal financial reporting.

Someone said something in one of the news lists which I subscribe to which is an incredibly succinct, insightful statement.  Here it is:

Automate to cut risk.

This is where I heard that statement. I prefer the term "reduce" to "cut". One could imply that "cut" could mean that risk could become zero and I don't believe risk can ever be zero, we just want to strive for zero risk.

Automation can also contribute to reducing costs.

In my reference implementation of an SEC XBRL financial filing I am up to 146 business rules which I use to make sure the XBRL is working correctly and therefore the financial report is correct.

Figuring out these rules and adding them manually using notepad is a lot of work.  To create these rules I had to work very, very hard to understand XBRL Formula.  If you add these business rules the way I had to, you will get to a high quality SEC XBRL financial report; however I understand people's reluctance to go through the effort because it is a rather daunting task given today's software applications for creating an SEC XBRL financial filings.

But, it will not always be this way.  Eventually, software vendors will get their act together and give accountants to software they need to create their SEC XBRL financial filings correctly.  Accountants will be able to prove to themselves that they did a good job and will be able to support their work.  It may seem very hard to believe today, but these business rules are a really good thing.

There are two ways you can check your work to be sure you did a good job: manually and using automated processes.  Doing these things manually is both expensive and so detailed that it really is impossible to get all the details correct.  Automation will turn this daunting task which is endured today into the solution pretty much everyone needs to get the quality of SEC XBRL financial filings where they need to be.

There are thousands and thousands of details which go into making a financial report the true and fair representation of a reporting entity's financial information that it needs to be.  Software is great at managing these details and performing repetitive, non-value added tasks.

Manual tasks will never go away.  But, the expensive and increased probability of errors caused by human involvement in this work can be reduced using automation.  Humans should do what only a human can do.  There is no way a computer will ever replace the judgment of a highly-skilled accountant. But computers can enhance the output and quality of an accountant's work.

Cars which are being created today could never be created without the robots which do much of the work to make sure all the pieces are there, put together correctly, and your complex automobile serves your needs reliably.  If you remember the lemon laws of the 70's and 80's, the reason that those laws existed were because so many mistakes were being made in the process of creating a car.

Software vendors will eventually deliver software which turns the complex process of creating an SEC XBRL financial report we experience today into a process accountants will prefer over the current processes of creating the legacy document formats of today.  Quality of the financial reports will be higher, both the accounting and financial reporting piece and the XBRL piece.

I know this his hard to believe and I am not asking anyone to take my word for this, it is a prediction.

Automation will make this prediction a reality.

This is one of the more interesting things which I have run across. Epistematica's article A new approach for Digital Financial Reporting states (the emphasis is mine):

Epistematica has studied and experimented an original approach for the XBRL-based Digital Financial Reporting, that introduces the possibility of defining the semantics of financial facts.

This approach is based in a strongly logical knowledge representation that aims at running inferential processes to automatically extract knowledge that is implicit in balance sheets and notes.

This is exactly on target: make the implicit knowledge explicit and articulate this explicit knowledge using a format understandable by computer software.

They seem to be calling their approach "Semantic Financial Reporting".  I like that term even better than Digital Financial Reporting.

The Data Coalition has a great graphic which explains the pieces of what they call "Smart Regulation". Another term for this is algorithmic regulation.

Data Coalition, Smart RegulationIn the graphic, notice the center column, the "Engine of Automation".  Excellent term.  In order for the engine of automation to work and get the benefits to both regulators and those being regulated (in the right column) you need all the stuff in the left column (vocabularies, business rules, interchange formats, identifiers).

The HL7 folks explained this as technical interoperability, semantic interoperability, and process interoperability.

Any system, yes any system, trying to make information exchange work effectively needs all these pieces.  The reason the XBRL-based data in the SEC EDGAR system is not useful is because the FASB/SEC left some of these pieces out of their system.

XBRL is only the "interchange format" or part of the "technical interoperability" piece.  XBRL provides a way of articulating the vocabulary and business rules, US GAAP is the vocabulary and business rules.  The US GAAP Taxonomy left out many of the business rules.  It is the missing business rules which causes most of the issues with the XBRL-based information in the SEC EDGAR system.

XBRL is excelling as an interchange format.  At the technical syntax level, XBRL technical syntax is inter-operable globally.  However, many systems leave out important business rules which makes the information less inter-operable at the business semantics level.

Finally, a tool which is useful to accountants verifying an SEC XBRL financial filing! While it isn't perfect (Version 1.0), XBRL Cloud's Evidence Package is a big, big step toward giving accountants the tools they need to effectively create and verify that they have created an appropriate SEC XBRL financial filing.

You send the URL of any XBRL instance to the Evidence Package and it returns a battery of HTML files.  Here is that battery of reports for the Reference Implementation of an SEC XBRL Financial Report which I have been maintaining for several years now. (This is where you can grab the XBRL files for that reference implementation.)

I was able to convince XBRL Cloud to use the report level semantic model I gleaned from SEC XBRL financial filings and summarized in the Financial Report Semantics and Dynamics Theory. As you look at the Evidence Package, notice how you see virtually no XBRL technical syntax. The information is very readable and understandable to accountants.  There are a few things you need to understand like the terms of the Financial Report Semantics and Dynamics Theory like "characteristic", "fact", and "component" and some US GAAP Taxonomy/SEC filing terms such as "Network", "Table", "Axis", "Member" and so forth, but you need to understand no such XBRL technical syntax.

If you want to understand the report level logical model articulated by the Financial Report Semantics and Dynamics Theory and determine for yourself, looking through this Evidence Package is the way to do it.  And like I said, every one of the 8000 or so 10-K and 10-Q SEC XBRL financial reports fits into this model.  Report level semantic errors in filings do exist and the illogical nature of the modeling is clear. For example, what does it mean to have a [Member] within a set of [Line Items]? That modeling error stands out clearly.

The narrative and videos of ten key areas of the Evidence Package helps you understand how to use the Evidence Package and helps you see how helpful it is.

(Video viewing tips: The videos seem to appear best if viewed in a Safari browser.  The best size is the medium size offered by YouTube. Sorry about the quality, this is the best my tools allow.)

1. Clarity as to your responsibility. The Evidence Package helps you see exactly what you are responsible for by summarizing both automated and manual verification tasks into an understandable dashboard and a list of each automated verification rule you must pass and manual verification task you must perform.
2. Seeing all the pieces clearly. Often, just trying to read reported information can be a challenge.  The SEC leaves off certain information from renderings as one example.  But the Evidence Package provides 100% of all relevant information and the ability to drill down into each and every relevant property.
3. Utility of component view. Rather than providing long lists thinks like validation rules, models, and other pieces which you then must refer to; the Evidence Package takes each of those very useful lists and provides them organized by component.  This component view is extremely helpful in verifying that each component of your financial report is correct.
4. Helpful, specifically focused reports. Special purpose, focused reports help you perform common verification tasks.
5. Seeing 100% of all relevant properties. Seeing all the relevant pieces is 90 percent of the battle when it comes to making sure your SEC XBRL financial filing is correct.
6. Seeing all the business rules. Automating verification tasks such as determining that mathematical computations are correct can save lots of time.  But, to automate these verification tasks, you need to create the rules.  Also, seeing the rules and component together is helpful in determining if in fact a necessary rule has been defined and if that rule is successfully passed.
7. Quickly scanning characteristics using fact table. Fact tables are very helpful tools for scanning a component to be sure things are consistent where they should be consistent.
8. Terminology understandable to accountants. XBRL technical jargon is not something that an accountant needs to understand.  Software should be built to hide that ugly terminology.
9. Seeing that categorizing report elements is helpful.  Report elements can be categorized or grouped and those groups can be leveraged to make many things easier to understand and tasks easier to perform.
10. Providing you piece of mind with a dashboard of verification status. A dashboard of green tells you that things are good to go!

Like I said, the Evidence Package is not necessarily perfect.  But for a version 1.0, it is extremely helpful and a good sign for accountants trying to tame the XBRL beast.  I find that this tool is very helpful in helping me understand if the digital financial reports I create are created as I desire them to be created. I was able to detect issues in my reference implementation which had gone undetected prior to using this tool.

If you want to understand the underlying model or other details, please read Digital Financial Reporting, a resource I put together to explain the report level model being used in detail.