BLOG:  Digital Financial Reporting

This is a blog for information relating to digital financial reporting.  This blog is basically my "lab notebook" for experimenting and learning about XBRL-based digital financial reporting.  This is my brain storming platform.  This is where I think out loud (i.e. publicly) about digital financial reporting. This information 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.

Entries from April 1, 2014 - April 30, 2014

Free Idea for Software Developer: Semantic Level Diffing Tool for Digital Financial Reports

So here is one of about 50 different software products that I can think of related to digital financial reporting.  And you need not understand anything about XBRL.  Nothing.  What you do need to do is understand financial reporting or know someone else who does.  A deep understanding of digital financial reports such as SEC XBRL financial reporting helps.  Note the word deep. That will help you understand priorities. 

If you are familiar with the 28msec SECXBRL.info API or the XBRL Cloud Edgar Report Information API, you can see that you DON'T have to build everything from scratch and you DON'T need to understand XBRL.  Just go look at the model structure and the fact tables on either, that is a great starting point.  As I understand it, you can also generate those infosets using the open source Arelle XBRL processor. But frankly, when you can simple grab the XML from a web service, why not just do that?

To be clear I am pushing two things: (1) Don't build everything from scratch, (2) semantics matters, not syntax.  Also, I am not pushing any specific web service, I am pushing the notion of using web services as opposted to building everything from scratch. (If you have a web service similar to XBRL Cloud or 28msec please make me aware of it.)

So here is the idea.  Imagine a "diffing" tool.  Not a syntax level diffing tool (but that could be useful for some things also), but rather a semantic level diffing tool.  Did the model structure change and how?  Did the fact table change and how?  Did a label change, new label added, label deleted, stuff like that.

Business users don't care if the syntax has changed, unless the syntax change impacted the meaning conveyed by the digital business report. Also, many times you don't need to compare the entire document, you want to compare things at the report component level.

Here are some very specific use cases as to how such a semantic diffing tool would be beneficial and how it would be used by business users:

  • By an accountant who is involved in the process of creation of a filing, comparing versions of the same filing at say 2 PM with a version that he/she generated at 4 PM to see what exactly changed in the document.  They will want to see if what they expected to change DID change and areas of the report which were NOT expected to change to be sure they did not accidentally change something.
  • By an internal auditor, third-party auditor, or the manager of an accountant in the creation process to REVIEW the work someone else has done to again understand exactly what changed.
  • By an external reporting manager or accountant to compare say a Q1 filing with a Q2 filing to see EXACTLY what changed.  This is particularly useful when a filer changes software vendors or filing agents.
  • By an external filing manager, third-party auditor, internal auditor to compare a report component of their filing to the report component of one of their peers to see which concepts were used, which axis were used, etc.  Generally, one would compare at the report component level, not the entire filing.  Comparing at the filing level would induce unnecessary noise which the accountants have to sort through.
  • By an external filing manager, third-party auditor, or internal auditor to see what verification or business rules have changed, if some other relation changed.

What would be particularly useful would be to see the semantic changes within the context of a rendering. Seeing what changed in context is significantly better than having to hunt around and find the context.

A digital financial report is made up of many, many discrete identifiable pieces. If you understand those pieces, if you understand the relations between the pieces, if you understand the important properties of those pieces; then writing a diffing tool is not that complicated.  Well, if you are a programmer.  You can see those pieces in those infosets.  Again, go look at the model structure, go look at the fact tables.  Neither of those is that complicated.

I would encourage any software developer who wants to create a nice little business for themselves or who wants to create something they might want to sell to XBRL Cloud or 28msec to fiddle around with those web services and see what they think.  If you are really serious about creating something, I might be convinced to help you spec out the application.

I even built my own taxonomy comparison tool (prototype) which works with the XBRL Cloud web service.  As you can tell from looking at the tool, I am not a programmer.  Otherwise, I would build this diffing tool myself.

This is a bit of an experiment to see what happens.  Will help me understand what to do with the other 49 ideas!  Do you have any product ideas?  Either 28msec or XBRL Cloud or both for that matter might be a great platform to distribute your product ideas.  Or, find some other web service.  Just don't be foolish and build everything from scratch.

There are lots of different digital financial reporting products which are necessary for accountants creating, reviewing, auditing, or otherwise working with digital financal reports.

