Digital Financial Reporting

ModelDriven.org is a resource for those interested in a model-based approach to working with business information.  ModelDriven.org describes itself on its web site as:

ModelDriven.org a new community of government, commercial and university members who use, develop and integrate open source and commercial capabilities to enable agile business solutions based on model driven methods and technologies. ModelDriven.org is standards based, leveraging Model Driven Architecture® as defined by the OMG and the Semantic Web as defined by W3C. This community has both a user membership and a provider membership.

This is what ModelDriven.org says about model driven architectures (emphasis is mine):

The model driven approach is the cornerstone of ModelDriven.org. Model Driven technologies include architecture, modeling and ontologies that capture knowledge about our business, our environment, our information, our processes and our supporting technologies. The Model Driven approach is able to integrate this knowledge into views of our enterprise or communities that provide the right information to the right stakeholders at the right time. Besides providing information, the Model Driven approach gets more value out of that information by being able to use it to support automated processes, technology development and re-purposing. Model Driven solutions are more technology independent, more agile and less expensive.Being able to utilize the Model Driven approach makes our organizations more agile, more efficient, and less costly to operate – in short it enables the transformation to a better enterprise. ModelDriven.org is developing both open source MDA tools and models.

The American Institute of Certified Public Accountants (AICPA) released an exposure draft, Audit Data Standards, which I believe is very much on target. The topic of audit data standards is not really that "sexy", even less sexy than XBRL in general which tends to make most people's eyes glaze over. But these audit data standards are important at a number of levels.

Two people, Eric Cohen and Gianluca Garbellotto both of whom are named contributors to this exposure draft, have been focused on this topic for years. Their work with XBRL Global Ledger will help users of this standard realize even more benefit from digital financial reporting.

Here is why I see these audit data standards important:  They are part of the "glue" which ties a financial report to the business systems which contain the information.  Let me explain.

Years ago I was an auditor with the international firm which was called Price Waterhouse at the time (now PricewaterhouseCoopers).  As an auditor, I got to see how companies closed their books and generated their financial statements.  All the companies were doing the same thing, but each did things in slightly different ways.

When I left public accounting for my new role as the person responsible for generating financial reports, I remembered all that I had seen and synthesized what I learned into my approach to getting the financial statements out.

I did not have a name for it back then, but I eventually ended up calling what I had created a "closing book".  My closing book was a set of Microsoft Excel spreadsheets, Microsoft Access databases, and queries which tied the spreadsheets, databases, accounting system, and other odds and ends together.

The system only worked within the local network I was connected to (there was no Internet at that time), it was brittle and would not scale because I am not a very good programmer, and there were other shortfalls within the system I had created; but it was better than doing all this manually and it worked.

A fundamental piece of this system was the Excel spreadsheets.  These spreadsheets organized all the information which ended up in the financial statements as I learned how to do it as an auditor.  Basically, these schedules were high-quality, well organized audit schedules which I learned to create as an auditor with Price Waterhouse.

Here is an example of the schedule which I had to support all the information related to long-term debt (click on it to see a larger screen shot):

Long-term debt related supporting information (i.e. audit schedules)

If you look at this you will notice that it has a list of debt instruments, information about each debt instrument, information about the maturities of each debt instrument, the interest accrual, and so forth.  (Remember, this is a prototype, there is more information.)

What if:

• Rather than organizing this information using a proprietary tool such as Microsoft Excel, the information was organized within a global standards such as XBRL?
• Rather then linking the information together using the cells of a spreadsheet, the information was linked semantically using the concepts of XBRL Global Ledger, the US GAAP Taxonomy (or the IFRS taxonomy), etc.
• Rather than expressing the business rules as Excel formulas, the business rules where expressed using XBRL Formula so that the business rules could be shared along with the information
• When the information was changed, that change would flow through the entire "web" of linked information, updating all the information for that change
• The links were both to internal information which exists within your organization, but also to external (with the appropriate security) information which supports the information contained in or which supports the financial report.

Said another way, what if the entire process of creating a financial report was not woven together using inconsistent information formats and droves of overworked, expensive, highly-skilled accountants re-keying and re-footing and otherwise "ticking" and "tying" everything together; but rather more standard information formats where used, what supported the information for the accountant creating the information, the internal auditor reviewing what was created, the external auditor providing independent third-party review of that information, and other views where just different views of the same information?

