Best Practices for Evaluating an XBRL-based Digital...

BEST PRACTICES FOR EVALUATING AN XBRL-BASED DIGITAL FINANCIAL REPORT

This work is licensed under a Creative Commons License. Public Domain Dedication (CC0 1.0)

https://creativecommons.org/publicdomain/zero/1.0/ 1

Best Practices for Evaluating an XBRL-based

Digital Financial Report

A practical, non-technical, and easy to understand guide for professional accountants to evaluating the quality and functionality

of an XBRL-based general purpose financial report Co-authors:

Charles Hoffman, CPA ([email protected])

Thomas McKinney, CPA ([email protected])

Thomas A. Egan, CPA ([email protected])

Contributors:

Andrew Noble ([email protected]), LodgeiT

Pierre Hamon ([email protected]), etXetera.com

Raynier van Egmond ([email protected])

Hamed Mousavi ([email protected])

Bill Seddon ([email protected]), XBRLQuery

Brian Milnes ([email protected] , XBRL Cloud

2019-04-02 (DRAFT)

How do you know if an XBRL-based financial report you have created or that you are extracting information from has been created properly?

Exactly how would you go about evaluating such a financial report? The Best Practices for Evaluating an XBRL-based Digital Financial Report provides a framework, principles, philosophy, technique, method, and

process for evaluating the quality of an XBRL-based general purpose financial report. This document is prepared specifically for the US GAAP

reporting scheme but is just as applicable to XBRL-based reports created using the IFRS reporting scheme. The document is created for professional accountants and accounting knowledge is assumed. After

reading this material you will be able to effectively evaluate an XBRL-based financial report.

https://creativecommons.org/publicdomain/zero/1.0/

mailto:[email protected]












Copyright (full and complete release of copyright)

All content of this document is placed in the public domain. The

authors hereby waive all claim of copyright in this work. This work may be used, altered or unaltered, in any manner by anyone

without attribution or notice to me. To be clear, we are granting full permission to use any content in this work in any way you like. We

fully and completely release all my rights to any copyright on this content. If you feel like distributing a copy of this work, you may do

so without attribution or payment of any kind. All that said, attribution is appreciated should one feel so compelled. The

copyrights of other works referenced by this document are established by the referenced work.





Introduction How do you know if an XBRL-based financial report you have created or that you are extracting information from has been

created properly? Exactly how would you go about evaluating such a financial report? The Best Practices for Evaluating an XBRL-based

Digital Financial Report provides a framework, principles, philosophy, technique, method, and process for evaluating the

quality of an XBRL-based general purpose financial report. This document is prepared specifically for the US GAAP reporting scheme

but the ideas are just as applicable to XBRL-based reports created using the IFRS reporting scheme. The document is created for

professional accountants and accounting knowledge is assumed.

After reading this material you will be able to effectively evaluate an XBRL-based financial report.

1.1. Need for more specific guidance

While the AICPA’s Principles and Criteria for XBRL-Formatted Information1 lays a good foundation for thinking about how to

create XBRL-based financial reports and evaluate if such reports have been created correctly; the guidance is very general and really

has not been based on specific empirical evidence that proves the guidance actually works. The AICPA’s guidance itself states

(emphasis added):

“The quality of XBRL files is an important concern to users of

these files. Errors in the XBRL files will have varying

consequences. During the development of the XBRL principles and criteria, potential errors that could occur when

preparing XBRL files were considered, and it is believed that the criteria addresses many of these errors. Further, the

principles and criteria meet the requirements under AT section 101, as previously discussed in paragraphs .11-.13, and, thus

are considered suitable for practitioners to perform an attestation engagement.”

Accountants and auditors cannot “believe” that such a report is correct using a process that “addresses many of these errors”.

Accountants and auditors need to make sure no errors exist using specific automated and manual processes and procedures that are

designed to maximize report quality.

Also, accountants and analysts don’t use “files”. They use

information that is contained within those files. It is not the

1 American Institute of Certified Public Accountants, 2017, Principles and Criteria for XBRL-Formatted

Information, https://www.aicpa.org/InterestAreas/FRC/AccountingFinancialReporting/XBRL/DownloadableDocuments/aicpa-principles-and-criteria-for-xbrl-formatted-information.pdf


https://www.aicpa.org/InterestAreas/FRC/AccountingFinancialReporting/XBRL/DownloadableDocuments/aicpa-principles-and-criteria-for-xbrl-formatted-information.pdf





physical files that need to be evaluated; it is the information that is

contained within those files. The files themselves can be evaluated using automated processes.

So, what does a report creator need to do if they want to address all of the possible errors? What exactly are all of the possible errors

that could occur? What good is an XBRL-based financial report if you don’t understand what errors it has of if you don’t even know

the nature of the errors that may exist2? How safe would it be to use such XBRL-based information? How do you specify what

consulting services that you need performed to make sure your report conveys information correctly? What is an acceptable error

rate? How do you measure your error rate?

As such, more specific guidance is necessary.

1.2. Internal control over financial reporting

In their document Guide to Internal Control over Financial

Reporting3, the Center for Audit Quality states:

Preparing reliable financial information is a key responsibility

of the management of every public company. The ability to effectively manage the company’s business requires access to

timely and accurate information. Moreover, investors must be able to place confidence in a company’s financial reports if the

company wants to raise capital in the public securities markets.

Management’s ability to fulfill its financial reporting responsibilities depends in part on the design and effectiveness of the processes

and safeguards it has put in place over accounting and financial reporting. Without such controls, it would be extremely difficult for

most business organizations — especially those with numerous

locations, operations, and processes — to prepare timely and reliable financial reports for management, investors, lenders, and

other users. While no practical control system can absolutely assure that financial reports will never contain material errors or

misstatements, an effective system of internal control over financial reporting can substantially reduce the risk of such misstatements

and inaccuracies in a company’s financial statements.

In no place in the statement of the importance of internal controls

does it distinguish between paper-based information published for

2 Understanding Logical, Mechanical, and Mathematical Accounting Relations in XBRL-based Digital

Financial Reports, http://xbrl.squarespace.com/journal/2016/12/15/understanding-logical-mechanical-and-mathematical-accounting.html 3 Center for Audit Quality, Guide to Internal Control Over Financial Reporting,

http://www.thecaq.org/sites/default/files/caq_icfr_042513.pdf


http://xbrl.squarespace.com/journal/2016/12/15/understanding-logical-mechanical-and-mathematical-accounting.html

http://xbrl.squarespace.com/journal/2016/12/15/understanding-logical-mechanical-and-mathematical-accounting.html

http://www.thecaq.org/sites/default/files/caq_icfr_042513.pdf




the consumption of humans and machine-readable information

formatted for the consumption by computer based processes.

XBRL-formatted information is not part of an audit yet. But it

seems to us that it also could be quite appropriate for auditors to include a point in their management representation letters for 10-K

audit and 10-Q review engagements related to XBRL-formatted information. This is a very practical way for CPAs to educate their

clients about XBRL-based reports, encourage their clients to get their XBRL right, and if nothing else it proves that they addressed

this subject with their clients, that the clients are aware of SEC filing requirements and potential sanctions regarding XBRL (i.e. the XBRL

is “filed” and is subject to SEC review and enforcement action if there are errors in the XBRL-based information), and the auditors

have no responsibility for the XBRL as it is not (yet) part of an audit.

CPA firms can use the management letter comments to initialize a

dialog with management and the audit committee of their clients to ensure their clients have adequate internal controls over financial

reporting (ICFR) in place related to XBRL. Further, this is a great way to offer their consulting services if internal controls and

processes are lacking. This puts the burden of XBRL compliance (or lack thereof) squarely on the shoulders of public companies and

their audit committees. They might take the XBRL more seriously.

1.3. Misconceptions related to the “audit of XBRL”

There are many misconceptions professional accountants,

professional auditors, and others have about the “audit of XBRL”. The first misconception is that XBRL is audited at all. XBRL is a

technical format. The XBRL technical format can be verified 100%

by automated software tests. That is the purpose of the XBRL International XBRL conformance suite tests4. Those tests are used

to build automated machine-based processes to be sure the XBRL technical syntax is right. But XBRL conformance suite tests do

not, and cannot, check to see if the meaning conveyed by the XBRL-formatted information is correct.

Second, when one “audits” the financial information represented in the form of paper you are not auditing the paper you are auditing

the information represented on the paper. In my document Thoughts on Auditing XBRL-formatted Information5 I point out that

the meaning conveyed by the XBRL-formatted information and the

4 XBRL International, XBRL 2.1, https://specifications.xbrl.org/work-product-index-group-base-spec-

base-spec.html 5 Thoughts on Auditing XBRL-formatted Information,

http://xbrlsite.azurewebsites.net/2017/Library/ThoughtsOnAuditingXBRLBasedInformation.pdf


https://specifications.xbrl.org/work-product-index-group-base-spec-base-spec.html






meaning conveyed by paper-based or “e-paper” information

including electronic forms of paper like HTML and PDF convey the exact same meaning.

Third, you don’t need third party auditors to make sure you get things right. The purpose of an audit is to provide an independent

third party opinion as to whether reported information about the financial condition and financial position of an economic entity is

being represented fairly by the information provided in a financial report. The audit is about the independent third party opinion as to

the fairness of that information. You can create financial information correctly even if the information is not audited. Most

professional accountants can do that fine.

Fourth, external financial reporting managers need to create true

and fair representations of their financial information. The team that works with the external financial reporting manager needs to

make sure the financial report is true and fair. Internal auditors

that work for a company to make sure the external financial reporting manager is doing their job correctly need to make sure

the information is true and fair. Finally, the CFO that signs off on the report needs to make sure the financial report information is

true and fair. The point here is that there are lots of people who care that the information contained in a financial report is

represented appropriately, not just auditors.

1.4. Transitioning to a new future

One type of practical knowledge is know-how; how to accomplish

something.

A kluge is a term from the engineering and computer science world

that refers to something that is convoluted and messy but gets the

job done. Elegance is the quality of being pleasingly ingenious, simple, and neat. Elegance is about beating down complexity.

Creating something complex is easy. Creating something simple and elegant is hard work.

XBRL-based financial reporting today is a kludge. The “rush to detail” is a mistake where people tend to focus on the details before

they have considered the broader goals and structure of what they are trying to accomplish. This rush to detail approach is like starting

to build a house by laying bricks, rather than drawing plans and establishing foundations.

We are taking a different approach. We are establishing a framework, principles, and theory for thinking about financial

reports and then backing into the important details; we are establishing a rock-solid foundation and then laying the bricks on

that foundation.





1.5. Best practices

A best practice is a method or technique that has been generally

accepted as superior to any known alternatives because it produces results that are superior to those achieved by other means or

because it has become a standard way of doing things.

This document describes best practices learned from analyzing

thousands of XBRL-based financial reports prepared using US GAAP and IFRS and have been submitted to the U.S. Securities and

Exchange Commission over a period of about 10 years. An engineering design process was used to derive these best practices;

not personal opinion, philosophical debates, political discussions, or theological dogma. These best practices are pure engineering.

1.6. Understanding our approach

The details of our approach taken in this document are explained in

the Financial Report Semantics and Dynamics Theory6, the Logical Theory Describing a Business Report7, and the Method of

Implementing a Standard Digital Financial Report Using the XBRL Syntax8. Reading those documents is not necessary in applying the

techniques, procedures, and practices of this document. However, understanding why these ideas work can be understood by reading

those documents.

Finally, most professional accountants don’t really understand how

computers actually perform work. The document Computer

Empathy9 fills in important gaps in understanding that help solidify the ideas used in this document.

1.7. Intended audience of this document

The intended audience of this document is professional accountants and financial analysts that create or use XBRL-based structured

digital financial reports. This document strives to be as non-technical as possible. Given the right tools, 100% of the technical

aspects of XBRL-based reporting will disappear deep into software applications exposing only the financial reporting related logic with

which professional accountants are familiar. The readers of this

6 Charles Hoffman, CPA and Rene van Egmond, Financial Report Semantics and Dynamics Theory,

http://xbrl.squarespace.com/fin-report-sem-dyn-theory/ 7 Charles Hoffman, CPA and Rene van Egmond, Logical Theory Describing a Business Report,

http://xbrlsite.azurewebsites.net/2019/Library/LogicalTheoryDescribingBusinessReport.pdf 8 Charles Hoffman, CPA and Rene van Egmond, Method of Implementing a Standard Digital Financial

Report Using the XBRL Syntax, http://xbrlsite.azurewebsites.net/2019/Library/MethodForImplementingStandardFinancialReportUsingXBRL.pdf 9 Charles Hoffman, CPA, Computer Empathy,

http://xbrlsite.azurewebsites.net/2018/Library/ComputerEmpathy.pdf


http://xbrl.squarespace.com/fin-report-sem-dyn-theory/

http://xbrlsite.azurewebsites.net/2019/Library/LogicalTheoryDescribingBusinessReport.pdf

http://xbrlsite.azurewebsites.net/2019/Library/MethodForImplementingStandardFinancialReportUsingXBRL.pdf


http://xbrlsite.azurewebsites.net/2018/Library/ComputerEmpathy.pdf




document are assumed to understand accounting and financial

reporting.

1.8. Organization of this document

This document is organized to be read linearly, start to finish. We

strive to summarize high-level ideas in this document and reference other documentation which is available to explain those details

further to the reader should they be interested in those details.

1.9. Terminology

For effective communication to occur, we need to be sure we are using the same terminology. The following is important terminology

that is used within this document and the definition of those terms as we use that term in this document.

Term Meaning

XBRL XBRL is a technical syntax that, among other things, can be used to represent a general purpose

financial report in machine-readable terms. XBRL is concerned with the representation of information.

Inline XBRL Inline XBRL is an approach to representing

information within an XHTML file. Inline XBRL is focused on the presentation of information.

Report Report which communicates financial and nonfinancial information about an economic or

accounting entity to users of that report. Financial

reports contain facts, characteristics which describe those facts, parenthetical explanations of facts,

relations between facts.

Fragment A fragment is a set of one or more fact sets. For

example, a "balance sheet" is a fragment that is made up of two fact sets, an assets roll up and a

liabilities and equity roll up.

Fact set A fact set (a.k.a. block or fact table) is a set of facts which go together (tend to be cohesive and share a

certain common nature) for some specific purpose within a financial report. For example, an "income

statement" is a fact set. The "Maturities of long-term debt" disclosure is a fact set.





Term Meaning

Fact A fact is reported. A fact defines a single,

observable, reportable piece of information contained within a financial report, or fact value,

contextualized for unambiguous interpretation or analysis by one or more distinguishing

characteristics. A fact value is one property of a fact; every fact has exactly one fact value. The set

of characteristics of a fact is a property of the fact. For example, Cash and cash equivalents of 100,000

for the consolidated entity for the current balance sheet date of December 31, 2014 which is reported

in US Dollars is a fact.

Characteristic A characteristic (a.k.a. aspect) describes a fact. A characteristic or distinguishing aspect provides

information necessary to describe a fact or distinguish one fact from another fact. A fact may

have one or many distinguishing characteristics. For example, line item concept Cash and cash

equivalents is a characteristic and the calendar period December 31, 2014 are characteristics which

describe a fact.

Parenthetical explanation

Facts may have parenthetical explanations which provide additional descriptive information about the

fact.

Rule A rule10 is used to guide, control, suggest, or influence behavior. Rules cause things to happen,

prevent things from happening, or suggest that it might be a good idea if something did or did not

happen. Rules help shape judgment, help make decisions, help evaluate, help shape behavior, and

help reach conclusions.

Relation A relation11 is some interaction between the pieces which make up a financial report. Report

components can be related to other report components.

10 Charles Hoffman, CPA and Rene van Egmond, Comprehensive Introduction to Business Rules,

http://xbrlsite.azurewebsites.net/2017/IntelligentDigitalFinancialReporting/Part01_Chapter02.4_ComprehensiveIntroductionToBusinessRules.pdf 11 A Taxonomy of Part-Whole Relations:

http://csjarchive.cogsci.rpi.edu/1987v11/i04/p0417p0444/MAIN.PDF


http://xbrlsite.azurewebsites.net/2017/IntelligentDigitalFinancialReporting/Part01_Chapter02.4_ComprehensiveIntroductionToBusinessRules.pdf

http://xbrlsite.azurewebsites.net/2017/IntelligentDigitalFinancialReporting/Part01_Chapter02.4_ComprehensiveIntroductionToBusinessRules.pdf

http://csjarchive.cogsci.rpi.edu/1987v11/i04/p0417p0444/MAIN.PDF




Term Meaning

Property A property is a trait, quality, feature, attribute, or

peculiarity which is used to define its possessor and is therefore dependent on the possessor. A property

belongs to something. For example, the color of a ball belongs to and is therefore is dependent on (is

a property of) the ball.

Disclosure A disclosure is simply a set of facts that is

disclosed, a fact set. One or more fact sets can

make up a disclosure. For example, a balance sheet is made up of two fact sets; an assets roll up

and a liabilities and equity roll up.

Topic A topic is simply a set of disclosures that are

grouped together for some specific reason.

Information model

definition

An information model definition (a.k.a. report definition) is the definition of the fragments, fact

sets, aspects, aspect arrangement patterns, rules, disclosures, reporting style, that define the

structure of a report.

Reporting scheme

A reporting scheme12 is the financial reporting scheme used to create the information model

definition. For example, US GAAP and IFRS are reporting schemes.

Reporting

style

A reporting style13 describes the arrangement of

high-level fundamental accounting concepts that are used to represent the balance sheet, income

statement, statement of comprehensive income, and cash flow statement of a report.

1.10. Inline XBRL layer

This document does not cover the presentation of information using

the Inline XBRL layer of a structured general purpose financial report. The Inline XBRL layer is a supplement to everything

discussed in this document. This document relates to the representation of the information model of an XBRL-based report

12 High level comparison of reporting schemes,

http://xbrlsite.azurewebsites.net/2018/Library/ReportingSchemes-2018-12-30.pdf 13 Charles Hoffman, CPA and Rene van Egmond, Understanding Fundamental Accounting Concepts

and Reporting Styles, http://xbrlsite.azurewebsites.net/2017/IntelligentDigitalFinancialReporting/Part02_Chapter05.6_UnderstandingFundamentalAccountingConceptRelationsAndReportingStyles.pdf


http://xbrlsite.azurewebsites.net/2018/Library/ReportingSchemes-2018-12-30.pdf

http://xbrlsite.azurewebsites.net/2017/IntelligentDigitalFinancialReporting/Part02_Chapter05.6_UnderstandingFundamentalAccountingConceptRelationsAndReportingStyles.pdf





and the meaning of the information conveyed by that report.

Whether those facts are contained in an Inline XBRL formatted document or a “raw XBRL” (i.e. not Inline XBRL); the information in

this document is relevant. Mapping facts into the Inline XBRL presentation layer is a rater straight forward process and beyond

the scope of this document.

2. Essence of a General Purpose Financial Report

A general purpose financial report is a high-fidelity, high-resolution, high-quality information exchange mechanism. The report is a

compendium of complex logical information required by statutory requirements and regulatory rules plus whatever management of an

economic entity wants to voluntarily disclose. The report represents quantitative and qualitative information about the financial condition

and financial performance of an economic entity. There are a number of different financial reporting schemes14 that might be

used to create that report: US GAAP, IFRS, IPSAS, GAS, FAS, etc.

2.1. Variability

Financial reports are not uniform. Financial reports are not forms,

they have variability. This consciously allowed variability is an

essential, characteristic trait of robust reporting schemes such as US GAAP, IFRS, and others. This variability contributes to the

richness, high-fidelity, and high-resolution nature of reported financial information that is unique to an industry sector, a style of

reporting, or an economic entity. This variability is a feature of such reporting schemes. Different reporting styles, different subtotals

used to aggregate details, and using some specific approach given a set of allowed alternatives are examples of variability. Variability

does not mean “arbitrary” or “random”. There are known identifiable patterns that exist in general purpose financial reports.

2.2. Basic use case

Consider the following use case of a general purpose financial

report:

Two economic entities, A and B, each have information about

their financial position and financial performance. They must communicate their information to an investor who is making

investment decisions which will make use of the combined information so as to draw some conclusions. All three parties

14 Charles Hoffman, CPA, Comparison of Financial Reporting Schemes High Level Concepts,







(economic entity A, economic entity B, investor) are using a

common set of basic logical principles (facts, statements, deductive reasoning, inductive reasoning, etc.), common

financial reporting standard concepts and relations (i.e. US GAAP, IFRS, IPSAS, etc.), and a common world view so they

should be able to communicate this information fully, so that any inferences which, say, the investor draws from economic

entity A's information should also be derivable by economic entity A itself using basic logical principles, common financial

reporting standards (concepts and relations), and common world view; and vice versa; and similarly for the investor and

economic entity B.

And so the fundamental purpose of a general purpose financial

report is to exchange information between some information bearer and some information consumer.

2.3. Principles

The following is a set of principles related to a general purpose

financial report:

1. A general purpose financial report is a high-fidelity, high-

resolution, high-quality information exchange mechanism.

2. Prudence dictates that using information from a general

purpose financial report should not be a guessing game.

3. All formats of a general purpose financial report conveying

information should convey the exact same meaning be that format paper, e-paper, or some machine readable format.

4. A rule is used to guide, control, suggest, or influence behavior. Rules cause things to happen, prevent things from

happening, or suggest that it might be a good idea if

something did or did not happen. Rules help shape judgment, help make decisions, help evaluate, help shape behavior, help

communication, and help reach conclusions.

5. The only way to achieve a meaningful exchange of

information without disputes is with the prior existence of and agreement as to a standard set of technical syntax rules,

business logic rules, and workflow rules.

6. Explicitly stated information from information bearers or

reliably derived information is preferable to requiring information receivers to make assumptions.

7. Reports can be guaranteed to be defect free using automated processes to the extent that machine-readable rules exist.





8. When possible to effectively create, machine-based

automated processes tend to be more desirable than human-based manual processes because machine processes tend to

be more reliable and cost less.

9. Complexity cannot be removed from a system, but complexity

can be moved15.

10. Double entry accounting enables processes that allow

for the detection of information errors and to distinguish errors (unintentional mistakes) from fraud (intentional

misleading information).

11. Catastrophic logical failures are to be avoided at all cost

as they cause systems to completely fail.

Depicted graphically; the essence of what is taking place when an

economic entity, an information bearer, provides information to some information receiver such as an investor, regulator, or lender;

is such:

All of the moving parts of an XBRL-based general purpose financial

report can be described logically in a manner that is easy for a professional accountant to understand. A logical theory, such as the

Logical Theory Describing a Business Report16, defines and describes things. A general purpose financial report is a

specialization of the more general business report.

Rules are used to articulate allowed variability and “channel”

creators of reports in the right direction and therefore control variability, keeping the variability within standard limits. That

keeps report quality where it needs to be. Rules enable things like preventing a user from using a concept meant to represent one

thing from unintentionally being used to represent something

15 Larry Teslar, The Law of Conservation of Complexity,

http://www.nomodes.com/Larry_Tesler_Consulting/Complexity_Law.html 16 Charles Hoffman, CPA and Rene van Egmond, Logical Theory Describing a Business Report,



http://www.nomodes.com/Larry_Tesler_Consulting/Complexity_Law.html





different. Further, the discipline of describing something in a form a

computer algorithm can understand also assists you in understanding the world better; weeding out flaws in your

understanding, myths, and misconceptions about accounting and reporting standards.

The Method of Implementing a Standard Digital Financial Report Using the XBRL Syntax17 is a document that explains a best practice

based, open standard approach to implementing a financial report leveraging the forth coming OMG Standard Business Report Model

(SBRM).

To understand the above method, I created a project which

represents a portion of the International Public Sector Accounting Standards (IPSAS) step-by-step using that method18.

2.4. General purpose financial report system narrative

A financial report is simply some internal or external financial

report which reports financial and nonfinancial information consistent with statutory laws and/or regulatory rules. Financial

reports are collections of fragments which make up the larger report.

A financial report fragment is a set of facts which go together (tend to be cohesive and share a certain common nature) for some

specific purpose within a financial report. For example, a "balance sheet" is a fragment of a financial report. "Maturities of long-term

debt" is a fragment of a financial report.

A fact describes a single, observable, piece of financial or

nonfinancial information contained within a financial report which is contextualized for unambiguous interpretation or analysis by

distinguishing characteristics of the fact. Every fact has exactly one

value. Every fact must have each of the core characteristics (reporting entity, calendar period, and concept) but may have

additional noncore characteristics.

A characteristic (a.k.a. aspect) provides information necessary to

describe a fact or unambiguously distinguish one fact from another fact.

A document is an organized set of financial report fragments. Report fragments are sequenced or organized in an appropriate

17 Charles Hoffman, CPA and Raynier van Egmond, Method of Implementing a Standard Digital

Financial Report Using the XBRL Syntax, http://xbrlsite.azurewebsites.net/2019/Library/MethodForImplementingStandardFinancialReportUsingXBRL.pdf 18 International Public Sector Accounting Standards XBRL Taxonomy Prototype Project,

http://xbrl.squarespace.com/journal/2019/1/16/international-public-sector-accounting-standards-xbrl-taxono.html









flow. A financial report can be sensibly and logically represented as

an electronic document (such as a Word or PDF document), a web document (such as an HTML file or Wiki page), dynamic

multidimensional hypercube, a spreadsheet, or any other visual form including something provided by a dynamic viewing application

(such as a pivot table, or drill-down information viewer).

2.5. Quality

As stated, a general purpose financial report is a high-fidelity, high-

resolution, high-quality information exchange mechanism. The report is a set of disclosures required by statutory requirements and

regulatory rules plus whatever management of an economic entity wants to voluntarily disclose.

Let’s be clear about the terms we are using and the need for low to

zero tolerance for error. Specifically, let’s be clear about the following definitions:

Reliability is about getting consistent results each time an activity is repeated.

Accuracy is about identifying the correct target. Accuracy relates to correctness in all details; conformity or

correspondence to fact or given quality, condition; deviating within acceptable limits from a standard. Accuracy means

with no loss of resolution or fidelity of what the sender wishes to communicate and no introduction of false knowledge or

misinterpretation of communicated information.

Completeness relates to having all necessary or normal

parts, components, elements, or steps; entire.

Correctness relates to freedom from error; in accordance

with fact or truth; right, proper. Consistency relates to being

compatible or in agreement with itself or with some group; coherent, uniform, steady. Holding true in a group,

compatible, not contradictory.

Precision is the closeness of repeated measurements to one

another. Precision involves choosing the right equipment and using that equipment properly. Precise readings are not

necessarily accurate. A faulty piece of equipment or incorrectly used equipment may give precise readings (all

repeated values are close together) but inaccurate (not correct) results.

Fidelity relates to the exactness or loyal adherence facts and details with which something is copied or reproduced. Fidelity

relates to the faithful representation of the facts and circumstances represented within a financial report properly





reflect, without distortion, reality. High fidelity is when the

reproduction (a financial report) with little distortion, provides a result very similar to the original (reality of economic entity

and environment in which economic entity operates).

Integrity is the quality or condition of being whole or

undivided; completeness, entireness, unbroken state, uncorrupt. Integrity means that not only is each piece of a

financial report correct but all the pieces of the financial report fit together correctly, all things considered.

Resolution relates to the amount of detail that you can see. The greater the resolution, the greater the clarity.

In a perfect world, computers would perform the translation of a financial report from the human-readable representation into a

machine-readable representation. Likewise, computers on the receiving end would ingest this reported information in a way that

brings desired value to the people who wish to understand and use

that information. In this perfect world, neither creator nor consumer of the information should need to get involved in this translation

process from human-readable to machine-readable information and back again.

Sadly, software today which is used in such a system is not yet good enough so financial professionals cannot understand, or even

believe or comprehend how such a system could possibly even work. And the reasons software is not good enough yet are not a

mystery. One of the primary reasons that no such software yet exists is the lack of a well-suited standard information model that

can be represented in XBRL. And so, it is difficult to have software that utilizes such a standard model when the model does not yet

even exist.

Another reason such software does not exist is that XBRL is under-

utilized generally because XBRL is poorly understood. A third

reason such software does not exist is that the metadata that would drive such software and make it work appropriately has not been

created yet because people tend to not understand XBRL and that it actually provides the means to represent that needed metadata.

Now we begin to see the need for some sort of methodology. A methodology can help illuminate the structure of a financial report.

With that methodology, some method for making the promise of XBRL-based digital financial reporting a reality can be created,

tested, and it can be determined if the system is meeting the needs of system stakeholders.





2.6. Risks

Below is a summary of the risks which could lead to a financial

report being invalid and the risk mitigation assertion or verification task which would assure that the risk goes unrealized.

Risk Risk Mitigation Assertion (Verification

task)

Full inclusion: All relevant facts, fact

sets, characteristics which describe facts and distinguish one fact from another fact, parenthetical explanations of facts, and relations between facts/characteristics are not included in the financial report.

Completeness: All relevant facts, fact sets,

characteristics of facts, parenthetical explanations of facts, and relations between facts/characteristics have been included.

False inclusion: No facts, characteristics

which describe facts, parenthetical explanations of facts, or relations between facts/characteristics which should not be included have been included.

Existence: No facts, characteristics which

describe facts, parenthetical explanations of facts, relations between facts/characteristics are included within financial report which should not be included.

Inaccuracy: Property of a fact, fact set,

characteristic, component, or relation is inaccurate. (For example, mathematical relations and model logical structure relations.)

Accuracy: The properties of all facts, fact

sets, characteristics, components, parenthetical explanations, relations between facts/characteristics which are included in the financial report are accurate, correct, and complete.

Infidelity: All facts, characteristics,

parenthetical explanations, and relations considered as a whole do not possess the required fidelity when considered as a whole.

Fidelity = faithful representation.

Fidelity: Considered as a whole; the facts,

characteristics, parenthetical explanations, and relations between facts/characteristics properly reproduces the financial and nonfinancial facts, characteristics, and relations of the reporting entity and provide a true and fair representation of such financial information.

Integrity not intact: Integrity between facts/characteristics is inappropriate.

Integrity: Considered as a whole, the facts and characteristics of those facts reflect the true and proper relations between such facts and characteristics.

Inconsistency: The facts, characteristics, parenthetical explanations, relations and

their properties expressed are inconsistent with prior reporting periods or with peers of the reporting entity.

Consistency: The facts, characteristics, parenthetical explanations, relations between

facts/characteristics, and their properties are consistent with prior periods and with the reporting entities peers, as is deemed appropriate.

Not presented fairly: The financial report is not presented fairly, in all material respects, and are not a true and fair representation in accordance with the financial reporting framework applied.

True and fair representation: The financial report is a true and fair representation of the information of the reporting entity. An auditor might say presented fairly, in all material respects, and provide a true and fair representation in accordance with the financial

reporting framework applied.





2.7. Contrasting comparability and uniformity

Per SFAS 819 issued by the FASB, page 19, QC23:

"Comparability is not uniformity. For information to be comparable, like things must look alike and different things must look different.

Comparability of financial information is not enhanced by making unlike things look alike any more than it is enhanced by making like

things look different."

It is important to understand what the FASB means by

"comparability (including consistency)". That is explained in SFAS 820. Here is the pertinent section of that document. This is well

stated, very clear, and every word is worth reading:

Comparability:

QC20. Users' decisions involve choosing between alternatives,

for example, selling or holding an investment, or investing in one reporting entity or another. Consequently, information

about a reporting entity is more useful if it can be compared with similar information about other entities and with similar

information about the same entity for another period or another date.

QC21. Comparability is the qualitative characteristic that enables users to identify and understand similarities in, and

differences among, items. Unlike the other qualitative characteristics, comparability does not relate to a single item.

A comparison requires at least two items.

QC22. Consistency, although related to comparability, is not

the same. Consistency refers to the use of the same methods for the same items, either from period to period within a

reporting entity or in a single period across entities.

Comparability is the goal; consistency helps to achieve that goal.

QC23. Comparability is not uniformity. For information to be comparable, like things must look alike and different things

must look different. Comparability of financial information is not enhanced by making unlike things look alike any more

than it is enhanced by making like things look different.

QC24. Some degree of comparability is likely to be attained

by satisfying the fundamental qualitative characteristics. A

19 FASB, Statement of Financial Accounting Concepts No. 8, page 19,

http://www.fasb.org/cs/BlobServer?blobcol=urldata&blobtable=MungoBlobs&blobkey=id&blobwhere=1175822892635&blobheader=application/pdf 20 FASB, Statement of Financial Accounting Concepts No. 8, page 19,

http://www.fasb.org/cs/BlobServer?blobcol=urldata&blobtable=MungoBlobs&blobkey=id&blobwhere=1175822892635&blobheader=application/pdf









faithful representation of a relevant economic phenomenon

should naturally possess some degree of comparability with a faithful representation of a similar relevant economic

phenomenon by another reporting entity.

QC25. Although a single economic phenomenon can be

faithfully represented in multiple ways, permitting alternative accounting methods for the same economic phenomenon

diminishes comparability.

US GAAP is an excellent financial reporting scheme because it

strikes a good balance between the ability to compare and the ability to accurately report the financial condition and financial

position of an economic entity. When trying to implement "comparisons" in software, it is very important to understand the

goal of comparability the financial reporting scheme enables.

2.8. Distinguishing the objective from the and subjective

Aspects of creating a financial report are objective and other aspects subjective and it is critically important to differentiate the

two. First, here are important definitions so we can be clear as to what we are saying:

Objective: not influenced by personal feelings or opinions in considering and representing facts; based on facts rather than

feelings or opinions; not influenced by feelings; facts are objective.

Subjective: based on or influenced by personal feelings, tastes, preferences, or opinions; based on feelings or opinions

rather than facts; relating to the way a person experiences things in his or her own mind; opinions are subjective.

Judgment: the ability to make considered decisions or come

to sensible conclusions; an opinion or decision that is based on careful thought; judgment is subjective.

While it is the case that what is required to be put into a financial report itself can many times be subjective, many other aspects of

the report itself are objective. For example, there is nothing subjective about whether the mathematical relations of a roll up or

roll forward must work. Of course a roll up must actually roll up and a roll forward must actually roll forward. It can be true that

professional accountants could choose between one approach to disclosing the roll up of some subcomponent of a financial report

line item or another. It might even be the case that a roll forward could be provided rather than a roll up. Choosing between allowed

alternatives is subjective and determined by the judgment of a professional accountant. But, things like the rules of mathematics

and the rules of logic are in no way subjective and must be followed





by accountants and the standard setters creating financial reporting

schemes.

2.9. Financial reporting conceptual framework

It is worth pointing out the “rush to detail” mistake that is often

made as contrast to drawing plans and establishing foundations. We also point out the special role of certified public accountants

who are responsible for balancing the needs of the creator of a financial report and investors, analysts, and regulators that

consume information from such reports.

Financial reporting has a conceptual framework. The FASB outlines

this conceptual framework in CON 1 – 7. The FASB has updated this conceptual framework through Statements of Financial Accounting

Concepts (SFACs). This conceptual framework is explained in

intermediate accounting text books and financial reporting research resources.

Per the FASB, the conceptual framework for financial reporting has two primary purposes. First, it serves as a foundation upon which

the FASB constructs financial reporting standards that are internally sound and consistent. Second, the conceptual framework is

intended to be used by the business community reporting or consuming financial information to help them better understand and

apply financial reporting standards.

The conceptual framework does this by per the FASB Special

Report, The Framework of Financial Accounting Concepts and Standards21:

Providing a set of common premises as a basis for discussion

Provide precise terminology

Helping to ask the right questions

Limiting areas of judgment and discretion and excluding

from consideration potential solutions that are in conflict with it

Imposing intellectual discipline on what traditionally has been a subjective and ad hoc reasoning process

It is critical for professional accountants evaluating a financial report to keep the conceptual framework of financial reporting in the

forefront of their mind when they perform their work.

21 FASB, FASB Special Report: The Framework of Financial

Accounting Concepts and Standards, January 1998, page 86, https://www.fasb.org/jsp/FASB/Page/SectionPage&cid=1176171747007


https://www.fasb.org/jsp/FASB/Page/SectionPage&cid=1176171747007




3. Decomposing a Financial Report And so, a full financial report is made up of fragments, or report fragments as the US GAAP Financial Reporting Taxonomy

Architecture calls them22. The US GAAP Financial Reporting Taxonomy Architecture goes on to explain the notion of a

schedule. The architecture document says, “A ‘Schedule‘ appears as a set of concepts within a relationship group and the root

concept of a schedule is a text block.23” And then the architecture discusses facts and relations between fragments and facts even

providing a UML diagram to explain the relationship24 precisely.

So, the descriptions of these terms and the relations between the

terms is not necessarily clear as provided by the US GAAP Financial Reporting Taxonomy Architecture; however, the architecture is

trying to articulate the pieces of a financial report, what those pieces do, and how the pieces interact with one another.

We have similarly decomposed the objects of a financial report. The following is a comparison of the terms that we use reconciled to the

terms the US GAAP Financial Reporting Taxonomy Architecture uses

as best as possible:

22 FASB, US GAAP Financial Reporting Taxonomy Architecture Version 2014, page 4,

https://www.fasb.org/cs/ContentServer?c=Document_C&cid=1176163689810&d=&pagename=FASB%2FDocument_C%2FDocumentPage 23 FASB, US GAAP Financial Reporting Taxonomy Architecture Version 2014, page 15, Section 3.2.2

Schedules, https://www.fasb.org/cs/ContentServer?c=Document_C&cid=1176163689810&d=&pagename=FASB%2FDocument_C%2FDocumentPage 24 FASB, US GAAP Financial Reporting Taxonomy Architecture Version 2014, page 13, Figure 6,

https://www.fasb.org/cs/ContentServer?c=Document_C&cid=1176163689810&d=&pagename=FASB%2FDocument_C%2FDocumentPage











Definition

Our Term

US GAAP Financial

Reporting

Taxonomy Term

A report is information published by a

reporting entity at some point in time

for some purpose.

Report Financial Report

A fragment is a set of one to many fact

sets which go together for some specific

purpose within a report.

Fragment Report Fragment

A fact set is a set of facts which go

together (tend to be cohesive and share

a certain common nature) for some

specific purpose within a report.

Fact Set Schedule

A fact is reported. A fact defines a

single, observable, reportable piece of

information contained within a report

contextualized for unambiguous

interpretation or analysis by one or

more distinguishing aspects.

Fact Fact

All the terms correlate pretty well with the possible exception of

“fact set” and “schedule”. The way the US GAAP Financial Reporting Taxonomy Architecture uses the term schedule is not as clear as it

needs to be. While we did not provide the complete logical model of a financial report above, understanding that complete model is

helpful. You can find the complete model in Logical Theory Describing a Business Report25.

3.1. Example decomposition overview

To better solidify the understanding of these terms let me provide a

specific example. I will use the Microsoft 2017 10-K26 report to explain the difference between a report, fragment, fact set, and

fact. You can use the SEC Interactive Data Viewer27, the freely available XBRL Cloud Viewer28, or any tool of your choice that

provides the sorts of information I will show you in this section.

25 Charles Hoffman, CPA and Rene van Egmond, Logical Theory Describing a Business Report,

http://xbrlsite.azurewebsites.net/2019/Library/LogicalTheoryDescribingBusinessReport.pdf 26 Microsoft 10-K for 2017,

https://www.sec.gov/Archives/edgar/data/789019/000156459017014900/0001564590-17-014900-index.htm 27 Microsoft 10-K in SEC Interactive Data Viewer, https://www.sec.gov/cgi-

bin/viewer?action=view&cik=789019&accession_number=0001564590-17-014900&xbrl_type=v 28 Microsoft 10-K in XBRL Cloud Viewer,

https://edgardashboard.xbrlcloud.com/flex/viewer/XBRLViewer.html#instance=http://www.sec.gov/Archives/edgar/data/789019/000156459017014900/msft-20170630.xml



https://www.sec.gov/Archives/edgar/data/789019/000156459017014900/0001564590-17-014900-index.htm

https://www.sec.gov/Archives/edgar/data/789019/000156459017014900/0001564590-17-014900-index.htm

https://www.sec.gov/cgi-bin/viewer?action=view&cik=789019&accession_number=0001564590-17-014900&xbrl_type=v







So here is a partial view of the Microsoft 10-K report. You see the

fragments of that report in a list on the left circled in red. You see the rendering of the selected fragment on the right.

If you change to the “Fact Table” view you see what the XBRL Cloud

viewer calls that Fact Table; we call this same thing the “Fact Set”. It is simply the individual facts that make up the selected report

fragment.

You will get a better appreciation of the difference between a fragment and a fact set when we look at the balance sheet. So

switching over to the SEC Interactive Data viewer because with that we can see the entire balance sheet, you see the following:





The balance sheet fragment is made up of two fact sets. The first fact set is the set of facts that makes up the Assets [Roll Up]. The

second fact set is the set of facts that makes up the Liabilities and Equity [Roll Up]. Now, this may not make a lot of sense. You

might ask, “Why would you ever use half of the balance sheet, you need both the assets roll up and the liabilities and equity roll up to

work with the balance sheet.” And you would be right, you typically

work with both the assets and liabilities and equity roll ups when you work with the balance sheet. But, for other report fragments,

this is not necessarily true.

Further, the facts for the balance sheet all fit into one fact set or

fact table. Why would you need to separate those out? Well, in this case that is a good question because we do not need to separate

the assets roll up and liabilities and equity roll up facts. Except, when we do. We do want to separate the balance sheet fragment

when we only want to work with the assets roll up facts.





Let’s go back to the first fragment we looked at, the document and entity information. Take a close look at what you see. First, the

name is a dead giveaway, “Document and Entity Information”. So, this is really two fact sets that you have no way of separating

unless you want to separate the “document information” from the “entity information” and you can even say that there are three

categories because you also have “entity listing information” in that one fact set.

So let’s walk through all the parts of a fact set by looking at a significantly smaller fact set, components of inventory. Each and

every fact set that makes up a report has these moving parts.

3.2. Rendering

For every fact set in a report you will have a rendering. A rendering is a means of a human to view a fact set. Here is the rendering of

the components of inventory for Microsoft:





Here is a rendering of the exact same fact set within a different software application:

Different software provides different types of renderings; some

might be static like the SEC Interactive Data Viewer, others are dynamic and be reconfigured much like a pivot table such as XBRL

Cloud’s viewer.

3.3. Fact table (Fact set)

Every fact set has a way to view the facts or fact table. Here is the

fact table (fact set) of the components of inventory that matches

the rendering shown above:





3.4. Information model definition

Every fact set has a way to view the information model definition or

“model structure” of the fact set. Here is the information model definition for the components of inventory disclosure:

3.5. Rules

Many fact sets have rules associated with the fact set. We will get

into these rules later, for now just realize that the rules exist and

that you can view the rule definitions. Here are the rules for the components of inventory of Microsoft:

So all that is straight forward. You have a fragment, components of inventory, which has exactly one fact set. Leveraging the fact set,

the information model definition, the concept arrangement pattern, and the XBRL calculation relations, a very nice and readable

rendering for the fact set can be created.

3.6. Verification of rules

If you have rules, you will need to verify that the report is

consistent with the specified rules. Applications will provide such

approaches to make sure the reported facts are consistent with rules provided. Here is a verification summary for one of the

periods of the components of inventory for Microsoft:

3.7. Intersections, integrity, contradictions, and consistency

At times one fact set can be related to another fact set in some way. For example, the fragment balance sheet has a fact set assets

roll up which might contain the fact “Property, plant and equipment,

net” as a line item within the balance sheet fragment. Another fragment components of property, plant, and equipment has a fact





set components of property, plant, and equipment roll up, which

likewise has the fact “Property, plant and equipment, net” as a total of that components of property, plant, and equipment roll up.

The fact “Property, plant and equipment, net” therefore exists within two different fact sets; it is the intersection between the

fact sets.

Another example is the fragment property, plant and equipment

Level 3 Disclosure Text Block and the fragment property, plant and equipment Level 4 Disclosure Detail. Both the Level 3 and Level 4

fact sets are required per SEC reporting rules.

One final example relates to contradictions between reported

facts. Say that the concept related to “Noncurrent assets” was used unintentionally to report the fact “Long-lived assets”. While the

Long-lived assets fact is not physically related to say the balance sheet, when the high-level concepts of the balance sheet are cross-

checked for consistency; the fact that an incorrect concept was used

to report some other fact would result in a contradiction within the report.

The bottom line here is that while relations within each fact set must be sound and intact; it is likewise true that all the relations

between fact sets must also be logical, consistent, and not contradict other reported information.

3.8. Note about the term disclosure

A disclosure29 as the term is used here is simply some set of information that is disclosed within a financial report. As the term is

being used here, there is no distinction between, say, a balance sheet and a components of property, plant, and equipment roll up.

They are both disclosures. A disclosure, as we are using the term,

is simply some set of information that is disclosed.

A fact set is the logical structure used to represent a disclosure. For

example, a balance sheet is two fact sets: an assets roll up and a liabilities and equity roll up. The balance sheet is a fragment of the

overall report. The report is a collection of fragments which are made up of fact sets which have facts which are disclosed.

4. Fact Set Patterns Patterns are simply similarities of the characteristics of something.

Financial reports have patterns and these patterns offer leverage.

29 Disclosure Best Practices, http://xbrlsite-

app.azurewebsites.net/DisclosureBestPractices/DisclosureBestPractices.aspx?DisclosureName=BalanceSheet


http://xbrlsite-app.azurewebsites.net/DisclosureBestPractices/DisclosureBestPractices.aspx?DisclosureName=BalanceSheet






4.1. Financial reports are collections of fact sets

A financial report is a collection of fact sets. One or more fact sets

work together to make up a disclosure. Fact sets are combined to represent the many fragments that make up a financial report.

4.2. Fact sets

Fact sets are logical structures that follow the multidimensional model30. Fact sets are implemented in software applications. Each

fact set has:

A rendering which provides a human-readable view of the fact set created by using/leveraging the facts that make up

the fact set, the information model that describes the fact set, the rules that describe the fact set, common business

practices such as single and double underscores for roll up relations, etc.

A fact table that provides a summary of the facts in the fact set

An information model description that explains the relations between the pieces that make up the fact set

Rules that both describe in machine readable terms how the information model fits together and can be used by software

applications to verify that the pieces actually fit together as specified.

Verification information that helps you see that the facts in

a fact set are consistent with rules.

The technical implementation of these logical structures is at the

description of software engineers. The serialization of the XBRL output is a technology task, not an accounting task.

4.3. Report element categories

When working with the pieces of the information model description of a financial report, you work with what we call report elements. A

report element is simply a piece of the information model description of an XBRL-based report. Many people erroneously

refer to all these things as “tags” which is not helpful.

The report elements that make up fact set information models

follow patterns. The following are the relationships of actual 10-Ks

submitted to the SEC by about 6,674 public companies:

30 Introduction to the Multidimensional Model for Professional Accountants,

http://xbrl.squarespace.com/journal/2016/3/18/introduction-to-the-multidimensional-model-for-professional.html







This information tells you about the categories of report elements

that exist within XBRL-based reports and the relations between those report element categories.

Report elements can be put into the following categories:

Network: A Network is a technical artifact that really has no

meaning by itself because those creating XBRL-based digital financial reports use networks in different ways. Sometimes

networks are called groups.

Table: A Table is the same thing that XBRL calls a hypercube.

A Table or hypercube simply groups some set of Axes, Members, Line Items, Abstracts, and Concepts together.

Again, because Table’s are used inconsistently, they really have no meaning by themselves.

Axis: An Axis is one approach to representing a Characteristic. Entity and period core aspects31 are also in

essence axes. An Axis is the same thing that XBRL calls a

dimension or the SBRM model calls an Aspect.

Member: A Member is a value of a Characteristic.

Line Items: A Line Items is a type of dimension or Axis. Line Items is the same thing XBRL calls primary items.

Abstract: An Abstract is simply used to organize, they provide no real meaning.

Concept: A Concept is a type of Member. A Concept is special in that it can be used to represent a Fact Value.

Therefore, Concepts have data types.

An information model definition is simply an organization of these

seven different building blocks.

31 XBRL International, Open Information Model 1.0, http://www.xbrl.org/Specification/oim/CR-2017-

05-02/oim-CR-2017-05-02.html


http://www.xbrl.org/Specification/oim/CR-2017-05-02/oim-CR-2017-05-02.html

http://www.xbrl.org/Specification/oim/CR-2017-05-02/oim-CR-2017-05-02.html




4.4. Relations between report element categories

The following table describes the allowed and disallowed

relationships between the different categories of report elements:

Note that these report element relations are only applicable to the XBRL presentation relations within an XBRL-based report. All XBRL

calculation relations and XBRL definition relations are enforced by XBRL technical syntax rules so you don’t need to worry about those

details.

4.5. Concept arrangement patterns

Every XBRL-based public company financial report is essentially a

set of fact sets. We queried 6,674 reports and determined that

there are about 754,430 fact sets in the set of public company

reports that we analyzed.

16% are roll ups,

5% are roll forwards,

24% are sets (hierarchies), and

54% are text blocks

As such, within a set of [Line Items], concepts are related to other

concepts in specific ways. Concepts can be related to one another numerically. Concepts can be related logically. Concepts can be

related mechanically. We refer to these relationships as concept arrangement patterns. The following is a summary of concept

arrangement patterns32 that exist:

Roll up: Fact A + Fact B + Fact C = Fact D (a total)

Roll forward: Beginning balance + changes = Ending

balance

Adjustment: Originally stated balance + adjustments =

restated balance

32 Charles Hoffman, CPA and Rene van Egmond, Understanding Concept Arrangement Patterns,

Member Arrangement Patterns, and Fragment Arrangement Patterns, http://xbrlsite.azurewebsites.net/2017/IntelligentDigitalFinancialReporting/Part02_Chapter05.7_UnderstandingConceptArrangementPatternsMemberArrangementPatterns.pdf


http://xbrlsite.azurewebsites.net/2017/IntelligentDigitalFinancialReporting/Part02_Chapter05.7_UnderstandingConceptArrangementPatternsMemberArrangementPatterns.pdf

http://xbrlsite.azurewebsites.net/2017/IntelligentDigitalFinancialReporting/Part02_Chapter05.7_UnderstandingConceptArrangementPatternsMemberArrangementPatterns.pdf




Variance: Actual amount – Budgeted amount = variance

Complex computation: Net income / Weighted average shares = earnings per share

Set or Hierarchy: Facts are related in some way, but not numerically. (Note that the term hierarchy is an older term

that is going to be phased out; the term set is preferred.)

Text Block: A Text Block is prose that is worked with as one

unit. Essentially a text block is a term used to refer to information that is represented as escaped XHTML.

Subsequent sections provide a more detailed explanation of concept arrangement patterns and examples of such patterns.

4.6. Reporting styles and fundamental accounting concept relations

Financial reports are not random facts; rather an examination of

6,672 reports shows patterns in the reporting styles of public companies. A reporting style is basically an organization of high-

level financial accounting concepts within the report33. For example, some companies report a classified balance sheet and

others such as banks report using an unclassified or order of liquidity balance sheet. Some companies report gross profit, others

do not. Some report operating income (loss) others do not. Each of these high-level accounting relationships can be documented and

organized into a set of patterns that we call reporting styles. US

GAAP34 has reporting styles as does IFRS35.

The fact of the matter is that 90% of or approximately 5,326 of

companies fit into only about 26 different reporting style permutations and combinations36.

33 Charles Hoffman, CPA and Rene van Egmond, Understanding Fundamental Accounting Concepts

and Reporting Styles, http://xbrlsite.azurewebsites.net/2017/IntelligentDigitalFinancialReporting/Part02_Chapter05.6_UnderstandingFundamentalAccountingConceptRelationsAndReportingStyles.pdf 34 US GAAP Reporting Styles, http://www.xbrlsite.com/2018/10K/US-GAAP-Reporting-Styles.pdf 35 IFRS Reporting Styles, http://www.xbrlsite.com/2018/IFRS/IFRS-Reporting-Styles.pdf 36 Charles Hoffman, CPA, Making the Case for Reporting Styles,

http://xbrlsite.azurewebsites.net/2017/library/MakingTheCaseForReportingStyles.pdf




http://www.xbrlsite.com/2018/10K/US-GAAP-Reporting-Styles.pdf

http://www.xbrlsite.com/2018/IFRS/IFRS-Reporting-Styles.pdf

http://xbrlsite.azurewebsites.net/2017/library/MakingTheCaseForReportingStyles.pdf




Here is an example of an income statement reporting style that is

used by about one third of all public companies:





Income statements have the highest level of variability. The least

variability in reporting exists in the cash flow statement. The balance sheet and statement of comprehensive income are in

between the two extremes.

4.7. Type or class relations

The concepts within an XBRL taxonomy can be grouped into classes

or types. For example, “Assets” concepts are not the same as “Revenues” concepts. You would never use an assets concept to

represent a revenues related fact. Type or class relations rules are used to prevent this sort of concept misuse. There are two general

types of relations between classes of concepts. “Type-of” relations indicate that a concept is of a similar type or a specialization of

some other general concept. For example “Sales Revenue, Net” is a

TYPE-OF “Revenues, Net”. “Whole-part” relations indicate that some WHOLE is made up of a specific set of PARTS.

Today, both the US GAAP and IFRS XBRL taxonomies do a rather poor job articulating type or class relations. The best information

that exists are XBRL calculation relations but many of those relations are not type/class relations. For example, the

computation “Gross Profit = Revenues – Cost of Revenues” does not indicate that revenues or cost of revenues are a type of gross profit.

So, you have to be careful.

4.8. Disclosure mechanics

Consider some of the disclosures that we have shown you in this document. Think about the following questions:

How often would the property, plant, and equipment components roll up be a roll up? Clearly 100% of the time. If

you wanted to represent a roll forward, that is a different disclosure with a different mathematical relationship.

How often would the total of the roll up of the components of property, plant, and equipment be the concept such as “us-

gaap:PropertyPlantAndEquipmentNet” or some similar alternative concept? Clearly 100% of the time.

How often would concepts such as Land, Buildings, Furniture and Fixtures, Computer Equipment and such be included

within the total? Well, that actually depends on what subcategories of property, plant, and equipment an economic

entity actually has. But often those concepts would be used.

How often would these subclasses of PPE be used to represent the subcategories of inventory? Never.





If the line item property plant and equipment was reported on

the balance sheet, what is the probability that the subcategories would be de disclosed?

If property, plant and equipment is disclosed, what is the probability that the estimated useful lives of the subclasses of

property, plant and equipment were also disclosed? Pretty high.

Consider the same questions above and the inventory components roll up disclosure. Consider the same question and the many other

disclosures that exist within a financial report.

Consider this disclosure of the components of property, plant and

equipment:

Consider the prototype below that will show you 339 different

property, plant, and equipment disclosures37:

37 Disclosure Best Practices, http://xbrlsite-

app.azurewebsites.net/DisclosureBestPractices/DisclosureBestPractices.aspx?DisclosureName=PropertyPlantAndEquipmentNetByTypeRollUp


http://xbrlsite-app.azurewebsites.net/DisclosureBestPractices/DisclosureBestPractices.aspx?DisclosureName=PropertyPlantAndEquipmentNetByTypeRollUp






That prototype has 40 different disclosures. Flipping through a

disclosure helps you see the disclosure patterns. These patterns are not unique to US GAAP, they also exist for IFRS and other

reporting schemes. These patterns can be represented in the form of machine-readable rules.

For example, here are machine-readable rules that relate to the inventory components disclosure required under US GAAP.

Here is that same machine readable rule shown within another software application:





Now, think about applying the same ideas that we are discussing for

the property, plant and equipment components disclosure and the inventory components disclosure to other disclosures represented

within a report:

Now think about applying them to every disclosure in a financial

report. Essentially, machine-readable rules can be created for each fact set in a report to verify each fact set which helps you verify the

entire report piece-by-piece. These techniques can be applied to

each and every fact set that exists within an XBRL-based financial report. Report creation processes and workflows can take

advantages of the ability to identify and work with specific fact sets that exist.

4.9. Reporting checklist

So we have established that a report is made up of fragments and those fragments can be broken down by fact set. Consider the

following:

Some fact sets are always required to exist within a financial

report. For example, 100% of public companies provide:

o A balance sheet of some sort

o An income statement of some sort

o A statement of comprehensive income of some sort (or a combined income statement and statement of

comprehensive income)





o A cash flow statement

o A summary of significant accounting policies is always reported.

o A basis of reporting is always disclosed.

o A nature of operations is always reported.

Some disclosures are required if a specific line item is reported;

o For example, if the line item property, plant, and equipment is reported the disclosure of estimated useful

lives is also reported.

Some disclosures are only provided if specific events,

circumstances, or other phenomenon have occurred for a reporting entity.

And so reporting checklist rules can be represented that convey the above reporting requirements and then automated processes can

watch over some of the report information

4.10. Reporting levels

XBRL-based reports that are submitted to the SEC are required to report different levels of information. Reported information can be

summarized into the following four levels:

Level 1 Note Text Blocks

Level 2 Policy Text Blocks

Level 3 Disclosure Text Blocks

Level 4 Disclosure Detail

Again, there are patterns within these fact sets that report

information at different levels. For example, you would always expect a Level 3 Disclosure Text Block and a Level 4 Disclosure

Detail for every disclosure other than the primary financial

statements. These reporting requirements can be summarized within the disclosure mechanics rules.

4.11. Consistency with prior periods and peers

Reported financial information should generally be consistent from one period to the next for a reporting economic entity. For example,

here are is summary information for Microsoft for five periods:

Entity comparison:





Also, the reported information of an economic entity should be consistent with its peers that use the same reporting style. For

example, here is a comparison of Microsoft with four of Microsoft’s peers that have the same income statement reporting style:

Peer comparison:





Not only should the XBRL metadata be consistent for an economic

entity from period to period and consistent between different economic entities that report using the same style; but the practice

of analytical review of the values between periods or across periods can also be leveraged to detect errors.

4.12. Summary

To verify that an XBRL-based report is created correctly takes a chain of capabilities38. The following is a summary of those

capabilities:

XBRL technical syntax consistency: XBRL instance

created MUST be checked for and proved to be consistent with the XBRL International consistency suite for XBRL 2.1, XBRL

Dimensions 1.0, and XBRL Formula 1.0.

Model structure consistency: The XBRL presentation relations MUST be checked for and proved to be consistent

with the allowed relationships between the following report elements: Networks, Tables, Axis, Members, Line Items,

Concepts, and Abstracts. See the table below.

Reporting styles: The reporting style used MUST be

consistent with reporting rules of the reporting scheme used to create the report, generally US GAAP or IFRS for financial

reports.

Continuity cross-checks: The XBRL instance MUST be

checked for and proved consistent with business rules that enforce relations between reported line items per the

reporting style used.

38 Charles Hoffman, CPA, Chain of Capabilities Necessary to Automate Accounting Processes,

http://xbrlsite.azurewebsites.net/2018/Library/ChainOfCapabilities.pdf


http://xbrlsite.azurewebsites.net/2018/Library/ChainOfCapabilities.pdf




Types: The XBRL instance MUST be checked for and proved

consistent with specified detailed line item relations of the reporting scheme and reporting style used.

Reporting checklist: The XBRL instance MUST be checked for and proven consistent with disclosure rules of the

reporting scheme used.

Disclosure mechanics: The XBRL instance and the XBRL

taxonomy MUST be checked for an proven consistent in terms of mathematical relations (roll ups, roll forwards, member

aggregations which is a form of roll up represented via XBRL Dimensions); in terms of structural relations (i.e. the integrity

of report fragments MUST be consistent within each fragment and between fragments); in terms of logical relations; in

terms of accounting relations; in terms of the disclosure rules of the reporting scheme used.

Manual review of non-automatable tasks: All review

tasks that cannot be automated for one reason or another such as lack of machine-readable verification rules or an

inability of software to tackle specific tasks must be verified using manual processes.

Notice that the last task is manual review. No XBRL-based report can be verified to be correct using automated processes. But that

said, automating as much as possible creates the most cost and times savings. Striking the correct balance between automated and

manual processes is crucial to success.

A dashboard that summarizes information is helpful for

understanding the big picture:

But, it is also important to be able to drill into the details and

understand what has been automated and what has not been automated. Not checking something manually can let errors and

other quality issues slip through.





Here is another form of dashboard with the ability to drill down into

detailed information about a report39. Note that XBRL Cloud has a separate report for the reporting checklist and disclosure mechanics

validation40 (i.e. the two are not integrated).

4.13. Sample analysis report

We created a sample analysis report41. We randomly picked the Microsoft 2017 10-K report to analyze. That analysis embodies the

ideas of this document and the framework and principles articulated. Currently, higher level analysis is covered whereas the

more detailed analysis of each report element, fact, and rule is not currently covered. A more detailed analysis template is

forthcoming. This analysis format could be used by any US GAAP or IFRS report submitted to the SEC. Clearly additional work is

necessary, but any analysis cannot be considered sufficient unless it

covers the points we are making in our analysis document.

4.14. Lean six sigma

Engineer and statistician W. Edwards Deming defined quality as

“predictability,” and called variance “the enemy of quality.” To achieve an intended outcome, Deming thought it was important to

plan for common-cause variation, which can be predicted, and special-cause variation, which cannot be predicted.

Harold F. Dodge, one of the principal architects of the science of statistical quality control, said, “You cannot inspect quality into a

product.” In other words, once the inspection takes place, it’s too late. Rather, data from the quality inspection needs to be utilized to

continually improve the creation process.

39 XBRL Cloud Evidence Package,

http://xbrlsite.azurewebsites.net/2017/Prototypes/Microsoft2017/evidence-package/#VerificationDashboard.html 40 XBRL Cloud Reporting Checklist and Disclosure Mechanics Report,

http://xbrlsite.azurewebsites.net/2017/Prototypes/Microsoft2017/Disclosure%20Mechanics%20and%20Reporting%20Checklist.html 41 XBRL-based Digital Financial Report Analysis Report,

http://xbrlsite.azurewebsites.net/2019/Prototype/EvaluatingReport/XBRLBasedReportAnalysisSummary_Microsoft.pdf


http://xbrlsite.azurewebsites.net/2017/Prototypes/Microsoft2017/evidence-package/#VerificationDashboard.html

http://xbrlsite.azurewebsites.net/2017/Prototypes/Microsoft2017/evidence-package/#VerificationDashboard.html

http://xbrlsite.azurewebsites.net/2017/Prototypes/Microsoft2017/Disclosure%20Mechanics%20and%20Reporting%20Checklist.html

http://xbrlsite.azurewebsites.net/2017/Prototypes/Microsoft2017/Disclosure%20Mechanics%20and%20Reporting%20Checklist.html






Management consultant Joseph Juran, who focused on management

training and the human element of quality control for a variety of businesses, stated that quality is “a fitness for use.”

Businessman Philip B. Crosby, who developed the concept of Zero Defects while working as senior quality engineer at aircraft

manufacturer The Martin Company, defined quality as “a conformance to requirements.” He warned against the high cost of

nonconformance and said that the desired performance standard of zero defects could only be achieved through the proper

management system.

Lean Six Sigma42 is a philosophy for managing quality. Lean Six

Sigma is a discipline that combines the problem solving methodologies and quality enhancement techniques of Six Sigma

with the process improvement tools and efficiency concepts of Lean Manufacturing. Born in the manufacturing sector, Lean Six Sigma

works to produce products and services in a way that meets

consumer demand without creating wasted time, money and resources. These same Lean Six Sigma philosophies can be applied

to the process of creating a financial report.

Built-in-quality (BIQ) is one lean six sigma technique. BIQ allows

an organization to move from the detection and containment of defects to preventing defects from ever being produced in the first

place.

5. Automated versus Manual Evaluation It is impossible for the evaluation of a financial report to be completely automated. Manual review steps will always be

necessary. That said; many aspects of the evaluation of a financial

report can be effectively automated. This is not an either/or question but rather an issue which should be consciously

understood so that the right approaches can be leveraged in order to maximize quality, minimize cost, and minimize the effort

necessary.

The review of an XBRL-based report will be a collaboration between

a machine and a human very similar to how a calculator helps a professional do math efficiently.

42 Charles Hoffman, CPA, Comprehensive Introduction to Lean Six Sigma for Accountants,

http://xbrlsite.azurewebsites.net/2017/IntelligentDigitalFinancialReporting/Part01_Chapter02.72_LeanSixSigma.pdf







5.1. Automated

As we stated earlier, XBRL conformance suite43 tests, do not, and

cannot, check to see if the meaning conveyed by the XBRL-formatted information is correct. The XBRL conformance suite only

tests the XBRL technical syntax for correctness. That said, XBRL conformance suite tests do test 100% of the technical syntax of an

XBRL instance and XBRL taxonomy to be sure that syntax is proper. Further, if Inline XBRL is used, the XHTML format can likewise be

tested 100% using the Inline XBRL conformance suite44.

Accounting professionals never need to be bothered by the XBRL or

Inline XBRL technical syntax. That syntax should always be right, be controlled and verified by software applications, and leave

accountants to deal with accounting issues.

There are other aspects of an XBRL-based report that can be successfully automated:

Model structure relations allowed within the XBRL presentation relations

Mathematical computations

Fundamental accounting concept relations continuity cross

checks

Type/class relations

Disclosure mechanics

Reporting checklist

However, in order to automate these and other processes; (a) machine-readable rules must be created and (b) software must be

created that can process those machine-readable business rules. No machine-readable rules, no automation. It really is that straight

forward.

But when these processes are automated, professional accountants have a lot less to learn about correctly representing information

within an XBRL-based financial report.

5.2. Manual

While it is the case that automated processes can effectively tell you

if a report is wrong; it is not the case that such automated processes can tell you that every aspect of a report is right.

43 XBRL International, XBRL 2.1, https://specifications.xbrl.org/work-product-index-group-base-spec-

base-spec.html 44 XBRL International, Inline XBRL 1.1, https://specifications.xbrl.org/work-product-index-inline-xbrl-

inline-xbrl-1.1.html




https://specifications.xbrl.org/work-product-index-inline-xbrl-inline-xbrl-1.1.html

https://specifications.xbrl.org/work-product-index-inline-xbrl-inline-xbrl-1.1.html




For example, if the concept “us-gaap:Cash” was used to represent a

fact that related to restricted cash (and a better concept existed that could have been used), there is no possible way to be 100%

reliably detect that representation error. However, automated processes can be extremely helpful in detecting errors.

As such, there will always be manual work that needs to be done. But, if processes are good that manual work can be minimized. For

example, when you create an XBRL-based report for the first time it is necessary to check each and every fact and all metadata to be

100% certain that everything is correct. But the next report that is created it is not necessary to re-review ever detail. If managed

correctly, only the changes between the initial report and the new report need to be reviewed.

A “diffing” tool can be used to highlight everything that changed from one report to the next. Not the XBRL technical syntax changes

but rather the changes in meaning or change in logic of a report.

6. Using Outsourced Services Outsourcing the process of creating an XBRL-based report can be

useful but it is not a panacea or a way to avoid responsibility for the true and fair representation of your XBRL formatted report.

If you are going to outsource the creation of your XBRL-based financial report (a) be an informed buyer and (b) recognize that

while you can delegate the task of creating the XBRL-based report to someone else, the quality of the report is ultimately still your

responsibility.

6.1. Filing agents

The burden of ensuring that the XBRL properly reflects the underlying HTML falls squarely on the shoulders of economic entity

creating a report and must submit that report to a regulator such as the SEC.

Far too often very unaware, naïve, less diligent external financial reporting managers assume that their EDGAR/XBRL service

providers are doing a good job of making sure that the concepts they select or choose to extend are accurately/optimally

representing the underlying XBRL-based report and that the XBRL-based report and the HTML-based report match.

The typical external financial reporting manager and their reporting teams, most of whom are highly skilled financial reporting experts

with Big 4 audit backgrounds and who can tell you precisely what

the ASC/Reg S-K/Reg S-X paragraph is that applies to a particular financial statement line item or footnote disclosure, have no idea





how to drill down into the SEC XBRL Interactive Data Viewer45 of

their own filed financial statements to evaluate the concepts selected and many are surprised to learn that such metadata even

exists. Further, the SEC XBRL Interactive Data Viewer is not particularly well suited for evaluating XBRL-based reports.

Typical external financial reporting managers are even less familiar with free tools to review the US GAAP XBRL Taxonomy46.

6.2. Independent auditors

Independent auditors don’t have some sort of innate understanding of XBRL-based reports although many would like to lead you to

believe that they do. Auditors have to go through the process of learning about XBRL just like you do.

In fact, most auditors tend to be behind the curve in terms of

understanding how to properly create an XBRL-based financial report. Currently, some of the best knowledge of XBRL and the

creation of XBRL-based reports exist at filing agents47. Ask filing agents to explain how they manage their processes and make sure

the reports they create are of high-quality.

You should ask your independent auditors the same questions.

Currently, there really is no formal guidance provided to auditors that they use for evaluating the quality of an XBRL-based financial

report. We mentioned that the AICPA provides guidance48, read that guidance, compare that guidance with the information we are

providing, and you can decide for yourself which is the most helpful and which works best for creating high-quality XBRL-based financial

reports.

6.3. Important tasks when using outsourced service providers

The following is information that helps external financial reporting managers and their teams to (a) critically evaluate an XBRL-based

financial report, (b) have useful, meaningful discussions with filing agents performing work for an economic entity, and (c) make sure

45 Microsoft 2017 10-K in the SEC Interactive Data viewer, https://www.sec.gov/cgi-

bin/viewer?action=view&cik=789019&accession_number=0001564590-17-014900&xbrl_type=v 46 FASB, US GAAP XBRL Taxonomy, http://xbrlview.fasb.org/yeti/resources/yeti-

gwt/Yeti.jsp#tax~(id~174*v~5957)!net~(a~3474*l~832)!lang~(code~en-us)!rg~(rg~32*p~12) 47 Quarterly XBRL-based Public Company Financial Report Quality Measurement (March 2019),

http://xbrl.squarespace.com/journal/2019/3/29/quarterly-xbrl-based-public-company-financial-report-quality.html 48 American Institute of Certified Public Accountants, 2017, Principles and Criteria for XBRL-

Formatted Information, https://www.aicpa.org/InterestAreas/FRC/AccountingFinancialReporting/XBRL/DownloadableDocuments/aicpa-principles-and-criteria-for-xbrl-formatted-information.pdf




http://xbrlview.fasb.org/yeti/resources/yeti-gwt/Yeti.jsp#tax~(id~174*v~5957)!net~(a~3474*l~832)!lang~(code~en-us)!rg~(rg~32*p~12)


http://xbrl.squarespace.com/journal/2019/3/29/quarterly-xbrl-based-public-company-financial-report-quality.html







that the meaning conveyed by such XBRL-based reports matches

the meaning conveyed via the human-readable HTML-based reports:

Leverage references: Filers need to understand that each XBRL concept contains useful metadata such as a definition

and ASC/Reg S-X references that they can use to determine whether the selected concept is appropriate and/or optimal for

the disclosure under consideration.

Preferred labels: Most filers are not aware that the so-called

“preferred label” of each of their XBRL concepts was manually changed by their XBRL service provider to match the line item

description in the HTML presentation, and that this preferred label has nothing to do with the underlying concept’s

appropriateness/correctness for the given disclosure. Many filers see the preferred label and just assume that because it

matches the HTML description that the XBRL must be correct

and they never bother to drill down to check the concept definition/ASC reference, or check if it is an extension as

contrast to a US GAAP XBRL Taxonomy concept.

Test 100% of concepts: Filers need to understand that

they need to drill down into the actual XBRL concepts used and be sure that each and every concept reflects their

intended meaning using concept documentation and references, not labels or concept names.

Extension concepts: Filers need to understand extensibility and don’t realize that their service providers may be prone to

extending if they can’t easily locate a US GAAP XBRL Taxonomy concept. Many service providers have gotten less

diligent over the years because they know that external financial reporting teams are not really checking the reports

at this level of detail and so they sometimes tend to extend

unnecessarily and irresponsibly.

Navigating/searching the US GAAP XBRL Taxonomy:

many filers have never navigated or searched the US GAAP XBRL Taxonomy for concepts and have no idea that there are

FREE tools that they can use to navigate and search to help keep their service providers honest49.

Excel based XBRL concept/fact reports from their service providers: Many filers are unaware that they can

easily download a list of every XBRL fact/concept in their 10-

49 FASB, US GAAP XBRL Taxonomy, http://xbrlview.fasb.org/yeti/resources/yeti-

gwt/Yeti.jsp#tax~(id~174*v~5957)!net~(a~3474*l~832)!lang~(code~en-us)!rg~(rg~32*p~12)







K/10-Q into an excel spreadsheet50 and that these

spreadsheets contain additional information to aid in their analysis of the concepts (e.g., the reports list the concepts in

the Excel rows and the columns contain additional information about the XBRL metadata including where in the 10-K the

XBRL is located. This simple exercise helps lift the veil of complexity/secrecy that still unnecessarily surrounds XBRL

and many clients are appalled by the quite obvious and inexcusable errors that so-called XBRL experts of filing agents

or other service provides have made in concept selection. XBRL may be an open source standard, but there is a lot of

money to be made from the proprietary code service providers use in creating these reports and that is part of the

problem - they want to keep the process a black box for as long as possible to keep the cash rolling in from the XBRL

services they provide. And although it is not their fault that

many filers are less arduous and just want to outsource the process, it is still their responsibility when their so-called XBRL

experts are consistently making mistakes.

Sense of ownership: Many filers are more than happy to

outsource their XBRL to service providers and are just as happy to also pass along all responsibility for the quality of

their XBRL to their service providers and use their own wilful and complacency as an excuse for not taking ownership. Filers

and/or their auditors should be required by their internal auditors, the FASB, PCAOB, SEC, or someone to internally

perform a comprehensive review of 100% of their XBRL concepts in their Form 10-K in conjunction with their annual

financial statement and ICFR audit and attest that the XBRL matches the HTML.

Think about it this way. Ultimately, XBRL-based reports are going

to be required to be audited by an independent auditor. There is a very high probability that this will come to pass; the question is not

IF but rather WHEN. You can turn the task of learning about XBRL-based financial reports into a crisis by waiting as long as you can

and then when an audit is required, you can scramble to make sure you have the appropriate skills.

6.4. Manage your learning process

XBRL-based reports are sophisticated and have many moving parts and gaining a proper understanding of these reports takes time and

practice. Outsourcing the creation of your XBRL-based report to a

50 Excel spreadsheet for Microsoft provided by XBRL Cloud,

http://xbrlsite.azurewebsites.net/2019/Prototype/EvaluatingReport/EvidencePackage_msft-20170630.zip







third party service provider can be an excellent approach to learning

about XBRL-based reports. XBRL is not going away; it is the future of financial reporting. Working with a good third party service

provider is an excellent way to incrementally bring knowledge into your organization if projects are managed properly. If you don’t

participate effectively, you will likely learn little or nothing from your third party service provider. But if done well, you can incrementally

institutionalize the necessary knowledge about XBRL-based financial reporting.

6.5. “Audit” of XBRL

Over the years there have been calls for XBRL to be “audited”51. Ultimately, the information provided within an XBRL-based report

will be required to be audited. You don’t need to “audit” XBRL;

XBRL is just a technical syntax and as we said earlier, 100% of the XBRL technical syntax can be checked using the XBRL conformance

suite. Auditing the XBRL format is unnecessary. Yes, it is helpful to make sure that the proper button was pushed and that the

automated testing of the XBRL technical syntax was run.

What does need to be audited is the information that is represented

within the XBRL technical syntax52. When an audit is done for a paper-based or e-paper based financial report, the “paper” or “e-

paper” format is not checked, it is the information that is conveyed by the paper or e-paper that is checked. Likewise, with XBRL

formatted information it is not the delivery mechanism that is checked, it is the information conveyed that is checked. Paper, PDF,

HTML, Word, and XBRL are simply mediums for conveying information.

The only difference between an independent third-party audit and

your internal evaluation of the XBRL-based information is the independence of those performing the work if both parties have the

same skill set. So, whether the external financial reporting team evaluates the report, or an internal audit team or a third-party

auditor; the tasks tend to be the same. The documentation of the task is likely different, but the work tasks are, or should be, pretty

much the same. If an auditor bills by the hour, they are not particularly motivated to be efficient.

51 Mohini Singh, ACA, h 2019, The Time to Develop Standards to Audit Digital (XBRL) Filings Has

Come, https://blogs.cfainstitute.org/marketintegrity/2019/03/26/the-time-to-develop-standards-to-audit-digital-xbrl-filings-has-come/ 52 Thoughts on Auditing XBRL-formatted Information,



https://blogs.cfainstitute.org/marketintegrity/2019/03/26/the-time-to-develop-standards-to-audit-digital-xbrl-filings-has-come/

https://blogs.cfainstitute.org/marketintegrity/2019/03/26/the-time-to-develop-standards-to-audit-digital-xbrl-filings-has-come/





7. Important Things you May Not Realize about Representing Information using XBRL

Again, this document tries to stay away from technical discussions.

For those who are curious, you can better understand the intimate details of what we are discussing better if you read something like

the basic XBRL Technical Primer53. This is not required, but some might find the additional details helpful.

7.1. Networks

In XBRL, an information model description is created by creating

Networks, putting Tables (hypercubes) in those Networks, and then putting other report elements within those Tables. Alternatively,

you might not explicitly define a Table within a Network. And so if you do not explicitly provide a Table and put any report elements

within a Network; essentially what you are doing is creating a single implied table that contains each report element that is not

represented within an explicitly defined Table within a Network.

And so, Networks and Tables (explicitly defined or implied) are used

to represent the information model description of a report.

Sometimes you MUST separate things using Networks to avoid

conflicts; other times you get too choose whether to separate things

using Networks. Tables work the same way; sometimes you MUST use a Table to separate fact sets and other times you get to choose

whether you want to (a) use an existing Table or (b) create a new Table to represent some piece of a report.

7.2. States of information representation

A representation of information can have exactly four possible states or features:

1. An information representation is logically represented and easy to comprehend.

2. An information representation is logically represented and hard to comprehend.

3. An information representation is illogically represented and

easy to comprehend (but illogical).

4. An information representation is illogically represented and

hard to comprehend (but illogical).

53 Charles Hoffman, CPA and Rene van Egmond, XBRL Technical Primer,

http://xbrlsite.azurewebsites.net/2017/IntelligentDigitalFinancialReporting/Part00_Chapter01.2_XBRLPrimer.pdf







States #3 and #4 are incorrect by definition. Information that is

defined illogically is simply wrong.

State #2 is not incorrect, but neither is it a best practice. State #1

is the only best practice, information that is logically represented and as easy to read as possible. As stated, a best practice is a

method or technique that has been generally accepted as superior to any other known alternatives because it produces results that are

superior to those results achieved by other means or because it has become a standard way of doing something.

7.3. Fact set example

And so, let’s have a look at the report rendering related to property, plant, and equipment components roll up and the inventory

components roll up are combined into one report fragment:

Now, look at this almost identical representation of the same

information and note the slight difference. In the report above, a root presentation relation which is an [Abstract] concept that holds

all of the other concepts from the property, plant, and equipment [Roll up] and distinguishes those concepts from the inventory [Roll

Up].





So, is the first rendering at the top of the page without those two [Abstract] concepts wrong and the second rendering at the bottom

right? No, that is not what I am saying. Both the top and the bottom representations are logically correct. But at the same time I

point out that if the second representation is easier to read than the first, then the second is a better practice that the first.

You might think that this discussion is silly and that as long as the

representation is logical, you can represent XBRL-based information however you want. And yes, it is true that you can do that,

represent information however you want as long as the information is not illogical.

However, if you are a software engineer that is constructing software that helps business professionals do things right or to

automatically follow best practices or to not let software users to things wrong; this is incredibly helpful information.

7.4. Sub-standard fact set examples

Further, have a look at this fragment from an XBRL-based financial

report of a public company submitted to the SEC:





That representation you see above is from an actual XBRL-based

report created by a public company to the U.S. Securities and Exchange Commission. While logically, the information is 100%

correct, the rendering of the information is hideous and downright ugly.

I have provided you with one simple, basic use of fact sets. This basic explanation is useful in that it helps you get a true sense of

what a fact set really is. But it is only a basic example; there are many other uses for the notion of fact sets.

So, one use of fact sets is to avoid hideous, ugly, and unreadable information representations such as these two examples:





There are two strong arguments for not creating ugly, hideous

renderings. First, for every one bad example of a rendering, there are 50 or 100 good examples. The good examples are best

practices, the bad examples are not. Second, if you can help

software engineers understand the problems you are having representing information using XBRL and making it right; the

software engineers can help you be more successful.

7.5. Extensions

Many people tend to hold the position that extensions created by a

reporting entity and used within their report are “bad” and lead to reports not being useable.





To make a broad sweeping general statement that extensions are

bad is completely absurd and demonstrates a lack of knowledge about XBRL-based reports.

Extensions are not inherently good or bad. Extensions when used correctly can be very useful. Extensions used incorrectly can be

extremely problematic. Here are two examples to make the point.

First, if an economic entity reported revenues as required by some

reporting scheme such as US GAAP; and then provided additional details that they felt is important about the details of revenues

using extensions that they have created they are providing information that describes their unique financial report and that

information could very well be useful to the user of a financial statement. Further, if the extension concepts were used

consistently from one period to the next, comparisons could effectively be created by those analyzing that financial report that

contained extensions. So, in this case extensions would be a

benefit to both the creator and the consumer of reported information.

Second, if an economic entity created an extension concept “my:Revenues” rather than using the existing concept such as “us-

gaap:Revenues” that extension would be problematic. It should never be the case that high-level financial report line items should

be extended. If an extension deemed to be necessary then either (a) the entity deeming that an extension is likely not justified in

creating such a high level extension or (b) the base taxonomy for the reporting scheme is missing an important high-level financial

accounting concept.

You should be able to justify every extension concept created and

providing that justification in the documentation of the extension concept is a best practice.

7.6. Deriving financial report line items

The vast majority of financial reports created by public companies

and then submitted to the SEC provide all the high-level line items to make reading the financial report easy for either a human or by

machines such as computers.

However, for a minority of such reports or for some financial report

line items; it is necessary to derive high-level line items. For example, not many financial reports explicitly report the line item

“Noncurrent assets”. But, virtually all reports provide the line item “Total assets”; a vast majority explicitly report the line item

“Current assets”; and it is common knowledge that “Total assets = Current assets + Noncurrent assets”. And therefore, deriving the





value for the line item is easy given the explicitly reported

information “Total assets” and “Current assets” and the rule.

If more and more subtotals are not explicitly reported it becomes

more and more of a guessing game to try and figure out (a) the information you want to use and (b) testing the information to

make sure you got the right information.

Remember that computers are dumb beasts. If, say, an economic

entity were to explicitly report the line item “Noncurrent assets” then two things happen. First, software does not have to poke

around and try to figure out what the value of Noncurrent assets is. It is there, explicitly reported, you know the value because the

report told you the value. Further, because all three values were reported; “Total assets”, “Current assets”, and “Noncurrent assets”;

users of the information can cross check the information, similar to how double entry accounting enables a cross check, to make using

information safer.

I point out this principle, “Prudence dictates that using information from a general purpose financial report should not be a guessing

game.” Ultimately, software has to be written to extract and use information. The less complicated those software algorithms, the

more sound extraction algorithms will be. The more complicated, the more potential for error and the more brittle software

algorithms will become.

Accountants can be pedantic and do things that make using XBRL-

based financial reports easier. Or, accountants can embrace the idea of automated information exchange, build a safe and reliable

information exchange media such as an XBRL-based general purpose financial report, and provide society a useful new

mechanism. Making things hard or making things easier is a choice. Make it a conscious choice.

Finally, holding onto too many past practices that cause the need

for “hacks” to be carried forward into the new digital future will cause problems.

7.7. References

Quality XBRL taxonomies such as the US GAAP XBRL Taxonomy and the IFRS XBRL Taxonomy contain references to authoritative

literature. Those references point to authoritative literature such as the Accounting Standards Codification (ASC) and SEC Reg S-X for

US GAAP or IFRS standards for IFRS. Other reporting schemes have similar authoritative references.

Every financial report that is created which is then audited by an independent auditor is evaluated using the disclosure checklist of

the professional accounting firm that performed that audit. Every





disclosure checklist has those same references to authoritative

literature.

The references in the XBRL taxonomy and the disclosure checklist

are to the same authoritative literature. While it is true that these references need to be put into machine-readable form to be

useable; the references are very usable and useful. While disclosure checklist today are used as little more than “memory

joggers” and those references are not in machine-readable form; that will ultimately change once software vendors are clued into

how useful the references are.

Ultimately, XBRL validation software could potentially be used to

streamline the audit process and the manual and burdensome disclosure checklist process. This is particularly true if Inline XBRL

documents are created where one document contains both the machine-readable information and the human-readable information.

Less leverage exists when the human-readable information is

created in Microsoft Work and then converted to HTML for submission to a regulator. As Inline XBRL is used more and more,

workflow processes can change and leverage machine-based rules, powerful rules engines, and other sophisticated software that

provides leverage that help make creating financial reports and even auditing those reports better, faster, and cheaper. References

is one type of machine-readable metadata that provides significant leverage.

7.8. Leveraging XBRL’s structured nature

The current evolution of software applications for working with XBRL-based information is uninspiring. But that will change.

Ultimately, the financial statement audit program, the financial

disclosure checklist, the actual financial report, and other processes and procedures will be significantly more integrated than they are

today. Today, the FASB/IASB is not providing important metadata relating to US GAAP/IFRS; the Big 4 auditors tools do not leverage

XBRL’s structured nature or machine-readable business rules; the regulators likewise don’t provide machine-readable metadata; and

software vendors don’t have particularly good insight as to how the process of creating, auditing, evaluating, and otherwise processing

a financial report and the possibilities for automation. But, this will change.

8. Increasing your Understanding The following provides information in different ways to help you understand disclosures in XBRL-based financial reports.





8.1. Fundamental accounting concept relations errors

One of the best ways to learn how to create XBRL-based digital

financial reports correctly is to examine errors in reports to understand the error and how to avoid such errors. Here is one

specific example so you can get a sense for this information:

What you see is a representation error where the total equity and

parent equity concepts were reversed. The XBRL calculation relations would be fine and the balance sheet would foot; but the

wrong information is being conveyed.

More of these types of errors are explained in the following

documents:

Fundamental Accounting Concept Relations Continuity

Cross Check Error Examples54: A collection of 26 different

errors relating to fundamental accounting concept relations continuity cross checks.

High Quality Examples of Errors in XBRL-based Financial Reports55: A set of about 24 documents with

54 Fundamental Accounting Concept Relations Continuity Cross Check Error Examples,

http://xbrlsite.azurewebsites.net/2019/Library/FundamentalAccountingConceptRelationsErrorExamples.pdf 55 High Quality Examples of Errors in XBRL-based Financial Reports,

http://xbrl.squarespace.com/journal/2017/4/29/high-quality-examples-of-errors-in-xbrl-based-financial-repo.html


http://xbrlsite.azurewebsites.net/2019/Library/FundamentalAccountingConceptRelationsErrorExamples.pdf

http://xbrlsite.azurewebsites.net/2019/Library/FundamentalAccountingConceptRelationsErrorExamples.pdf






probably 250 different errors detailed so that they are easy to

understand.

8.2. Disclosures mechanics

Comparing and contrasting the different ways companies report

their Level 3 Disclosure Text Blocks and the Level 4 Disclosure Detail provides tremendous insight into disclosures. Here is an

example of one comparison56:

You can see the Level 3 Disclosure Text Block used and the Level 4

Disclosure Detail roll up total concept used for this disclosure.

You can compare this disclosure for 199 different public

companies57:

You can do this same comparison for 65 different disclosures

here58:

56 View comparison for individual company online here,

http://www.xbrlsite.com/site1/2017/Prototypes/DisclosureAnalysis/All/0001564590-17-005736_517.html 57 View comparison between companies online here,

http://www.xbrlsite.com/site1/2017/Prototypes/DisclosureAnalysis/All/Index_517_Consistent.html 58 View comparison of about 65 different disclosures here,

http://www.xbrlsite.com/site1/2017/Prototypes/DisclosureAnalysis/All/


http://www.xbrlsite.com/site1/2017/Prototypes/DisclosureAnalysis/All/0001564590-17-005736_517.html

http://www.xbrlsite.com/site1/2017/Prototypes/DisclosureAnalysis/All/0001564590-17-005736_517.html

http://www.xbrlsite.com/site1/2017/Prototypes/DisclosureAnalysis/All/Index_517_Consistent.html

http://www.xbrlsite.com/site1/2017/Prototypes/DisclosureAnalysis/All/




Information gleaned from these comparisons is summarized in the

document Disclosure Best Practices59. Information is provided for about 65 disclosures.

Finally, you can use a tool that allows you to look at individual disclosures for both US GAAP60 and IFRS61 using the best practices

tool.

Finally, these additional documents provide information related to

understanding disclosure mechanics:

Understanding Disclosure Mechanics62: Provides an

introduction to disclosure mechanics, shows good examples and errors.

Detailed Analysis of Nine Disclosures63: Analysis of nine different disclosures that helps you understand errors.

Analysis of Disclosures64: Summary information from the analysis of 10-Ks for disclosure mechanics rules.

Other65: Boat load of other examples, in particular look at the section with the heading of “Disclosures”.

59 Disclosure Best Practices,

http://www.xbrlsite.com/site1/2017/Prototypes/DisclosureAnalysis/DisclosureBestPractices.pdf 60 Disclosure Best Practices, US GAAP, http://xbrlsite-

app.azurewebsites.net/DisclosureBestPractices/DisclosureBestPractices.aspx?DisclosureName=BalanceSheet 61 Disclosure Best Practices, IFRS, http://xbrlsite-

app.azurewebsites.net/DisclosureBestPractices_IFRS/DisclosureBestPractices.aspx?DisclosureName=BalanceSheet 62 Understanding Disclosure Mechanics,

http://xbrlsite.azurewebsites.net/2016/Analysis/UnderstandingDisclosureMechanics.pdf 63 Disclosure Error Rate Consistent with Primary Financial Statements Error Rate,

http://xbrl.squarespace.com/journal/2014/12/18/disclosure-error-rate-consistent-with-primary-financial-stat.html 64 Analysis Summary,

http://www.xbrlsite.com/site1/2017/Prototypes/DisclosureAnalysis/SummaryTable.pdf 65 Understanding SEC XBRL Financial Filings, http://xbrl.squarespace.com/understanding-sec-xbrl-

financi/


http://www.xbrlsite.com/site1/2017/Prototypes/DisclosureAnalysis/DisclosureBestPractices.pdf




http://xbrlsite-app.azurewebsites.net/DisclosureBestPractices_IFRS/DisclosureBestPractices.aspx?DisclosureName=BalanceSheet



http://xbrlsite.azurewebsites.net/2016/Analysis/UnderstandingDisclosureMechanics.pdf

http://xbrl.squarespace.com/journal/2014/12/18/disclosure-error-rate-consistent-with-primary-financial-stat.html



http://www.xbrlsite.com/site1/2017/Prototypes/DisclosureAnalysis/SummaryTable.pdf

http://xbrl.squarespace.com/understanding-sec-xbrl-financi/

http://xbrl.squarespace.com/understanding-sec-xbrl-financi/




8.3. Quality measurements of public company financial reports

Each month I measure the quality of the last 10-Q or 10-K filed

against a set of about 22 fundamental accounting concept relations rules to cross check the continuity of those reports. A summary of

the quality of the reports is provided by generator of the report (software vendor or filing agent). You can view this comparison

online66:

This analysis points out that 5,716 US GAAP financial reports were analyzed and that 5,093 reports, or 89.1% of all reports, contain no

inconsistencies with the fundamental accounting concept relations measurements. But, 623 reports did contain errors; there were a

total of 962 errors.

66 Quarterly XBRL-based Public Company Financial Report Quality Measurement (March 2019),








On a per test basis, 99.24% of all relations measured were

consistent with expectations.

Additionally, on the blog post you can download an Excel

spreadsheet that contains documentation for each of the 962 errors67.

There are Excel-based extraction tools68 that the combination of all of the spreadsheets allows you to extract information successfully

for 4,060 public companies financial reports, which is 68% of all public companies.

9. Other Resources This section contains references to information that is useful in

understanding this framework and principles in more detail.

Understanding Block Semantics69: Helps you better understand fact sets (a.k.a. blocks).

Leveraging the Theoretical and Mathematical Underpinnings of a Financial Report70: Helps you

understand the leverage that things like double entry bookkeeping and other feature of financial reports can be

leveraged.

Leveraging XBRL’s Extensibility Effectively71: Helps you

understand XBRL’s extensibility and how to use it effectively.

Blueprint for Creating Zero-Defect XBRL-based Digital

Financial Reports72: Cookbook for creating high-quality XBRL-based digital financial reports.

Intelligent XBRL-based Digital Financial Reporting73: Full library of resources.

67 ZIP file containing Excel spreadsheet that details errors,

http://xbrlsite.azurewebsites.net/2019/Library/2019-03-31_FAC-ErrorDetails.zip 68 Blog post that points you to Excel extraction tools,

http://xbrl.squarespace.com/journal/2018/1/11/further-updated-and-expanded-xbrl-based-financial-report-ext.html 69 Understanding Block Semantics,

http://xbrlsite.azurewebsites.net/2017/IntelligentDigitalFinancialReporting/UnderstandingBlockSemantics.pdf 70 Leveraging the Theoretical and Mathematical Underpinnings of a Financial Report,

http://xbrlsite.azurewebsites.net/2018/Library/TheoreticalAndMathematicalUnderpinningsOfFinancialReport.pdf 71 Leveraging XBRL’s Extensibility Effectively,

http://xbrlsite.azurewebsites.net/2018/Library/LeveragingXBRLExtensibilityEffectively.pdf 72 Blueprint for Creating Zero-Defect XBRL-based Digital Financial Reports,

http://xbrlsite.azurewebsites.net/2017/Library/BlueprintForZeroDefectDigitalFinancialReports.pdf 73 Intelligent XBRL-based Digital Financial Reporting, http://xbrl.squarespace.com/intelligent-xbrl/


http://xbrlsite.azurewebsites.net/2019/Library/2019-03-31_FAC-ErrorDetails.zip

http://xbrl.squarespace.com/journal/2018/1/11/further-updated-and-expanded-xbrl-based-financial-report-ext.html

http://xbrl.squarespace.com/journal/2018/1/11/further-updated-and-expanded-xbrl-based-financial-report-ext.html

http://xbrlsite.azurewebsites.net/2017/IntelligentDigitalFinancialReporting/UnderstandingBlockSemantics.pdf

http://xbrlsite.azurewebsites.net/2017/IntelligentDigitalFinancialReporting/UnderstandingBlockSemantics.pdf

http://xbrlsite.azurewebsites.net/2018/Library/TheoreticalAndMathematicalUnderpinningsOfFinancialReport.pdf

http://xbrlsite.azurewebsites.net/2018/Library/TheoreticalAndMathematicalUnderpinningsOfFinancialReport.pdf

http://xbrlsite.azurewebsites.net/2018/Library/LeveragingXBRLExtensibilityEffectively.pdf

http://xbrlsite.azurewebsites.net/2017/Library/BlueprintForZeroDefectDigitalFinancialReports.pdf

http://xbrl.squarespace.com/intelligent-xbrl/

Best Practices for Evaluating an XBRL-based Digital...

Documents

Transcript of Best Practices for Evaluating an XBRL-based Digital...