Bleed-through is a common phenomenon on the SEC’s XBRL Viewer, as well as on RDG’s own Thunderdome® Viewer (which was designed to resemble the SEC’s Viewer, but with more information and features). To explain it in a nutshell: Bleed-through is a natural result of how the SEC’s Viewer interprets XBRL code. It is both normal and expected by the SEC.
Below is a common example of bleed-through. The first table presented is directly from the company’s EDGAR document (it’s from a disclosure table in Note 1). The second is the same table, but how it is presented in the SEC’s XBRL Viewer.
The difference in the XBRL Viewer is the addition of the first line, “Net trade income (loss).” Plainly those “Net trade income (loss)” numbers do not ‘belong’ in the Note 1 disclosure table.
So, why are they there? Well, the short-answer is that due to the nature of XBRL and the function of the SEC’s XBRL Viewer, the numbers are “bleeding through” from the Operations Statement. You can see that table from the EDGAR document here:
The longer answer is that both the “Net trade income (loss)” line in the disclosures table in Note 1 and the “Net trade income (loss)” line in the Operations Statement are tagged with the same primary concept (us-gaap_NetIncomeLoss). However, only the occurrence of that concept in the Note 1 table has had a dimension applied to it.
This bleed-through issue is not symptomatic of a problem with the tagging. This document is tagged properly and it is entirely in line with the SEC XBRL requirements and FASB best practices. The bleed-through is a direct result of the SEC’s XBRL Viewer, and to-date, the SEC has taken no steps to correct it.
Here’s what is happening on the SEC’s Viewer: When the Viewer displays any fact that has been tagged with a dimension, the Viewer will also grab and display all other facts throughout the document that share the same tag but that do not include a dimension. In this case, the “Net trade income (loss)” line in the Operations Statement is tagged with the same primary concept as it is in the Note 1 disclosure table, but in the Note 1 table that concept is also dimensionalized. As a result the SEC Viewer presents the “Net trade income (loss)” line from the Operations Statement in the Note 1 table.
This is classic bleed-through, and it has been causing headaches for people reviewing XBRL tagging since the inception of the mandate.
So, can it be fixed? Firstly, it is important to understand that the SEC does not want filers adjusting their tagging simply to make the presentation in the XBRL Viewer look better. The reality of XBRL is that it is not intended for human consumption. It is designed to make Financial Statements & Notes machine-readable. When XBRL is tagged properly – each fact stands alone, free of the original document, getting context only from its own tag, date, and any dimensions. From a “machine-readable” point of view, it does not matter where in the document the fact is located, so long as it is tagged correctly. This is why the SEC did not build the Viewer to present the XBRL in an entirely human-readable format. It is also why the SEC expects to see bleed-through, and does not consider it an issue.
The actual issue is when some filers attempt to “fix” bleed-through by adjusting the tagging with the presentation in mind. We do not recommend these sorts of “presentation fixes” because they often contradict SEC guidelines and FASB best practice. So in the case above – as with almost all bleed-through cases – we simply leave it be. It is tagged properly, and it is machine-readable. The SEC wants it tagged this way, and they expect the bleed-through that results.
