RDG Filings is committed to providing its clients with the best XBRL service(s) available. This includes keeping our clients up to date with XBRL Tagging ideas, XBRL service updates as well as recent XBRL Filings for better understanding of the XBRL filing process.

XBRL News & Blogs

Research Data Group & Uptick Data Technologies Combine Under Unified Management

May 27th, 2017

Research Data Group, Inc. (RDG), a leader in assisting public corporations with SEC filing requirements, and UpTick Data Technologies, a leader in Natural Language Generation and financial reporting, announced the merger of the two companies under one management structure. The combination brings together RDG’s corporate performance graphs, peer group analysis, XBRL and EDGAR filing capabilities with UpTick’s automated text generation technology used to produce corporate insider, earnings, and analyst recommendation news as well as UpTick’s retirement reporting platform PlanXtra.com.  UpTick was previously majority controlled by RDG and this consolidation allows for a more streamlined financial and management structure, integrated infrastructure and development platform.

According to Jonathan Elliott, RDG’s Chief Operating Officer, “UpTick’s capabilities utilizing financial data for text generation and commentary fit extremely well with RDG’s SEC data creation and management services. We are excited about the opportunity to apply this market leading technology to our full-service analysis and software platform offerings.  UpTick’s report generation capabilities complement and enhance RDG’s own reporting capabilities and will expand the suite of products we offer in exciting new ways, including the creation of reports and news utilizing XBRL data.  We look forward to exploiting these synergies to better serve and grow our combined client base.”

About RDG:

  • With offices in San Francisco, CA, Boise, ID and Salem, VA, RDG is the fifth largest full-service filing agent in the country as well as the most trusted name in Performance Graph production, custom peer group calculation, analysis, and consulting. Together with its SEC EDGAR filing and XBRL services, RDG supports a client base of over 1,500 public companies and is the only provider of all licensed Major Market Index data from Dow Jones, Dow Jones US Total Stock Market, NASDAQ, Russell, S&P, NYSE Amex, and TSX.

About UpTick Data Technologies:

  • Headquartered in San Francisco, UpTick Data Technologies combines its state-of-the-art Natural Language Generation (NLG) technology with proprietary client data and data from leading financial data sources such as Thomson Reuters, Morningstar, and SEC EDGAR Filings to produce customized financial news, commentary, and reporting solutions.  UpTick’s products include PlanXtra.com an automated retirement plan monitoring and reporting tool and Corporate Insiders News available from leading news distributors.

You are welcome to contact us for more information.

(415) 643-6017

New Rule from the SEC – Exhibit Indexes Must Be Hyperlinked

March 8th, 2017

Everyone loves new rules from the SEC, right?  Well, the SEC is happy to oblige.  On March 1st, the SEC released new rules about hyperlinking the exhibit indexes in many SEC Filings.  The Final Rule 33-10322 is called “Exhibit Hyperlinks and HTML Format,” and if you’d like to read the full 47 pages, you can find them here. However, if you’d prefer a brief summary, you can find one below.

The Gist

All documents (even those incorporated by reference) listed in the Exhibit Index must include a hyperlink that will link directly to the exhibit itself.

The rule also includes a related requirement, which will impact only a small number of companies.  The SEC will be no longer accept filings (that include an exhibit index) in ASCII.  Hyperlinks are not possible in ASCII, so companies will be required to submit all impacted filings in HTML.

When Does it Take Effect?

September 1, 2017

The only exception to this start date will be for Smaller Reporting Companies and Non-Accelerated Filers that currently file in ASCII.  Those companies will have until September 1, 2018 to comply.

What’s the Point?

To improve investors’ access to information.

What Form Types Will this Affect?

10-K, 10-Q, 8-K, 20-F, S-1, S-3, S-4, S-8, S-11, SF-1, SF-3, F-1, F-3, F-4, 10, 10-D, F-10

Related amendments (e.g., S-1/A, 10-K/A, 10-Q/A, 8-K/A, etc.) will also be affected.

Are There any Exceptions?

Exhibits that have not been filed electronically (i.e., paper filings) are excluded because there is nothing to which to link.

XBRL exhibits are also excluded from the requirement because a hyperlink would lead to an XML file, which would not be helpful to investors.

What Happens if a Hyperlink on a Filed Document is Inaccurate or Non-functioning?