When people talk about paving the "last mile" of finance, it is things like the audit data standards envisioned by the AICPA which will contribute to making this vision a reality.  These audit data standards are directly related to digital financial reporting, the end product or external financial report.  The audit data standards will let you do things like navigate from the financial report all the way back to the source information in whatever system that information came from.  You can see every business rule used in the journey that information took.

More specifically, I see these audit data schedules as a set of semantic spreadsheets which are all hooked together using additional semantics such as business rules which enables information to reliably flow throughout that entire system, whether a piece of that system is internal or external (i.e. say a regulator) to your organization.  Basically an "information supply chain".

This is not some "Star Trek" type fantasy, this is the power of standards.  Think of what life would be like without the universal product code (UPC).

A milestone of 75 disclosure templates has been reached. This creating these disclosure templates is a lot of work, but as you might imagine one learns a great deal from the exercise.

One thing I am discovering is that good models produce good renderings from good rendering engines. I am looking at these disclosure templates using the renderings of the SEC viewer, CoreFiling Magnify(a document review application), and the XBRL Cloud Viewer(the same application used by the XBRL Cloud Edgar Dashboard).

I distill "good model" down to the following essence:

• Model the information, not the presentation
• Use good, meaningful labels
• Create logical, usually smaller, pieces which go together (as opposed to packing a bunch of reportable information into one big piece which is usually not logical, which might go together in the presentation but is logically separate pieces)
• There are WAY, WAY more business rules than I anticipated (this is a good thing, it helps you verify that you modelled the information correctly)

As I mentioned in another post, I found an SEC filing (Google) which had the characteristics of a good filing.  Well, there are others. For example, FERRO CORP (their XBRL instance, their documents on the SEC web site) is another generally good modeling.

Take a look at both of these filings using the SEC viewer, Magnify (ask CoreFiling for a 30 day trial), or XBRL Cloud (see Ferro Corp here, Google here). 

Also, if anyone is aware of other publicly available viewing software please let me know about it.

There is another discovery or realization.  The SEC viewer does not allow you to "pivot" the information reported by an SEC filer.  Both the XBRL Clould viewer and the CoreFiling Magnify viewer do allow you to pivot the information. 

I would say that upwards of 80% of well modeled information looks good on the first rendering that you see from all three of these rendering engines.  If the rendering is not what you want, the CoreFiling and XBRL Cloud applications allow you to "tweak" the rendering by pivoting it, you can configure some options.  That gets the number of financial report components which look good upwards of 95% or so.  You cannot do this with the SEC viewer unfortunately.  Maybe some day, maybe not.

I would speculate that the software can be improved and get the good renderings in the neighborhood of 98%, maybe higher, for good modelings.  But, there are there are four specific issues that I see here:

