What were your biggest challenges when switching to Inline XBRL (iXBRL)?
Switching to inline XBRL if basically effortless. The biggest hurdle with Wdesk is managing any phantom tagging and looking to consolidate those back into the document if possible.
The biggest problem we had when moving to inline XBRL was with our Auditors. It has been my experience that the Big 4 audit firms are not very experienced with XBRL and given Audit firms are not yet required to audit XBRL tagging, they tend to push back on using inline XBRL until the SEC makes it mandatory and issues guidance as to what independent auditors are responsible for in their opinions. Our auditors let us do it for the 2017 10-Q's but were initially reluctant to let us file the 10-K.
After some intensive negotiations KPMG suddenly changed their view and were all in. They never said why the change in opinion, but maybe the SEC issued additional guidance for them, but I have not seen anything on the SEC site that addresses it. I am a big fan on inline XBRL as it is basically a built in disclosure checklist within the document.0
Hi Dave- We are looking into transitioning to iXBRL. Can you elaborate on what you mean about managing the phantom tagging? Do you mean being able to double tag a number in the document and therefore being able to delete the non-printing/phantom sections? Thanks!0 Yes, phantom tags are not viewable in iXBRL. Also you will get a warning when you file with SEC and will list the number of items affected. This is not a big deal as they can be viewed in the xbrl viewer on SEC site. It just made me take a closer look at our phantom tags and as a result I was able to limit the number of Tags we had. I believe the SEC is working on fixing this and eliminate the warnings. I would not recommend eliminating the phantoms if they are required, I would just recommend reviewing them to make sure they are all needed.0 The biggest issues we came across were ISO periods (i.e. "PY5" for 5 years) where the display format requires words (i.e. five-year notes). iXBRL doesn't like them and they have to be phantomed on a nonprinting section if you're not willing to forego the word format). iXBRL also sees duplicate facts where there are none in cases where the difference is merely rounding ($5,432 in a table linked to paragraph language where that same number reads "$5.4 million") and finally with some negated facts. My recommendation is to convert to iXBRL very early in the non-filing period, such as right after a filing using regular XBRL. When you roll the project and dates, convert to iXBRL and immediately generate XBRL in the project for a "baseline" XBRL version to assess whether there are any of these types of compatibility errors. That'll give you enough time to address them. As other users indicated, many of these compatibility errors can be cleared with phantom tags in a nonprinting section.1
Please sign in to leave a comment.