In the case of a Registration Statement that is not yet effective:  The company must file an amendment with the correct link.

In the case of a Registration Statement that has become effective:  The company must correct the link in their next filing that contains an Exhibit Index.  Alternatively, the company could file (but is not required to file) a Post-Effective Amendment to the Registration Statement.

In the case of a 10-Q, 10-K, or 8-K:  The company must correct the link in their next filing that contains an Exhibit Index.  An amended filing is not required.

Here is an Image to Help Clarify

The Exhibit in the blue square is incorporated by reference, so this will need a hyperlink that leads to the URL for that previous 8-K filing on the EDGAR system.

The Exhibits in the red square are being filed or furnished along with the filing in question, so they will need to be hyperlinked to the exhibits themselves.

The XBRL Exhibits in the green box will not need to be hyperlinked.

Exhibit Index Hyperlinks_boxes

Will My Edit Require an XBRL Update?

February 8th, 2017

A common question we receive about XBRL is, “Will this small edit I’m about to make to my document require an XBRL update?”  We typically get this question when there are only a few hours left before the filing deadline and it’s necessary to squeeze in a few more tweaks—a comma here, a typo there, a couple underlines on a table, etc.

The short answer is:  If the edit is in a section of your document that is tagged with XBRL, an update to the XBRL will be required, even for an edit as minor as adding a comma.

It’s important to keep in mind that we are only talking about sections of the document that are tagged for XBRL:  Financial Statements, Footnotes to Financial Statements, and Supporting Financial Schedules (e.g. Schedule II).  In other words, if you need to make an edit to the F-pages, you’ll need an XBRL update.  However, if you need to edit the MD&A, certification exhibits, or anything else outside the F-pages, you will not need an XBRL update.

So let’s look at why this is so.  We’ll give the basic explanation first and provide some more nuanced details as well.

The Basics:

The first thing to keep in mind about edits that affect the Financial Statements & Footnotes to Financial Statements is that XBRL creation does not function like word processing.  For reasons related to both version control & consistency and to the quality of the XBRL code, edits are not made directly to an existing XBRL document.  Put another way, updating XBRL is not as simple as clicking in a paragraph and typing changes.

Here’s the gist:  During the filing process, RDG maintains one master HTML version of your document.  From that master HTML file, we can create the EDGAR proof, and we can also pull that HTML into the XBRL tagging software to create an updated XBRL version.  In this way, the content of the EDGAR document and the XBRL version always match exactly.     So, when you submit a change to the F-Pages, we make that edit to the master HTML file in a way that is roughly analogous to word processing, and then we can send you the updated EDGAR proof generated from the revised master HTML file.  However, we do not then go into the XBRL version of the document and re-make the same edits.  To update the XBRL, even for the smallest changes, the master HTML file must be re-uploaded to the XBRL tagging software.

Because XBRL creation is complex, once the new master HTML file is uploaded, even the smallest of edits must be reviewed and re-validated to ensure the finished product is ready to be submitted to the SEC.  This is why even a single comma can take considerably longer to update than expected.

Some Details:

So why does even the addition of a single comma to a footnote require an XBRL update? Let’s take a look at the section list of an average SEC rendering:


Looking at the image above, the nitty-gritty of XBRL tagging is mostly found in the sections of the SEC rendering called “Financial Statements” and “Notes Details.” In those sections, all you see is a list of tagged values and their attributes, but you do not see any of the text from which those values are pulled.  The three sections in-between are very different, because there, you will not simply find individual tagged values, but the entire note, table, or policy from your HTML document. These sections are tagged as a block (called a “Text Block”).  When a Footnote to the Financial Statements is block-tagged, you see the entire note exactly as it’s formatted in your HTML document, down to every comma.

Here’s an example of a note in its entirety:

rendering_sections_expanded Capture

If you were to add a comma in the note above, an XBRL update would be necessary.  The added comma would not affect the “Notes Details” section where only the values are presented. However, without an update, the added comma would not appear in any of the text block sections and the XBRL would not exactly match the HTML document.  The same goes for any changes to tables, no matter how small the change.

RDG will, as always, make every effort to get all necessary changes done as expeditiously as possible. We hope this information helps to make clear why even the smallest change to the Financial Statements & Footnotes is a challenge, especially during the time-crunch on deadline day, and can require more time to process than you might anticipate.

