And here’s why: XBRL documents are a collection of data points. When you edit a report in your XBRL software, the software writes out the data points with relational information and other properties. Then it’s up to other software to interpret the relationships between the data points and put the report in a human-readable format. There’s no part of your XBRL document that says: “Data Point A belongs on Presentation X”. It’s a little more complicated than that. Rather, your XBRL software will describe your document more like this: “Data Point A is related to the Cash Element and the March 31, 2014 Date. Presentation X contains all data points for a certain set of elements (including the Cash Element) and for a certain set of dimensions.” For this reason, you may often see unexpected facts that didn’t appear on a presentation within your XBRL software suddenly appear on an XBRL viewer. It is because those data points fall within the criteria for that presentation. The viewing software doesn’t know that you didn’t have those facts on that sheet when you were editing. It simply knows that they meet the description of the facts that should appear on that sheet, so it displays them.

So a user like you is reliant on your editing software to write the XBRL data in a particular way so that the consumer’s viewing software can logically put it back together – and the consumer’s viewing software needs to be smart enough to put everything in its place.

But changing the structure of your XBRL so it looks better on the SEC’s previewer or any other viewer for that matter is a bad idea. The whole point of XBRL is to create a uniform way of reporting financial data so investors can analyze and compare data quickly and easily. The quality of your data needs to be your main concern when creating XBRL reports, not the “look” of the report.

It’s easy enough to say that you can ignore the quirks of XBRL viewers, but it’s harder to convince your stakeholders or clients that something that doesn’t look quite right in the viewer is perfectly acceptable – and even 100% correctly tagged and coded XBRL. The SEC provides a previewer to help you determine if you are reporting all the data they require, but it can be problematic when reviewers start looking at style over substance.

So here are some tips that will help you enhance the look of your report in the SEC Viewer and Previewer without undermining the quality of your data.

1. Make sure that your member elements and axis elements are included in both the definitions and presentation linkbases.

If you want facts with dimensional information to appear on a presentation, be certain that the dimension information is added to that presentation’s linkbase. This will prevent the data from appearing as “uncategorized” on the SEC’s Viewer or not appearing at all in other XBRL software.

2. Organize your report so all presentations appear in the appropriate order.

The SEC requires different types of presentations: your face financials, block tagged footnotes (Level 1), accounting principles (Level 2), block tagged tables within each footnotes (Level 3), and footnote details (Level 4). Within your report, all face financials should appear first, followed by all Level 1 presentations, then all Level 2 presentations (if any), then all Level 3 presentations (if any), and finally all of the Level 4 presentations (if any). If these presentations are out of order – say, a Level 4 presentation appears between your Balance Sheet and Cash Flows – you’ll end up with uncategorized presentations on the SEC’s Viewer.

3. Verify element and date choices if you find that unwanted columns appear or desired columns disappear once you view your document outside your XBRL editor.

Sometimes, unexpected columns show up on your presentations in the viewer. This can happen because, as we talked about earlier, XBRL documents don’t write out which data points belong to which presentations so presentations can suddenly gain additional columns when a viewer pieces the data points back together for display. All you can do is make sure that element choice for that fact is correct, and that the context is correct. You may find that you
have chosen the wrong start or end date for a context or that you’ve selected an inappropriate element.

Conversely, you may have columns disappear on you. This happens because the SEC Viewer hides columns that don’t have enough data within them. There’s no way to force those columns to display, and you should never add data to make them appear. Remember, the data quality is the most important part of XBRL reporting. All you can do is verify that everything is correct in your XBRL
document. If a column is short on data, it could be because you used extensions when you didn’t need to do so.

If everything is correct and those pesky columns still aren’t behaving, don’t fret. As long as your data is accurate, don’t sweat the viewer. An unreported value, a zero, and a nil value can mean different things, so you should not change them unless you are sure data wise it is the right choice.

4. Make sure you use TextBlock Elements for HTML.

When tagging HTML data, it’s always important to double-check that you’ve used an element of the correct data type. The String data type isn’t appropriate for HTML facts. Only TextBlock elements should be used when tagging HTML data.

5. Avoid using conflicting fact precision. 

The SEC Viewer consolidates precision when it renders XBRL, so if you have varying precision for facts of the same data type on a presentation, things aren’t going to look quite right. Verify that the precision for all facts that appear on that presentation is correct. It isn’t common for items with the same data type have different levels of precision within the same report, and it’s even less common for items with the same data type to
have different levels of precision on the same presentation.

6. Be careful using Abstract elements.

Abstract elements will not appear if they don’t have any non-abstract children, so it’s a good idea to check that all your relational information is correct. If one of your abstract headings disappears, use your XBRL software to make sure it has at least one child element that isn’t another heading. Unfortunately, in some viewer like those provided by the SEC, if the first item after an abstract heading is another abstract element, that heading
won’t appear. So if you have the AssetsAbstract element as a heading and the first line item under it is the AssetsCurrentAbstract element, AssetsAbstract will disappear. There’s nothing you can do to stop that from happening.

You also need to be careful that you don’t make all of your elements children of preceding abstract elements. While the SEC Viewer doesn’t have any indenting or other visual indication of what elements are children of other elements, it’s not appropriate to have your liabilities line items be children of your assets heading.

So when using abstract elements, try to avoid these common problems, if at all possible.

7. Write appropriate labels for your units.

Finally, you should always make sure that you have appropriate labels for your units. Labels may or may not be used by the XBRL viewing software, but you should always assume that labels will be visible to an end user. For units, labels can appear in column headings, so a hodge-podge label for a custom unit isn’t the best idea. Your labels should be clear representations of what the units are and don’t forget to check your spelling!

When it comes to XBRL, the number one priority should always be data quality, so never compromise the quality of your data to achieve results in an XBRL Viewer. As XBRL is used by more consumers and more XBRL tools are developed and released, expect the behavior of software to improve so that some of these issues will no longer be concerns. Until then, always make sure the underlying data is accurate and do what you can to create XBRL reports that look
neat in the SEC Viewer.