Lessons Learned from Teaching XBRL
Sometimes you have to forget a lot to learn a little. In my six years working with XBRL, I've provided instruction to scores of engineers and financial reporting specialists inside filing companies, as well as in services firms building XBRL practices. Here are three conclusions I've reached about the task of teaching XBRL itself.
- Your enthusiasm is no substitute for theirs.
The adage “You can lead a horse to water, but you can't make him drink” certainly applies. You have to find out why each person is there and what will be expected of them when they complete the training and return to their job. Then you must help the student clearly frame these objectives, so you both may keep connecting the training to these objectives.
This helps you keep student's interests first and foremost, and select material that is relevant to their objectives. Your respect for their situation encourages their enthusiasm.
- It is easier to teach external reporting people about XBRL than technical people about financial reporting.
It would be great if all financial reporting people possessed an engineer's comfort with data abstractions. Fortunately, financial reporting people can make up for this through practice, and they come with all sorts of great examples with which to practice. It is this domain knowledge and their practical needs that provide the basis for connecting them to the theory, to the technology, and to its use. Often, financial reporting specialists have to forget some of their paper-based reporting methods to be successful with the move to XBRL.
The statement of cash flows provides a good example. This statement is challenging because it requires understanding calculation weights and their relationship to balance types—those balance types have a meaning that is independent of the particular statement in which the fact resides and the use of negated labels to control the presentation of the fact. The technical features of balance type for elements, calculation weights, and negated labels also play a part on the balance sheet, but it is the circumstance of shared facts between the statement of income and the statement of cash flows that makes these features not only necessary to use but also necessary to understand.
It isn't uncommon to see XBRL novitiates create reports with duplicate facts: a positive version coming from the statement of income, and negative version from the statement of cash flows. In explaining this to students, I keep in mind that they need explanations grounded in their work rather than in my technology. I must understand their insistence that a particular facts “is positive on the statement of income, and negative on the statement of cash flows.”
Then, I can help them understand it in their terms such as these: It may be that the visual value of a fact needs to be reversed or have its sign flipped to comply with the calculation weights. It is very common that the visual presentation of a number is reversed to support the simple sum presented in the printed document. But these values need to be reversed as XBRL facts in order to represent the correct meaning of the financial reporting fact (as defined by the XBRL concept used to represent the fact). These changes to flip the sign are always accompanied by a negated label to flip it back for the visual presentation. This combination insures that the value has the correct sign for its meaning, but also is displayed with the sign that is appropriate for its visual presentation in the particular outline being presented.
It is with the statement of cash flows that these external reporting experts recognize that there is more to reporting in XBRL than just finding tags. Domain knowledge is a necessity, but so is forgetting the restrictions imposed by paper reporting. I've found that business users respond positively to my assertion that, “if you can read a taxonomy, you can define a taxonomy.” These collaborations between practice and theory make it easier for them to learn and provide endless useful examples. Because business users know what is to be modeled by XBRL, they have a leg up on learning how the models work and a reason to learn.
- We must focus on making training easier for business users.
The best one can hope for in teaching engineers about XBRL is that they learn how to assist domain experts in building XBRL filings. In contrast, the best one can hope for in teaching financial reporting specialists about XBRL (given appropriate software for these business users) is to independently build and maintain their filings. This is a necessity for financial reporting people.
Therefore, the software we design and build should do more than just make something possible. It should also be designed to be teachable and learnable by those folks most dependent upon it (i.e., business users). Training is not the answer when dealing with unnecessarily difficult software. That's why I recently moved from a consulting practice focused on “getting the job done,” to an employed position where I help make it a job easier to do.
As teachers, we should have some professional obligation to make the subject matter easier to learn. For me, that means forgetting about technology for its own sake, and instead remembering that the people who use it have to get their jobs done. *Originally published on the [Hitachi Data Interactive website.](http://hitachidatainteractive.com/2011/02/03/lessons-learned-from-teachi...)*