Scaling in XBRL Filings: Perceived vs. Real Errors

September 9th, 2016

You’re scanning over your financial reports again when something small catches your eye. The balance sheet numbers seem right on the XBRL rendering, but why aren’t they scaled like on the original proof? This scenario probably sounds familiar because it is so common to see scale rendering differences between RDG’s Thunderdome Viewer and the SEC’s XBRL Viewer. It’s important to understand that this type of difference in appearance does not indicate inaccuracy.

Thunderdome Viewer closely mirrors the SEC’s rendering software and treats scaling in the same way. If a table in your original document is scaled in thousands, we assign the same scale of “in thousands” in the XBRL tagging. Below is an original balance sheet, followed by the same balance sheet in the Viewer. Notice they are scaled the same, with the phrase “in thousands” under the page header.



However, there are times when the rendering of a table doesn’t match your original document. This happens when a number in your table is referenced in another location in your document, such as in the text of a footnote, but in a difference scale. And then, as we described in a previous article, the scaling bleeds through from the other location and into your table. Since an XBRL rendering cannot support more than one scale in a single table, the scaling of all facts in that table is then adjusted to the lowest common denominator – the scale closest to actual. You can see this happening in the following example. The original balance sheet is scaled in thousands, but the rendered balance sheet is scaled in exact dollars. Remember, the XBRL code is identical in both cases. Only the presentation is different.



Here’s a point worth remembering: according to the SEC, the aesthetics of an XBRL rendering are always secondary to the accuracy of the data. In the examples above, the values look different but they are, in fact, the same. If the tagging is correct in the underlying XBRL, the underlying values of the financials are also correct. There is nothing to fix, and no need for adjustments to the XBRL to make the Thunderdome Viewer proof match the SEC’s XBRL Viewer presentation.

Professionals often learn the significance of presentation early in their careers, in just about everything from haircuts to slideshows. Once ingrained, it’s a hard habit to shake. Yet even the SEC addressed the issue in its December 2011 round-up of staff observations: “Filers should concentrate on the quality of the tagging rather than trying to match the rendering of the XBRL exactly to the HTML filing.” To align ourselves with this statement, our efforts and our recommendations are always focused on the accuracy of the XBRL rather than to achieve any specific rendering presentation result.

XBRL FAQ: What is Bleed-Through?

May 3rd, 2016

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.

Bleed Through Table 1

Bleed Through Table 2


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:


Bleed Through Table 3


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.

RDG presents – The ThunderDome® Portal, an On-Demand Disclosure Management Software

April 27th, 2016

Are you in the market for SEC Disclosure Management software?

Do you want to control your SEC filing process, and have the ability to edit and file the EDGAR document yourself?

Yes, you say?  Well then, RDG Filings would like to introduce the ThunderDome® Portal, an on-demand disclosure management software that will streamline your SEC Filings process.

The ThunderDome® Portal works in harmony with RDG’s industry leading XBRL tagging full-service expertise.  RDG has created the Perfect Combination of On-Demand Software & Expert Full-Service.

EDGAR Control

The exclusive ThunderDome® Portal allows multi-user access to create, manage, edit, and file EDGAR documents with the SEC.  The web-based portal creates significant efficiencies as it enable version control and collaboration while also eliminating the need to manually hand-mark EDGAR changes only to then wait for your provider to return a proof.  The portal also remove the possibility of ‘printer error’ during the editorial process.

RDG remains available 24/7 for full-service EDGAR conversion, service, and support.  So our clients enjoy the perfect combination of full-service expertise when they need it and in-house control when they want it.

XBRL Expertise

RDG’s US-based experts do all the XBRL tagging and validation, and a dedicated Account Manager be available to you for questions and consultation.

You will simply review the tagging on our superior online XBRL review tool, which is an integral aspect of the ThunderDome® Portal.

Rational, Flat-Rate Pricing

And here’s the kicker: RDG’s rational and flat-rate pricing structure will represent both savings & budget-predictability.


Please feel free to contact me anytime.

Stewart Walker – SVP, Director of Sales

(415) 643-6017

The DATA Act – What it can do for all Americans

April 19th, 2016

It is no secret that the federal budget is riddled with waste and errors. Tell us something we don’t know.

