• Translating Your Print Invoice
• Hackers Breached the SEC and Profited Off Pre-Public Information
• IFRS Companies to Begin Filing XBRL in 2018
• Presentation Differences between PDF files & HTML files
• Research Data Group & Uptick Data Technologies Combine Under Unified Management
• New Rule from the SEC – Exhibit Indexes Must Be Hyperlinked
• Will My Edit Require an XBRL Update?
• Scaling in XBRL Filings: Perceived vs. Real Errors
• XBRL FAQ: What is Bleed-Through?
• RDG presents – The ThunderDome® Portal, an On-Demand Disclosure Management Software
• The DATA Act – What it can do for all Americans
• XBRL Quality Assurance – A Potentially Too Honest Take
• An Interview with XBRL Experts — Why Outsourcing XBRL May Be a Safer Bet
• The SEC’s Updated XBRL Viewer – Improvements are Accompanied by Some Bugs
• RDG Filings is Honored to be a Founding Member of the XBRL US Center for Data Quality
• XBRL Is Back In The Crosshairs — Rep. Hurt Is At It Again
• Once Again, The SEC Bolsters XBRL
• The SEC Expands Use of XBRL and Validates RDG’s Commitment to Excellence
• The SEC Massively Expands Its Use Of XBRL Data
• The SEC Enhances its Commitment to XBRL Data
• New Data and Analytical Tools Increase the SEC’s Enforcement Reach
• The SEC is Moving (slowly) in the Right Direction
• At Long Last: The SEC Increases Its Enforcement of XBRL Quality
• Without Warning – The SEC Introduces a New Validation Error
• Congress Sends The DATA Act to the President’s Desk for his Signature
• The DATA Act Will Vastly Improve the Transparency of Government Spending
• H.R. 4164 — Dubious Benefits & Destructive Consequences
• The Buried Lede in an Interesting Article from CFO.com: Ensure Your XBRL Data Is of the Highest Quality
• The 2013 FERF Survey: Doing XBRL In-House Requires 2.3x More Time and Resources than Utilizing a Full-Service Solution
• Congress Will Not Ban XBRL – pressure for improved quality will remain
• The Takeaway from the XBRL-US Conference – Data Quality Is Paramount
• Daryl Issa vs. The SEC? Not So Much. They’re On The Same Page About XBRL Quality
• Don’t Rely on Software Alone to Build and Validate Your XBRL Filings
• XBRL Is Increasingly Becoming The New Standard
• The Truth About The SEC’s RoboCop & The Importance of XBRL Data Quality
• XBRL Data & the SEC’s Enhanced Enforcement Efforts
• XBRL Provider Myth: “Legacy” vs. “New Wave”
• Want high XBRL Data Quality? Why Full-Service is the Way to Go
• Be Practical, Not Scared of XBRL Limited Liability Expiration
• XBRL Quality Assurance – Layman’s Terms
• What Does XBRL Limited Liability Expiration Mean to You?
• Wall Street Journal Article & What XBRL Data Errors Mean to Your Company?
• Financial Executives Research Foundation – FERF Survey Highlights

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.

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.