Posted on Tuesday, April 29, 2014 at 10:58AM by Registered CommenterCharlie in | CommentsPost a Comment | EmailEmail | PrintPrint

Data Act Passed by Both Senate and House

The Data Transparency Coalition has been working to get The Digital Accountability and Transparency Act, or The DATA Act, passed by congress.  They have achieve that goal with both the house and senate passing the bill unanimously. President Obama is highly likely to sign this bill into law.

"Agencies usually do not and cannot tell us how much taxpayer money has been spent on any given program," said Rep. Issa on the House floor shortly before securing the bill's passage. "The American people deserve to know if their taxpayer dollars are being wasted or whether they are being spent wisely."

The next step is implementing this idea correctly, making The Data Act work for the taxpayers.  It needs to work significantly better than SEC XBRL financial filings.  From what I can tell, this is what it takes to make this digital reporting work correctly.  I hope those implementing The Data Act learn from the mistakes of the SEC rather then repeat those same mistakes.

While XBRL is in the running for the global standard format to use, there is competition. The Government Linked Data (GLD) Working Group got started a number of years ago. They have a Data Cube Vocabulary specification. Truth be known, syntax does not matter.  Each syntax has its pros and cons.  Digital business reporting is coming!

Nice work Data Transparency Coalition!

Posted on Tuesday, April 29, 2014 at 07:11AM by Registered CommenterCharlie in | CommentsPost a Comment | EmailEmail | PrintPrint

SECXBRL.info (Beta) is Worth Checking Out

28msec has said that it is OK to make people aware of SECXBRL.info (BETA), a repository of US public company financial information, which is a working prototype that they have created.

Be sure that you understand what you see.  There are three important pieces:

  1. SECXBRL.info is both a graphical user interface (GUI) and application programming interface (API) what allows you to make use of public company financial information.  The information comes from SEC XBRL financial filings but the information is not stored as XBRL.  The repository stores the information in a form which is more representitive of the information. That makes the information easier to query.
  2. SECXBRL.info is an instance of 28.io which is optimized for XBRL and customized for public company financial filings.  Want to implement XBRL?  You can do that same thing for any XBRL-based system.  You start with a base which is common to every XBRL implementation and add what is custom to your implementation.  Basically, SECXBRL.info was created in order to figure out the best approach to implementing XBRL more generally and test the implementation to be sure it is working correctly. This is one of the most functional working prototypes that I have ever seen!
  3. If you want more control over your system, use 28.io and implement any architecture you might like or take some existing application profile and tweak it to your needs.  Or, don't want to bother with that? Just use some other application profile as-is, no IT skills needed.  As I understand it you can have a repository up and running in an afternoon and they are working toward a 100% self-service.

Here is some specific information to help you check out what SECXBRL.info can do.  First, this PDF walks you through a bunch of basic query examples. This ZIP file contains an Excel spreadsheetwhich has VBA code which walks you how to use the API in Excel.

Next, here are a handful of things which I find the most interesting and useful about SECXBRL.info.  Many of these are things which I created functionally for which I convinced 28msec to provide.

That is good for now.  I will make more advanced query examples available later.  If there is anything specific that you might want send me an email.

Posted on Monday, April 28, 2014 at 01:05PM by Registered CommenterCharlie in | CommentsPost a Comment | EmailEmail | PrintPrint

Understanding Database/Query Options (Part 3)

Continuing where Understanding Database/Query Options (Part 2) left off...

Looking at all the moving pieces in parts 1 and 2, it seems to me that these are the things business users might care about. Or rather, maybe business users don't care about some of these things but someone who pays the bills cares about all of these.  All these need to be in balance:

  • Easy for business user to use (intuitive): Something should be EASY to use as opposed to HARD to use.
  • Query power and query sophistication: Queries should be POWERFUL rather than UNSOPHISTICATED. (The more you can do, the better, as long as what you can do is useful to you.)
  • Performance, query speed: Performance should be FAST rather than SLOW.
  • Expressive power: The expressiveness of the system should be EXPRESSIVE as compared to INEXPRESSIVE. (The more you can do, the better, as long as what you can do is useful to you.)
  • System flexibility, agility: A system should be FLEXIBLE as compared to INFLEXIBLE.  (Flexibility should be judged by where the user needs the flexibility.  Flexibility in the wrong places causes a system to be harder to use than necessary. Unnecessary options are a bug, not a feature.)
  • System scalability: A system might need to SCALE as compared to DOES NOT SCALE.
  • Global standard: A system might be better if it is more STANDARD than PROPRIETARY.
  • Cost effective: A system could either EXPENSIVE or INEXPENSIVE.
  • Maintainability: A system could be either HARD TO MAINTAIN or EASY TO MAINTAIN.