1. Document of record: Is it the right thing to do to allow users of financial information to render the information in different ways than the creator of that information created it?  Frankly, you cannot stop an investor or analyst from doing this; but is it the right thing to allow from the SEC public company filer's "document of record".  Personally, I don't have any problem with this but I would be the first to admit that I don't understand all the legal or societal issues. Another way of saying this is that different users of the same information will have different views of the information using different software applications.  Is that a good thing?
2. Not 100% readable:  In an HTML filing, PDF, or some other "presentation" oriented format, the information is 100% readable.  The format is also "locked" (i.e. #1 above).  So, if you cannot read 100% of the information, what good is the filing?  It does not seem that we could live with 98% of the information rendering in a usable format.  It really needs to be 100%, all the time.
3. Difference between "Readable" versus "Pixel perfect" renderings: There is a difference between "readable" and "pixel perfect" renderings.  What is the required target?  Users are use to pixel perfect.  Will they accept readable renderings in exchange for the ability to pivot information, easily load information into analysis software, etc.? 
4. Lots and lots of pieces: Presentations organize lots and lots of small models into logical pieces, presented for easy consumption.  If you look at the Google and Ferro SEC XBRL financial reports, they are readable, but there are lots of pieces and you have to work a little harder to relate some of the pieces how you want them related.  On the other hand, software can help you navigate through the many small pieces and put the pieces together in way, way more presentations than you could the one single HTML rendering.

What will be acceptable to the creators and users of this information?  How much better can software tools do to fill some of these gaps in usability?  Will the trade-offs be understood by both creators and users of this information?

Time will tell.

Bye, bye XBRL technical syntax; hello report level semantics! Well actually, the XBRL technical syntax is not going away, it will just be hidden behind easier to use business report semantics.

Who will be the first software vendor to make the leap?

I created a mapping from the SEC XBRL financial report model to XBRL International's public working draft XBRL Abstract Model 2.0. You can see a PDF of that mapping here.

Mapping from SEC Reporting Model Semantics to XBRL Abstract Model 2.0 Semantics

In that same PDF I also did a mapping from the Financial Report Semantics and Dynamics Theory semantics to XBRL International's XBRL Abstract Model semantics.

Mapping from Financial Report Semantics and Dynamics Theory to XBRL Abstract Model 2.0 Semantics

If you go to section 6 Secondary model - Financial Report Logical Model you will see a UML diagram which maps an SEC Filing to the XBRL Abstract Model 2.0.  The diagram is rather rough, but there are some interesting tidbits of information which you may find interesting.  I will dig into those later perhaps.

I want to point out a few statements from that XBRL Abstract Model 2.0 public working draft:

• Section 1.3 Model vs. meta-model: "... it is important to understand the distinction between modelling and meta-modelling. Whereas a model is typically a representation of some phenomena in the real world, a meta-model is more concerned about describing and defining the actual modelling framework that is used to construct the model."  (So it seems to me that: the XBRL Abstract Model 2.0 is actually a meta-model; the US GAAP Taxonomy is meta-data; SEC XBRL financial filings are the actual models)
• Section 1.3.1 Domain modeling: "However, it is anticipated that instances of this meta-model will eventually be created to communicate how XBRL has been applied in specific projects and taxonomies."  (Meaning: people who build XBRL taxonomies need to explain their models by mapping them to this XBRL meta-model.)
• Section 1.4 Layered modeling: "the Primary Layer - captures the pure semantics of XBRL and thus, as much as possible, is independent of the XML syntax" and "For this reason, the reader should be aware that syntactical artefacts of XBRL (such as Contexts, Arcs, and Locators) do not appear in this model as they have been considered to be artefacts of syntax rather than having any semantic significance."  (Semantics matters, not syntax)

There is a lot of technical stuff in this document.  But, there are some key definitions you should care about. These are the key definitions from the XBRL Abstract Model 2.0.

• Model element: named elements or objects or classes of the meta-model.
• DataPoint: defines a reportable item of business information.
• Aspect: defines an identifying or describing characteristic of a business information item data point.
• AspectValue: defines a specific instance of a value of an Aspect.
• Relationship: defines a logical relationship between pairs of Aspects, AspectValues, DataPoints, Resources, and between Aspect and AspectValue, Aspect or DataPoint and Resources.  (They seemed to have left out relationships between Cubes, or the sequence/ordering of Cubes.)
• Manifest: defines what is packaged in the Document. (I don't quite get this, does not seem like 'document' is defined well enough, or it is syntax.)
• Cube: defines a collection of CubeRegions that are associated with specified aspects to report. (Note that I do not believe that they mean "aspect" as defined above when they use "aspects" here. Could be wrong.)
• CubeRegion: defines a cartesian product, or set of Aspects, of enumerable AspectValues (corresponding to XBRL hypercubes after subtraction of negative hypercubes from positive hypercubes).  (This is a mouth full.  Eyes glazing over.  Don't quite get this.  It may be an irrelevant technical detail, business users may only need to understand what a Cube is.  Frankly, I don't know at this point.)

I had a number of requests for XML Schemas which explained the XML Infoset files which I use to work with XBRL.  Well, here is a first cut.  Note that I have had two different versions of terminology which I was using, I am transitioning to a new third format which syncs a bunch of things together.

These are DRAFT versions of the XML Schemas (I hope to have the final version within one to two months along with RDF/OWL ontologies which explains these and some other things:

• Model structure: http://xbrlsite.com/DigitalFinancialReporting/Schemas/ModelStructure.xsd   (note that this was called the relations infoset)
• Fact table: http://xbrlsite.com/DigitalFinancialReporting/Schemas/FactTable.xsd
• Report elements: http://xbrlsite.com/DigitalFinancialReporting/Schemas/ReportElements.xsd
• Business rules: (to do)

If you want to understand this stuff more, please refer to the "Digital Financial Reporting" page of my blog.