This fact is the type of thing most Americans have accepted with death and taxes. As our culture grows more cynical, there is an overwhelming sentiment of “There is nothing I can do to change the way things are.”

We must fight against our apathy and use technology to assist us in forging ahead into what we know to be better government and “a more perfect union.”

The DATA Act (Digital Accountability & Transparency Act) is one of the few opportunities we have to change not just some things – but everything about the way the government distributes money. I will be the first to admit that it is a long shot for any government agency to do something efficiently and effectively, but even if they get this legislation half-right it would be a great improvement.

Another piece of potential good news for the DATA act is that it has a very recent, major government implementation process to learn from and improve upon. The process I am referring to is the Securities & Exchange Commission’s implementation of eXtensible Business Reporting Language (XBRL) from 2009-2012.

This SEC action plan for implementation of XBRL into public company filings incorporated a two-year voluntary-filer pilot-program, followed by a gradual phase in of the biggest companies to the smallest public companies from 2009-2012. This roll out allowed both the SEC and small companies to learn from early mistakes and refine the process quickly. The phase-in also allowed for milestones to be achieved with regard to the level of detail in the data.

Where the SEC went wrong is not demanding enough standardization of data-tagging. It allowed for over 15,000 definitions public companies could choose from and also offered companies the ability to create their own customized definitions on top of the 15,000 options. So the reality was “infinite possibilities”. Not so surprisingly, customization was rampant in early XBRL filings and created high “extension rates”, which make it difficult to get apples to apples comparisons. What one company termed as “Sales” another could customize their definition slightly in order to not have their numbers directly compared for fear of looking bad against the competition.

This single point of failure can be avoided in the DATA Act implementation and in future transparency efforts. Minimizing the number of customized ways to say the same thing will increase the accuracy of comparison between municipalities, grant recipients, companies and agencies that receive federal money.

The good people at POGO have put together 10 questions that should be easy enough for even moderate transparency to answer. 

While what is below is an over-simplification of a complex tagging-service process using a complex software product, it will show how it should look to the lay person who wants to know where their tax dollar are getting spent. This way of looking at the data is, in fact, the end goal of transparency. All of us being able to see how the government is spending the money we (the citizens) agree to give.

Question: What small businesses in my community are receiving federal dollars?

How XBRL would allow for easy comparison:

<smallbusinessname>ABC Fictional Company</smallbusinessname>
<federalagencyDoD>Department of Defense</federalagencyDoD>
<intendeduse_militaryfacilityconstruction>Fort Fake Barracks Improvements</intendeduse_militaryfacilityconstruction>




XBRL Quality Assurance – A Potentially Too Honest Take

November 3rd, 2015

“XBRL is an unfunded mandate, and I don’t like paying for it in the first place.  Furthermore, nobody is even using this data, so why would I approve additional expense to have our XBRL reviewed by an independent and expert third party?”

While this is a direct quote from a CFO I spoke with recently, I thought it pretty well sums up the sentiment I hear from a lot of people I speak with about XBRL in general and about our Quality Assurance Services in particular.

I’m in sales, so of course when I get this type of objection, I look to re-direct the focus of the conversation and find a new way to present the value of the service I’m offering.  Often times, this kind of sales-spin is not too difficult because the facts of the case point to a clear conclusion, and it’s just a matter of illuminating the facts and presenting them in such a way as to make it easier for the prospective client to arrive at the same conclusion.

However, as is the case with the quote above, sometimes the “facts of the matter” are not inherently helpful to your case.  Sometimes, one or more of the facts actually align to make it more difficult for your prospective client to see the value.  In my years of selling, I’ve witnessed myriad sales people try to “dance” around undesirable facts.  The steps to this dance are graceless, and the music is discordant.

I refuse to do that dance, which brings me (at long last) to the point of this post:  The CFO quoted above is correct in some very important respects.  My job is not to avoid these ‘difficult facts,’ but rather to shine a light on them and make my case nonetheless.

My argument:

  • Hiring an independent, 3rd party to expertly review your XBRL is a sound investment.

The difficult facts that must be admitted:

  • Very few people outside of the SEC are currently looking at your XBRL files.
  • A review of the quality of your XBRL is, quite simply, not something you need to do at this point.

