InfoBytes: Interview With Robert Santoski on iXBRL and the ESEF mandate
Full Disclosure recently interviewed Robert Santoski, Founder at XBRLogic.com (formerly AsReported.com) on iXBRL and the ESMA mandate. He developed multiple software solutions in the area of financial data extraction, standardization, and automation. Robert recently developed XBRL Standardization Engine available for the collection and standardization of corporate financial data from SEC filings and other published reports. Here is a transcript of the interview.
It has been 10 years since the US SEC adopted XBRL reporting. When and where did you first come across XBRL as a standard, and how has your journey been with this standard so far?
Robert Santoski:
I first encountered XBRL in 2008. At the time I was working for S&P’s Capital IQ division, developing an automated process to standardize preliminary 8K financials. The SEC mandate was still a year away. At the time, XBRL looked promising and I felt that if properly implemented, it could transform the financial disclosure industry. From the beginning, however, I was skeptical that a single data set could be created that was both as-reported and standardized. They were at cross purposes and the resulting tension would be hard to reconcile. The last ten years have demonstrated that this tension still exists. Filers are focused on accurately presenting historical results, favoring tagging precision over standardization. Investors, on the other hand, favor standardization over tagging precision. The result has been a disconnect between what filers supply and what investors demand.
With more countries moving to Inline XBRL, what are your views on inline XBRL? What benefits, challenges, and issues (if at all) do you see with iXBRL?
Robert Santoski:
I’ve authored an article on this subject on Linked In.
https://www.linkedin.com/pulse/inline-xbrl-curb-enthusiasm-robert-santoski/
I’m not opposed to inline XBRL, just concerned that it’s being oversold as XBRL’s savior. It’s basically an application using XBRL data and I think that a small segment of financial data consumers will find it useful. The majority will not. Having left document-based analysis years ago in favor of table-based analysis, popups of metadata and analytics within the raw filing won’t bring them back. And the quality improvements that have been forecast by both the SEC and industry advocates are, in my view, unlikely to be significant. Early results support this view. As a visual representation of XBRL data and a platform for 3rd party add-ons, iXBRL is fine. But the market is small and the danger is that it deflects attention away from the real quality issues that continue to plague XBRL.
Inline XBRL is applicable for large accelerated filers from June 2019 and for the rest of the filers in a phased manner. Would you encourage companies to consider early adoption of iXBRL?
Robert Santoski:
My guess is that compliance software will improve over several reporting cycles in helping filers meet iXBRL requirements, and costs should go down. Since I don’t believe demand for iXBRL will be high among investors, I wouldn’t advise early adoption.
The European Union is introducing Inline XBRL from 1st Jan 2020 with the European Single Electronic Format (ESEF) mandate. With your experience in the US, what advice would you have for companies in the EU?
Robert Santoski:
Focus on the underlying data. Remember that digital reporting and standardization are intended to improve the accessibility and utility of financial disclosures for investors. Every decision made in the creation of the filer’s extension taxonomy should be filtered through that lens.
ESEF requires the XHTML documents to be audited (unlike in the US). What is your opinion on the audit of the XHTML documents?
Robert Santoski:
It’s likely to increase compliance costs and further expose the tension between accountants and investors, and between as-reported and standardized financials.
You published recently the Q2 quality report of US SEC filings, showing an average quality score of 88.1 across 4,610 commercial filings. With 10 years of US SEC reporting, if the quality scores are only at 88.1, what (in your opinion) can the SEC or companies do to get these scores up? What are the major issues in filings? Could you elaborate?
Robert Santoski:
The SEC should reject filings…
- If the extended taxonomy is incomplete or contains errors. Missing calculation arcs are a major problem. As are invalid summations. It’s trivial to test for these issues during file creation or at the SEC.
- If items are tagged from the wrong sector taxonomy, the wrong block within the taxonomy, or the wrong level within the block.
- If extensions are created when a closely related standard element is available, dimensions are preferable, or a custom label can be used.
When the SEC tightens its tolerances and rejects non-conforming filings, companies will focus on these issues and demand more robust compliance software. If we want better quality, the cost to the filer of a sub-standard filing must increase.
Do you have any advice/ suggestions for ESMA?
Robert Santoski:
ESMA has already improved on the SEC’s implementation of XBRL by requiring that extensions (custom elements) be anchored to standard elements. Beyond that, keep the standard taxonomy as simple as possible and insist that filers create complete and compliant extension taxonomies.
How do you envisage XBRL reporting in the next 10 years? Do you expect more use cases for XBRL, other than for financial reporting?
Robert Santoski:
All levels of government reporting are candidates for digital reporting using XBRL. We’re seeing the early stages of that migration. For XBRL to become a ubiquitous standard, all jurisdictions and all applications need to become more responsive to the customer. XBRL data is a product and its features should meet the requirements of the market. Currently, that’s not the case with the SEC’s implementation. But it can be if the SEC solves the extension issue and adopts a much stricter enforcement policy.
Finally, a lot of people say that XBRL is too esoteric, and that has been one of the reasons it hasn’t gotten more popular (across more use cases)? Is this a problem with the standard? With software solutions? What is your opinion can be done to simplify the standard, so laypeople can use it more easily?
Robert Santoski:
XBRL is a bit clunky and there are redundancies in the filings. But the problem is not the format. Alternative machine-readable formats would be equally cryptic to most users. XBRL is designed for programmers and the XML standard is very accessible to that community. The focus should be on the underlying data and not the format chosen for its conveyance.
The views and opinions expressed in this article are those of Robert Santoski’s and do not reflect or represent the views or opinions of IRIS Business Services Ltd. and IRIS CARBON®.
IRIS CARBON®, is a SaaS disclosure management platform bundled with the highest quality services. The platform allows users to prepare and submit filings directly to the SEC, including several EDGAR, XBRL, and iXBRL form types.
