Digital Financial Reporting

The FEI published a survey, SEC Reporting and the Impact of XBRL: 2012 Survey, which I believe exposes an opportunity for CPAs and other accountants who truly understand how to articulate financial information using XBRL and to software vendors who have products usable by accountants and other business users involved in the process of creating SEC XBRL financial filings.

The following are the highlights of the FEI survey:

• Companies across the board expect to take greater responsibility for their XBRL filings, with the percentage of respondents not planning to outsource XBRL at all over the next year increasing and the respondents planning to use full outsourcing over the next year decreasing.
• Respondents across the board projected increasing both the size of their XBRL team as well as the level of internal XBRL competency.
• XBRL is not expected to delay reporting calendars. The vast majority of respondents expect to file in line with the time frame of previous filings or faster.
• XBRL was the most often mentioned SEC reporting bottleneck.
• The biggest concern raised regarding XBRL compliance was to question the cost - benefit proposition of the XBRL mandate.

Notice the terms "bottleneck" and "cost - benefit proposition".  Another opportunity for CPAs and other accountants with the appropriate knowledge of how to express financial information properly using XBRL is to help software vendors make their software usable by these business users.

With all the SEC XBRL financial information of public companies available over the Internet and with the quality of software for business users such as accountants to understand SEC XBRL financial filings improving, it will be very easy to differentiate between high quality and poor quality SEC XBRL financial filings.

With the knowledge of the buyers of software and services is increasing, it will only get harder and harder for those who really are not qualified to express financial information using XBRL well to hide amongst the herd.

Clearly additional pressure will be applied by the SEC who has been complaining about XBRL financial filing quality.

With digital financial reporting being not only inevitable, but imminent; taking the plunge into digital financial reporting seems wise to me.  What will you chose?

Are you building or buying the right software applications?  This presentation, Semantics Overview, helps you understand if you are.

Smart data/applications:

• Knowledge baked in
• New knowledge can be inferred/added
• Agility to adapt to ever-changing conditions
• Semi-automated data integration
• Machine intelligence

I predict that you will see digital financial reporting applications with these characteristics in 1 to 2 years. But, before software applications can work in this manner, they need the right metadata.  The metadata is key to making them work.

These applications will work better than today's legacy software applications for creating financial reports such as Microsoft Word which have no knowledge or understanding of financial reports or financial reporting.  These applications will generate perfectly modeled XBRL output without their users ever having to understand anything about the XBRL technical syntax.

Not only are these types of software applications inevitable, they are imminent.  Like I said, 1 to 2 years.  Seem hard to believe?  Well, I have mentioned these sorts of things pretty much every year for the past 14 years, for example here in 2009.  I sometimes described this sort of application as something like a "modifiable TuboTax" type application for creating financial reports, driven by metadata.

Users won't adopt digital financial reporting and these types of applications because of regulatory mandates; they will adopt digital financial reporting because it is better and easier than today's approach.  Hard to believe given today's XBRL software.  However, once you see this software you will become a believer.

This is what XBRL has always been about; semantic, model based, structured authoring.  The ability to exchange this information between software applications and analysis is a byproduct.

Check out the presentation, decide for yourself, place your bets on the table.

For more information, read the PWC paper on Disclosure Management and the Project10X executive summary.

This information is taken from the TopQuadrant web site, Ontology Development page. I am still trying to understand some of this information.

More people understand CSV files (comma separated values), relational databases, Microsoft Excel spreadsheets, and perhaps even XML for approaches to storing and using information better than they might understand an ontology. (See this blog post if you are trying to understand what an ontology is.)

Ontologies are powering the next generation of software applications. Ontologies are active models of information that are like and unlike other information modeling approaches you may be more familiar with:

• Like databases, ontologies are used by software applications at run time to provide information to the users of the software applications. HOWEVER, unlike databases, relationships in the ontologies are ‘first-class’ constructs, have rich explicit semantics and are used locally or globally because the nature of the information and the syntax of the information can be exchanged between business systems (as opposed to use being restricted to your internal database because the syntax is proprietary or the semantics are hard coded into the software)
• Like object models, ontologies describe classes and attributes (properties). HOWEVER, unlike object models, ontologies are set-based. (I don't understand what this means, I will try and figure this out...watch for a subsequent post.)
• Like business rules, ontologies encode business rules which are basically some formal and implementable expression of a user requirement; HOWEVER, unlike business rules, ontologies organize rules using class structures (they are formally grouped), they are written using a global standard format, which means that the business rules can be effectively exchange between business systems.
• Like XML schemas, ontologies are native to the web and can be serialized in XML; HOWEVER, unlike XML schemas, ontologies are graphs (not trees), can be used for reasoning, an infinite number of explicit relations can be expressed (rather than the one implicit relation of an XML schema).

XBRL is closer to something like RDF than it is to XML Schema. In fact, that is why the elements within an XBRL taxonomy are "flat".  XBRL tried to overcome the limitations of XML Schema by using only parts of it.  This is why tuples in XBRL are so bad for extensibility; they basically go back to using XML Schema.

The XBRL definition relation is similar to RDF-type expressions of information.  Definition relations are somewhat standard in that they use XLink.  But, it does not seem that XLink is catching on.