XBRL News

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

Quick Links

October 12th, 2017

Translating your Print Invoice

October 12th, 2017

If you have ever printed with one of the big Financial Printers, please try to find your last invoice.  Chances are the invoice includes as many as 15 line items for each document.  Many of these line items are purposefully abstruse, and some are simply absurd.  Below you will find a translation from Invoice-ese into Real-talk.  If you see any of the following line items on your print invoice, they should raise a red-flag.

Let’s start with a simple one:

  • LINE ITEM: “Page(s) duplicated from a previous file and processed into new document”
  • TRANSLATION: “We’ve already created this part of the document in the past so no new work was necessary. However, we are taking this opportunity to bill you for the work once again.”

Here’s are two related doozies:

  • LINE ITEM: “File(s) converted to PDF”
  • TRANSLATION: “Although it takes only 1-2 seconds to create a PDF, that won’t stop us from charging you for it.”
  • LINE ITEM: “Electronic Digital Book Proof”
  • TRANSLATION: “We already charged for creating a PDF proof of your document, but we also want to charge for sending a fancy proof too. It only required a moment of time, but nonetheless… ka-ching.”

I saved my absolute favorite for last:

  • LINE ITEM: “Email(s), per address”
  • TRANSLATION: “We think we can get away with charging to send you an email, as if there was another way for us to send you your proofs.”

We here at RDG Filings have typeset & printed many thousands of Annual Reports, Proxies, and Transactional Documents, and we find it neither necessary nor reasonable to charge for processes that only require a few clicks of the mouse.  We provide both print quotes and print invoices that are simple & transparent.

RDG Filings offers fast turnaround, high-quality printed material, and quick delivery to transfer agents from our NYC area press facilities.

We will be happy to get a No-Obligation Quote for you.  Please contact us anytime!

Stewart Walker

415.643.6017

Hackers Breached the SEC and Profited Off Pre-Public Information

September 22nd, 2017

The SEC has reported that the EDGAR system was hacked by nefarious actors in 2016, and they were able to access companies’ financial disclosures before they were released publicly.  Although the SEC was able to patch the breach in their security systems and protocols fairly quickly, Chairman Jay Clayton admitted “that some may have used it to make illegal profits.”

You can read more here, here, and here.

Coming on the heels of the massive data breach at Equifax earlier this month, this news might rattle the cages of security-conscious public companies.  In his statement on the incident, Clayton also made clear that the SEC is “continuing to investigate the breach and its possible consequences,” and it seems likely that the SEC will be making inquiries regarding the path that pre-public financial information takes as it wends from the companies themselves, through the filing agents, and finally to the SEC.

As Reuters states in their article on the hack, “Cyber criminals have targeted financial information hubs before — the Hong Kong stock exchange and the Nasdaq stock exchange in New York were targeted by hackers in 2011.”  Hackers and cyber thieves see considerable money to be made accessing pre-public information, and they have proven as much by targeting stock exchanges and now even the SEC.

This is why RDG has always made the security of our clients’ pre-public information our highest priority.

RDG is proud of the fact that we do not send any of our clients’ documents overseas to be converted.  We also take pride in the fact that all our staff is US-based, as this is a central aspect of our commitment to both data security and customer service.  Another important part of our commitment to both data security and quality is the fact that all our EDGAR conversion and XBRL tagging software is proprietary.  We have built all our own tools for maximum security and quality, and we maintain all our tools and data on our own SSAE16 certified secure servers, which are located in a world-class co-location facility with redundant storage capacity, multiple back-ups for power, dual and backup internet connections, and full hardware redundancy.

We encourage public companies to ask their SEC filing agent some very important questions:

  • Do you send any part of my documents to a 3rd party for EDGAR conversion or XBRL tagging?
  • Do you send any part of my documents overseas for EDGAR conversion or XBRL tagging?
  • Are all of your employees US-based?
  • What are your security protocols and procedures?

Please contact us if you have any questions about the hack of the SEC or about RDG’s service.

We will be looking forward to hearing from you. Get in touch with us anytime!

Stewart Walker

415.643.6017

IFRS Companies to Begin Filing XBRL in 2018

September 12th, 2017

On March 1, 2017 the SEC posted the IFRS Taxonomy.  A full eight years after the start of the XBRL mandate for US GAAP companies, the SEC has finally announced the mandate for IFRS companies to submit XBRL files for 20-F and 40-F filings.

IFRS filers will have to begin submitting XBRL exhibits with fiscal periods ending on or after December 15, 2017.

How does this impact SEC Foreign Private Issuers (FPI) that use IFRS?

SEC Forms 20-F and 40-F (and some 6-Ks*) will require XBRL tags to be applied to each number in the Base Financials, including all of the facts in the Notes to the Financial Statements.

It cannot be denied that this will require some additional work for IFRS companies’ financial reporting teams.  However, there is value in IFRS companies beginning to file XBRL structured data and adding their data to the currently existing wealth of structured data that has been submitted to the SEC by US GAAP companies since 2009.  XBRL structured data is computer-readable and enhances the value, access, and usability of the financial information that SEC issuers file.

