The SEC’s announcement on the voluntary filing of financial statements in Inline XBRL or iXBRL has sharply thrown the topic on everyones radar. While the filing is voluntary for now, a number of companies are already looking to adopt iXBRL given the time and cost efficiencies. As more and more companies plan their move to iXBRL, there are a few questions that naturally arise on iXBRL tagging.
Since iXBRL is just a modification in file format and not in the underlying rules, the scope of tagging remains the same. But filers do need to be aware of certain aspects of iXBRL tagging to prepare a compliant iXBRL document.
Here is a list of 5 easy Inline XBRL tagging rules to help you master your inline XBRL filing
1. Aligning Value Formats
The HTML report of an SEC filing is defined by each entity’s reporting style and hence varied patterns can be found for the same reporting element. These variations could be in the spellings, letter case, writing style, etc. which are usually standardized while defining the taxonomy. The XBRL taxonomy thus defines the value types or patterns that can be expected for any reporting element to ensure standard and consistent reporting by all entities.
Dates are one of the most common examples where different formats could be adopted by companies in the HTML report, while XBRL strictly requires dates to be represented as YYYY-MM-DD.
Further, some information that is usually descriptive in the source document could be defined as a granular element in the XBRL taxonomy. Either the values for these granular elements (though not directly mentioned in the HTML report) need to be interpreted or are not as per the pattern defined in the taxonomy.
For instance, the HTML states the filer category as Large accelerated filer, while the value expected in the XBRL document is Large Accelerated Filer.
In inline XBRL tagging, the value formats need to be aligned so that when the XBRL data is extracted from the inline XBRL document, it conforms to the format specified in the XBRL taxonomy.
2. Reversing Value Signage
Incorrect signs for values are one of the most common errors found in an XBRL document. This is usually done to make calculations visually clear. For e. g., items of expense such as cost of goods sold, income tax, etc. are shown in parenthesis to indicate that these are deducted to arrive at the next sub-total.
XBRL has the ability to separate the presentation layer from the calculation layer i.e. the way the information is captured for calculation versus presentation. The Edgar Filing Manual rule 6.6.30 states that the sign of a numeric fact should be inverted only when the balance type of the element is inconsistent with the reported concept. However, while preparing an XBRL report, in an effort to replicate the visual readability, this rule is commonly misused.
With Inline XBRL, since the presentation aspect of the report is taken care of, errors due to wrong signage should be significantly reduced, if not eliminated. However, filers should be cautious of scenarios where the sign for the value needs to be inverted and ensure that correct signs are assigned to values.
3. Tagging Invisible Data
Inline XBRL is driven by the source HTML report. There might be instances where data is not shown on the HTML document but needs to be tagged in XBRL so that machines can consume the data. For example, many times the HTML document either contains values only for the current period or mentions the values only once even if they hold true for both current and previous periods. However, the SEC rules may require values for both periods to be reported and tagged in the XBRL document, for instance, when reporting certain numbers for current and previous quarters for Q-o-Q comparison.
Further, there could be certain elements for which values do not appear on the face of HTML but are to be interpreted based on some explanatory text. For example, the current fiscal year-end date is not directly mentioned in the HTML but derived from the period end date.
In all such cases, the inline tagging needs to be done in a way that conforms to the structured data format. This is not on-document tagging as data doesn’t appear on the HTML. The XBRL authoring software instead should have the functionality to support this off-document tagging. All such information should get categorized as hidden tags in the Inline XBRL document, validated, and extracted when required.
4. Not Tagging What’s Visible
While preparing an inline XBRL report, all the information as per the scope and level of tagging should be tagged. Filers need to ensure that there is no important information left untagged. This is important because, if a piece of information is not identified using an XBRL tag, the untagged information though visible on the face of the HTML report, will not get extracted as XBRL data.
5. Tagging Duplicates Facts
In any financial statement, the same information or data point is often found in multiple places, for example, in the main statements and again in the notes to accounts. The information could appear the same or be on different scales. Also, when it comes to non-numeric details, varied styles could be followed making them appear different. In such cases, there is scope for duplicate information to be tagged separately, creating issues during data validation.
However since inline XBRL supports document-driven tagging, it might be unavoidable to tag repetitive facts. In such cases, the XBRL software needs to handle duplicate facts while transforming inline XBRL to XBRL for validation purposes. XBRL International has provided guidance to filers on handling duplicate facts in XBRL, with a special mention of duplicates in inline XBRL. It is recommended that filers follow the approach specified for duplicate tagging while creating an inline XBRL report.
An inline XBRL document serves the dual purpose of making the data human as well as machine-readable, a fact that the filer should bear in mind while tagging in inline XBRL.
For companies using a single-source disclosure management system such as IRIS CARBONTM that is already inline XBRL compliant, these additional functionalities and processes are already taken care of. With the use of IRIS CARBONTM, you need not change anything in your SEC disclosure management process and can generate your iXBRL report literally at the click of a button Contact Us.