It has been my observation that may people's expectations are at an inappropriate level.  You have probably heard the saying, "Ignorance is bliss."  Not knowing something is often more "comfortable" than knowing it.  For example, it has been my experience that a lot of people overuse Microsoft Excel for things that are much, much more easily achieved using Microsoft Access.

Not knowing Access does not make Excel better than Access.  What it means is that someone who understands both Access and Excel can be more effective and efficient than someone who knows only Excel, all other things considered.  Frankly, I see people doing extremely foolish things in Excel.

Basing your expectations on what you currently know can be dangerous and limiting.  For example, people who only understand SQL and have never used XQuery and say SQL is better (even though they have never used XQuery) are being foolish.  Why would someone like the W3C go through the trouble of creating XQuery if SQL can do everything that XQuery does?

People tend to agree that data comes in different sorts of structures.  The following is a summary of the spectrum of data or information structures:

  • Unstructured Data: Unstructured data follows no specified data model or structure. The truth is that even unstructured information has some structure. Computers can ONLY deal with information which has been structured.  For example, text tends to exist in a file.  That file is a structure. Text files have mechanisms and techniques for structuring even unstructured information such as line feeds, blank lines, etc.
  • Semi-structured Data: Semi-structured data is a cross between the two. It is a type of structured data, but lacks the strict data model structure.
  • Structured Data: Structured data or highly-structured is data or information that conforms to some rigid data model. For example, data in a relational database is structured data.

What is the right approach?  Well, that seems to depend. Everything in life doesn't always necessarily fit into neat little boxes. On the other hand, life is not totally random either. There are advantages to information which can be formally structured.  There are also advantages to unstructured information.  Each, likewise, has disadvantages.  The trick is to pick the appropriate approach for the specific situation.

People tend to agree that information can be structured for presentation or for meaning.

  • Structured for presentation: HTML, word processing documents, PDF, and believe it or not even electronic spreadsheets are structured for presentation. For example, the sections of a document, a paragraph, a sentence, or the format of a word are all presentation structures.  The workbooks, spreadsheets, columns, rows, and cells of a spreadsheet are presentation structures.
  • Structured for meaning: XBRL is something that is structured for meaning, not presentation.  There is presentation oriented information within the sstructured meaning, such as the XBRL presentation linkbase which communicates the ordering of report elements, etc.

This video, How XBRL Works, walks you through the difference between information structured for presentation and information structured for meaning.

People tend to agree that information is comprised of "things" and those "things" can be related. There are different ways to express those "things" (sometimes called "entities") and the relatinos between the things.

  • Subject-predicate-object: The approach used by RDF is subject-predicate-object. This description enhances this description a bit, Subject (start) - Predicate (connector) - Object (end). The subject and object are both things and the predicate is how the things are related. Things can be related in many different ways.
  • Entity-attribute-value: This approach is very similar to subject-predicate-object.
  • Entity-relations model:  An entity-relationship model is a systematic way of describing and defining a business process.  It seems that subject-predicate-object and entity-attribute-value are approaches to implementing an entity-relations model.
  • Set theory:  Another approach to describing things and relations between things.
  • Conceptual model or domain model: It seems that a conceptual model is a general notion that a model is anything used in any way to represent anything else.  This is a great description of what a conceptual model is: "Conceptual modeling is the activity of formally describing some aspects of the physical and social world around us for the purposes of understanding and communication."

The "things" that you are working with are commonly grouped into three different "levels":

  • Conceptual model: High level description of how something in the real world works
  • Logical model: Lower level desciption of the conconceptual model
  • Physical model: Details of how the logical model is implemented using some technology.

 

Posted on Monday, April 28, 2014 at 11:12AM by Registered CommenterCharlie in | CommentsPost a Comment | EmailEmail | PrintPrint