RDG filings is one of the leading providers of full-service XBRL tagging solutions in the country, and we create the highest quality XBRL data available.  We have been filing XBRL under the US GAAP taxonomy since the beginning of the mandate, and we are very excited that the IFRS taxonomy is finally going to be made live.  As one of the founding members of the XBRL US Center for Data Quality, RDG has the experience and the expertise to provide IFRS companies with excellent customer service and the highest quality XBRL data.

RDG has always made a strong commitment to creating the highest quality, most useable XBRL data possible, and we employ Certified Public Accountants and experienced auditing/accounting professionals to provide personal service to all of our clients.  As a result of this commitment, the XBRL data that RDG builds has been ranked by a leading independent expert as being filed error free 99% of the time.

Don’t Wait

Don’t wait until you are drafting your 20-F or your 40-F to begin preparing for the XBRL tagging process.  The template creation and set up process is not insignificant, and it pays to begin the process early.  Please contact us to ask any questions and get a realistic and transparent flat-rate quote.  Some providers may try to overcharge you for this service, so it is very much worth your while to take a few moments to do your due diligence.

(*Unless an issuer has a Form F-3 shelf registration that it wants to keep current, there is no requirement for quarterly or semiannual financial statements or earnings press releases that are submitted to the SEC on Form 6 K to include the information in XBRL format.)

We will be looking forward to hearing from you. Get in touch with us anytime!

Stewart Walker

415.643.6017

Presentation Differences between PDF files & HTML files

July 14th, 2017

A common question we receive at RDG is:  “Why does my PDF Proof look different then the HTML?”  The answer to this question partly requires changing it to:  “How is HTML different from PDF?”

The answer to the question about the differing presentations of the two formats lies in the foundations of these two document types.

HTML files are displayed in accordance to whichever Operating System/Browser you are using.  For example, using different web browsers such as Google Chrome or Mozilla Firefox can affect the way an HTML is displayed/presented.  This is because the underlying code in the HTML file is communicating with the underlying code in the browser being used, and each browser interprets and displays HTML differently.  Additionally, the SEC has its own specific conversion process that dictates how the HTML is presented on the SEC’s website once it is filed.  RDG adheres to those SEC standards known as the EDGAR Filer Manual.

A PDF file, on the other hand, is not dependent on the Operating System/Browser to dictate how the file is displayed.  A PDF is usually not meant to be altered, and it is essentially a snapshot of a document as it would look were it to be physically printed out on 8.5×11 paper.  This is why the PDF file type is the preferred method for documents that are meant to be presented to an audience or physically printed out.

So the PDF proof can look different than the HTML version because when the HTML’s underlying code is converted into a PDF file, some of the characteristics of the HTML’s code can be stripped out by Adobe PDF’s differing interpretation of that underlying code.

That being said, when something doesn’t appear to be presenting correctly in the PDF proof, we strongly advise adjusting the scale/zoom feature in Adobe.  The screen on which the PDF is being viewed on can also affect how it is displayed.  If you are viewing the PDF on your phone versus viewing it on your computer, then there can be some differences in how it’s displayed.  This also applies to larger or smaller computer monitors.  Alternatively, if you are viewing it on your screen and something doesn’t look right, you will find that physically printing the document will show that issue is not in the document itself, but rather is just a function of how Adobe presents PDFs on screen.

Common Questions about PDF Proofs:

  • Why are the underlines missing in this table?
    1. Usually that is a direct result of the “zoom” or “scaling” feature in Adobe.
      1. Solution: Adjust the zoom/scaling in Adobe (zoom in or out) until the underlines appear correctly. You can also print the document to confirm the underlines are present.
      2. Alternate Solution: View the PDF on a different sized screen/monitor.
  • If issue still persists, please contact us and we will be happy to assist.
  • Why are the indents incorrect?
    1. HTML files can have margins as big or small as necessary to display the information. However PDF files have maximum margin limitations, which can create presentation differences on paragraphs that are fully justified. This is because Adobe is trying to adjust the presentation in a way that fits with its own parameters.
      1. Solution: Adjust the zoom in Adobe until the indents appear correctly, or print the document.
      2. Alternate Solution: View the PDF on a different sized screen/monitor.
  • If issue still persists, please contact us and we will be happy to assist.
  1. This can also occur in bulleted lists. The presentation of spacing between bullet points or within bullet points can be inconsistent based on how Adobe PDF interprets the HTML code.
    1. Solution: Adjust the zoom in Adobe until the indents appear correctly, or print the document.
    2. Alternate Solution: View the PDF on a different sized screen/monitor.
  • If issue still persists, please contact us and we will be happy to assist.

If you have any other questions regarding the presentation of a PDF file versus an HTML file, please feel free to contact us and we will be happy to assist.

 

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:

rendering_sections

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.

htm_1

render_1

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.

htm_2

render_2

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.