It is true that that outside of the SEC, very few people of immediate consequence to your company are looking at or utilizing XBRL data.  However, all the analysts I’ve spoken to or heard at conferences admit they would love to use this data, because XBRL would hugely improve and hasten their access to important information that drives investment decisions.  The only reason they don’t currently use it, they say, is because there is not enough data out there of reliable quality.  Much of the XBRL data being created by firms that outsource the work overseas—or that is created in-house by companies using some of the leading document control software—is not of consistent quality and does not provide a sufficiently accurate depiction of the filer’s financials to be trusted.

To this point, I say that there is both a present and future benefit to ensuring your XBRL is quality and useable for analysts.  Presently, the major analyst and investment houses are not currently using your XBRL code, but many people both in the investment community and the academic community are, and it is of significant importance that your XBRL present an accurate depiction of your financial disclosures.  And in the future, when the major analysts do start using this data (and they most certainly will), having a history of accurate and useable XBRL filings for them to call upon will put your company’s disclosures in a position of strength compared to the rest of the market.

Finally, it is also true that the SEC is not yet enforcing XBRL data quality to any significant degree, and there is scant motivation in terms of strict compliance.  However, the SEC has invested years of resources to the establishment of this new reporting requirement, and they will be increasing their enforcement of quality and expanding on steps they’ve already taken.  They already use XBRL as the main tool of their RoboCop fraud detection tool and to expand their enforcement reach.  The SEC has only increased its commitment to the XBRL reporting requirement, and they have also massively increased its use of the data.  So being out ahead of the SEC current requirements is valuable in its own right.

I liken a thorough review of your XBRL by 3rd party experts to buying auto insurance that also improves the performance of your car.  Ensuring your XBRL is of the highest quality will keep the SEC out of your hair now and in the future, and it will also make your data more available to and useable for analysts who will be using this data to drive important investment decisions.

Please feel free to contact me anytime.

Stewart Walker – SVP, Director of Sales

(415) 643-6017

An Interview with XBRL Experts — Why Outsourcing XBRL May Be a Safer Bet

August 24th, 2015

Recently I sat down with a couple of our resident XBRL Account Managers to see what their thoughts were on the clients’ knowledge of XBRL and whether going in-house would make sense.  Here’s what I found out:

Question: What would you say are the most challenging aspects of XBRL for clients to understand?

XBRL Account Manager: Bleed-through and negations would be top of the list.  Explaining the context of specific tagging can also be difficult.  Someone can look at the definition, and it could look appropriate on its face. However, the definition can sometimes be misleading, and you have to look at the structure of the taxonomy to see where the definition was pulled from to be certain it is appropriate.   It can also be hard to explain what actually happens within the code. For example, a client who transitions over to us from tagging on their own with a software will negate an item, but it will not reflect in the code. The presentation link base and the calculation link base will not match. It is difficult to explain why it’s not rendering in the code.

Question: Are you ever surprised by the coding errors that need to be corrected from previous vendors? What are some of the most common errors that you find yourself having to fix?

XBRL Account Managers: We are never surprised per se because, unfortunately, errors are frequent. That said the most common errors we find are inappropriate tagging. For instance, inconsistent parent and child relationships.

Question: How much time do you devote to keeping abreast all new SEC regulations?

XBRL Account Managers: Anytime there is a taxonomy update or new FASB guidance, we make sure we are familiar with it, and we spend quite a bit of time going through the guidance.  Additionally, we get updates from major accounting firms, AICPA, FASB, and XBRL-US about changes that are coming down the pipeline but that have not yet been adopted.  XBRL-US does not just update its members on new regulations, but also about any changes to their best practices.  We train our team at least once a week on various topics including accounting guidance and taxonomy updates.  And as founding members of the XBRL-US Center for Data Quality, we are deeply involved in the establishment of best practices as well.

Question: If you were the CFO of a public company, would you hire someone internally to take care of the creation of XBRL exhibits for you? Why or why not? No.

XBRL Account Managers: Absolutely not. That hired person is only going to have a fraction of the experience of a dedicated XBRL expert. You would be depending on someone who does four filings per year as opposed to an RDG manager for example that averages about 80 filings per year.  Now, to be honest, if I was a CFO of a large company with unlimited funds, and I wanted to hire someone internally who I could send to XBRL workshops and have them focus exclusively on XBRL — I would go that route.  But it sure seems inefficient to have a full time employee to do only four filings a year.  Unless they are exclusively committed to the company’s XBRL reporting, they simply won’t have time to keep abreast of all the guidance.  It just makes more sense to outsource.