Understanding Database/Query Options (Part 2) 

Continuing on from where I left off in Understanding Database/Query Options (Part 1)...

People tend to agree that there are different types of databases. Another term for this is DBMS (database management system) or database or database model. Now, keep in mind here that you have databases and you have modeling approaches used by databases.  These are different.  For example, a relational database can use a multidimensional approach to representing information within that that database.

  • RDBMS: Relational database management system, which is a database based on the relational model or set theory. The relational model is a two dimensional structure: rows and columns. (Note that you can use a multidimensional structure in a relational database.)
  • Hierarchical database: A hierarchical database management system is a system which follows the hierarchical model.
  • Object database: An object database is a database management system in which information is represented in the form of objects (follows object model), similar in approach to how objects are used in object-oriented programming.
  • Network database: A network database is a database management system which follows the network model.
  • Multidimensional database: A multidimensional database or multidimensional engine is a system which is fundamentally to work using the multidimensional model.  (i.e. this means it is not a relational database which is then structured to mimic the multidimensional model (explained here), it inherently uses the multidimensional model; this video explains the difference)
  • NoSQL database: A NoSQL (not only SQL) database provides a system which is based on an open data structure (e.g. tree, graph, key-value, document) which is generally something other than tabular (nothing really prohibits the use of table like structures).  Basically, a NoSQL database is very flexible and you have to manage the structure yourself. (For more information on NoSQL databases see here, here, here, here, here)
  • Triplestore: A triplestore or RDF triplestore is a purpose-built database for the storage and retrieval of triples, such as RDF, which is a graph of subject-predicate-object relations.
  • Flat file database: A flat file database is a system where in essence one or more files are used to store data.
  • Linked data: Linked data is basically seeing the entire internet as a database. So the "system" is the internet itself.

People tend to agree that the categories of processing of information can broken down into at least two groups: (this presentation compares and contrasts OLTP and OLAP)

  • OLTP: Online Transaction Processing, transaction oriented where the system responds immediately to user requests.
  • OLAP: Online Analytical Processing, an approach to answering multi-dimensional analytical (MDA) queries swiftly

OLTP is what relational database did when they were first created.  OLAP was invented as an approach to making analysis of information, many times from OLTP systems data, easier.  OLAP uses the notion of "cubes".

OLAP can be broken down into categories also:

  • ROLAP: Relational OLAP which stores information in a relational database.
  • MOLAP: Multidimensional OLAP which store information in a multidimensional array rather than a relational database.
  • HOLAP: Hybrid OLAP which combines the best of ROLAP and the best of MOLAP, allowing a tradeoff of the advantages of each
  • NOLAP:  The term NOLAP means NoSQL Analytical Processing or NoSQL OLAP. NOLAP uses NoSQL and XBRL to express cubes which do what OLAP does but have fewer constraints.

There seems to be a couple of other data cube models: (data cube)

  • RDF Data Cube: The W3C published a data cube model. That cube model states, "The model underpinning the Data Cube vocabulary is compatible with the cube model that underlies SDMX (Statistical Data and Metadata eXchange), an ISO standard for exchanging and sharing statistical data and metadata among organizations."
  • SDMX: The RDF data cube references this SDMX cube model as mentioned above.

Ran across a few things which I want to investigate further relating to semantic model:

Most of what I have pointed out so far in Part 1 and Part 2 are facts which few people tend not to dispute.  Some people might add something to a list, change a term, or maybe even remove something from the lists that I have provided.  When you have to choose something from a list, then things change.  There is an interesting phenomenon that I have noticed when one tries to select something on the list.  Specific software vendors always have "the best solution".  Always! It is unreal.  I don't think I have ever run across a software vendor who says, "Yeah, sounds like you need a multidimensional database based on what you are describing and we sell a relational database type system..."  You ever have that experience?

Hadoop is a set of tools for working with "big data".  Hadoop is open source and based on Linux; the direction of Hadoop is not determined by any software vendor.  This video explains hadoop. This also explains hadoop.

Gotta walk the dog again...Guess there will be a Part 3.

Posted on Sunday, April 27, 2014 at 07:25AM by Registered CommenterCharlie in | CommentsPost a Comment | EmailEmail | PrintPrint
Page | 1 | 2 | 3 | 4 | Next 5 Entries