Sometimes you have to fet a lot to learn a little. In my six years working with XBRL, I’ve provided instruction to sres of engineers and financial reporting specialists inside filing mpanies, as well as in services firms building XBRL practices. Here are three nclusions I’ve reached about the task of teaching XBRL itself.

1. 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 mplete the training and return to their job. Then you must help the student clearly frame these objectives, so you both may keep nnecting 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 enurages their enthusiasm.

2. 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 mfort with data abstractions. Fortunately, financial reporting people can make up for this through practice, and they me with all sorts of great examples with which to practice. It is this domain knowledge and their practical needs that provide the basis for nnecting them to the theory, to the technology, and to its use.

Often, financial reporting specialists have to fet some of their paper-based reporting methods to be suessful 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 ntrol 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 inme and the statement of cash flows that makes these features not only necessary to use but also necessary to understand. It isn’t unmmon to see XBRL novitiates create reports with duplicate facts: a positive version ming from the statement of inme, 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 inme, 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 mply with the calculation weights. It is very mmon 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 rrect meaning of the financial reporting fact (as defined by the XBRL ncept used to represent the fact). These changes to flip the sign are always acmpanied by a negated label to flip it back for the visual presentation. This mbination insures that the value has the rrect 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 regnize that there is more to reporting in XBRL than just finding tags. Domain knowledge is a necessity, but so is fetting 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 llaborations 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.

3. 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 ntrast, 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 nsulting 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 fetting about technology for its own sake, and instead remembering that the people who use it have to get their jobs done.