Question: Why shouldn’t a company just outsource this process overseas?

XBRL Account Managers: Security first and foremost. This is time sensitive and pre-public information that we are dealing with, and sending it overseas prior to filing seems an unnecessary risk.   However, a lack of US GAAP knowledge would also be a significant concern. It is doubtful that any foreign 3rd party provider is going to be as familiar as necessary with the same accounting standards as your financial statements.

Question: What do you say to a company that says: “My financials don’t change much from quarter to quarter and I already have my XBRL files built, so why can’t I just carry this forward and tag future filings myself? Seems simple enough.”

XBRL Account Managers: If your financials are in one consistent form, it does make it a bit easier. However, while your financial statements may not change, accounting standards are always changing. The taxonomy is also constantly changing. If your tagging does not change to keep pace with changes to the accounting standards and taxonomy, you will be left behind. Even the FASB guidance changes every month and we are constantly adopting these changes.  If you have the same tagging for even a two year period– I guarantee that your tagging will be obsolete because everything around it has changed.

Question: Do you think that the SEC will ask for XBRL to be audited in the future?

XBRL Account Managers: Perhaps. However, before this happens, the SEC will have to push for increased consistency and quality on the XBRL reports, and they will have to increase their enforcement mechanisms to achieve this. The SEC is certainly going in that direction as they have already started to invest in-line XBRL, which would make auditing the XBRL more plausible.

So now the question goes to you- would you feel most comfortable hiring someone internally or outsourcing?


Written by : Divya Patel- VP Business Development

If you have any questions or would like any further detail, please feel free to contact Stewart Walker – SVP, Director of Sales

(415) 643-6017

The SEC’s Updated XBRL Viewer – Improvements are Accompanied by Some Bugs

August 11th, 2015

The SEC has updated their XBRL viewer, and in many ways the changes are improvements.  The new XBRL viewer ( was deployed this summer, replacing the previous version (  Additionally, the update was a necessary step with regard to future enhancements the SEC will be making to the viewer.  However, in the short term, this update includes some bugs that we wanted to alert you to. This post will describe the changes the SEC made to their viewer and explain some of the bugs that have come from this update.  We invite you to contact us if you have any questions or if you’d like more specific information.

To put the viewer update in context, it’s important to know that the previous SEC viewer originally was created using the .NET framework over 6 years ago.  However, the SEC’s validation engine (Arelle) was built using a coding framework called Python.  The different programming languages made integrating the two platforms difficult.  Additionally, the .NET framework caused some problems running the renderer on non-Windows machines.

To address these issues, the SEC has built the new viewer using the Python platform so that integration with the Arelle validator is now seamless.  While this does not impact the end user to any significant degree, it helps developers and the SEC a great deal.

Now we will address the bugs that have popped up as a result of this viewer update.

Uncategorized Items

“Uncategorized Facts” are typically only presented as such if the facts are not assigned a specific presentation. The updated viewer is erroneously identifying certain facts as “uncategorized” even when they have been assigned a presentation.  This issue is most commonly tied to US-GAAP concepts that appear on both the Income and Cash Flows Statements.  Apparently, the viewer will place shared facts from the Cash Flows in the “uncategorized” section and ‘forgets’ that those facts were already used on the Income Statement.  This means the viewer did not need to display those facts as uncategorized because they were indeed displayed on the Income Statement.  The new viewer also fails to distinguish between actual uncategorized facts and facts the viewer is choosing not to display.

The SEC is aware of this bug, and we believe it will be addressed with their next Viewer update, but they have not yet provided a timeframe for the correction.

Total Columns

Where the previous viewer displayed a “Total” column only when the presentation was an equity table, the update has caused the viewer to display a “Total” column whenever there are multiple contexts that end on the same date in the same presentation.  This change does allows for tables other than the equity table to render with a “Total” column, but it leads to certain other issues when viewing reports (e.g.: The Document and Entity Information can now render with a “Total” column, or Operations tables may render with two “Total” columns).

We do not yet know if the SEC considers this a bug, or if they will address it with their next Viewer update.


If you have any questions or would like any further detail, please feel free to contact us anytime.

Stewart Walker – SVP, Director of Sales

(415) 643-6017