Manuel Schmidt

What is XBRL?

2021-07-01T05:48:17+00:00

Lately I get a lot of feedback and requests regarding my open-source library py-xbrl, which makes me very happy. But since I unfortunately can’t answer every request and many questions focus on the XBRL standard, I want to give a short technical overview of the XBRL standard with this blog post.

1 Introduction

XBRL (eXtensible Business Reporting Language) is a established XML-based specification used for the transmission of financial data between two parties. Transferring financial data between two different parties seems trivial at first glance. However, the huge number of different companies from different industries with different internal accounting systems makes the creation of a common interface a challenge. This is where XBRL comes into play. XBRL allows a wide variety of financial information to be compiled and transmitted.

A very common use case is the transmission of quarterly reports and annual reports to authorities. For example, every U.S. company (over a certain size) must file quarterly reports (10-Q) and annual reports (10-K) with the SEC using XBRL. These submissions are publicly accessible through SEC EDGAR.

2 The Taxonomy

Since there is a large number of financial information with different accounting systems (us-gaap, ifrs…), a common language framework must be established prior to the data transfer. In the XBRL context, this common language framework is called a Taxonomy. The taxonomy defines a list of concepts that can then be used in the instance document to tag certain numbers and ensures the integrity and syntactic correctness of the data.

It has proven useful to create a separate taxonomy for each accounting system - e.g. IFRS, German GAAP (HGB), US GAAP.

2.1 The Taxonomy Schema

The taxonomy schema is the heart of the taxonomy and defines the concepts of the taxonomy. The concepts will later be used by the creator of a financial report to tag certain numbers.

An example: The US-GAAP taxonomy defines the concept “Cash and Cash Equivalents”. Every company that creates a financial report based on us-gaap can use this concept (us-gaap:CashAndCashEquivalents) and associate it with a number in their financial report.

2.2 Taxonomy Linkbases

Linkbases are individual XML files that bring structure to concepts and link them to additional information. This information can be, for example, user-friendly labels or references to authoritative literature. The linkbases are imported in the taxonomy schema. Linkbases can be divided into two main groups: Relation Linkbases and Reference Linkbases. Relation Linkbases create hierarchical relationships between multiple concepts. The interpretation of these hierarchical relationships is defined by the type of linkbase. Reference linkbases, on the other hand, add resources to concepts.

2.2.1 Relation Linkbases

With the help of relation linkbases, it is possible to represent hierarchical structures between the concepts of the taxonomy. These hierarchical structures are created using XLink and extended links. The locators here reference the concepts of the taxonomy, which are declared in the taxonomy schema. These locators are then linked via arcs. So, in XLink jargon, this is linking two remote resources, where the remote resources are concepts of the taxonomy. In the image below, a locator pointing to the concept “Assets” is linked via two arcs to the hierarchically underlying concepts “Current Assets” and “Non-Current Assets”.

The hierarchies created in the linkbase have different meanings depending on the type of the linkbase.

Calculation Linkbase: The Calculation Linkbase defines simple arithmetic relationships between individual concepts. If the above example were a calculation linkbase, it would define the following equation: us-gaap_Assets = us-gaap_AssetsCurrent + us-gaap_AssetsNonCurrent.

Presentation Linkbase: The presentation linkbase describes the order in which the concepts of the taxonomy should be arranged. The above example would subordinate the us-gaap_AssetsCurrent and us-gaap_AssetsNonCurrent concepts to the us-gaap_Assets concept.

Definition Linkbase: The definition linkbase allows to create various other logical connections between concepts. For example, a link with the arcrole “essence-alias” can be used to emphasize that two concepts cover the same or very similar subject matter.

2.2.2 Reference Linkbases

In contrast to relation linkbases, which create connections between different concepts, resource linkbases connect concepts with related resources. These resources can be, for example, different types of labels for the concepts. So, in XLink jargon, here a remote element is linked to several local elements via arcs. The figure below shows a possible structure of a label linkbase. Here, the concept “Assets” is linked to the labels “Assets” and “Total Assets”. Depending on the use of the concept in the financial report, one of the two labels can be selected later.

Label Linkbase: The Label Linkbase links concepts with one or more reader-friendly labels. It is also possible to link labels in different languages.

Reference Linkbase: The reference linkbase can be used to create links between concepts and documents outside of XBRL/XML. Most often, these external documents are laws or policies that govern the calculation, disclosure, or presentation of these concepts.

3 Instance Documents

The taxonomies discussed previously create the basic structure of reporting in XBRL and usually relate the concepts using regulatory guidelines or link them to other resources such as labels. The Instance Document builds on top of it and uses the concepts created in the taxonomy to tag the numbers to be reported, giving them meaning and structure. Thus, the instance document embodies the actual business report, for example, the annual financial statement.

There are two different types of instance documents: the classic XBRL instance document (XML) and the iXBRL instance document (HTML). Both types are based on the same elements but are written in different file types.

3.1 Important Elements

The core elements of every Instance document are the Facts. A fact is a number (150000) combined with a context (from Jan-Dec 2020 for company xyz), a Unit (USD) and tagged with a Concept from the taxonomy (us-gaap_Revenue). The Context defines the time frame and the company to which the fact belongs.

To be able to tag Facts in an XBRL Instance Document, each Instance Document must reference at least one Taxonomy. After referencing a taxonomy, any concepts defined in the taxonomy can be used to tag the facts in the instance document.

3.2 inline vs default Instance Documents

The issue with classic XBRL instance documents is that the filer has to provide two seperate reports. One that is human readable and the XBRL Instance Document (which is basically an XML file). This leads to additional work and can lead to inconsistencies between the two files. A inline XBRL (iXBRL) Instance Document makes it possible to make XBRL taggings directly in an HTML file. Compared to XML files, HTML files have the decisive advantage that they can be read by an end user directly in the browser. Thus, the filer only has to create one document.

4 Putting it all together

The following figure shows all elements of an XBRL submission discussed before and their interrelationships.

What is XLink?

2021-05-25T21:40:32+00:00

This blog post mainly discusses extended links, as they are an important concept for XBRL linkbases.

Widely used for linking resources on the web is the “href” attribute. It provides a simple unidirectional link to another resource and is used, for example, in the anchor tag <a> in HTML to create a link to another web address. However, the “href” attribute quickly reaches its limits for more complex problems, which is why the World Wide Web Consortium (W3C) has developed an additional specification, the XML Linking Language (XLink).

With XLink the linking of several elements within as well as between XML documents is possible. Logical relationships between two or more XML elements can be modeled. Thus, in addition to the already known unidirectional links, more complex link structures can also be created. Unidirectional links between two resources are called simple links (xlink:type="simple"), links to any number of resources are called extended links (xlink:type="extended").

The XBRL standard mainly uses extended links, which is why we will focus on them in the following.

When you create an extended link, you can freely choose the name for your link element. In code example below it got the name <studentLink>. The only important thing here is the attribute xlink:type, which specifies the type of link.

After creating the link element, all external elements that are to be linked to the link element must first be referenced. This is done with the so-called locator. In code example below, the external resource named “student123”, which is defined in the schema file “students.xsd”, is referenced in this way. Next, the element to be associated with the first element must be defined. It can either be created locally (in the same file) or referenced remotely (in another file). The first code example defines the firstname and lastname as seperate local resources. The value “resource” of the attribute xlink:type indicates that this is a locally defined resource.

Now that it is clear which elements and information play a role in the link, it must be defined how these are to be linked. For this the so-called Arcs are used. In the code example, this would be the element <go>. It connects XLink elements with the from and to attributes. The elements are identified by the “xlink:label” attribute. It is possible that an Arc element links several elements via the label, as is the case with the two resources in the example below, which both have the label “local”.

<studentLink xlink:type="extended">

  <!-- This locator references a XML element in another document -->
  <locator xlink:type="locator" xlink:label="remote1"
           xlink:href="/students.xsd#student123"/> 
  
  <resource xlink:type="resource" xlink:label="local" 
            xlink:role="first-name">Peter</resource>
  
  <resource xlink:type="resource" xlink:label="local" 
            xlink:role="last-name">Smith</resource>
  
  <!-- This arc connects the locator with the locally defined resources -->
  <go xlink:type="arc" xlink:from="local" xlink:to="remote1"/> 
  
</studentLink>

The second code example shows a link between two remotely stored elements. But the basic structure is the same, we now have only two locators instead of one locator and multiple resources.

<studentLink xlink:type="extended">
  <!-- Both locators reference an XML element in another document -->

  <locator xlink:type="locator" xlink:label="remote1"
           xlink:href="/students.xsd#student123"/> 
  
  <locator xlink:type="locator" xlink:label="remote2" 
           xlink:href="/grades-123.xsd"/>

  <!-- This arc connects the two remotly defined XML elements -->
  <go xlink:type="arc" xlink:from="remote2" xlink:to="remote1"/>
  
</studentLink>

Summary

XLink is a Specification that allows for defining linkings between two XML-elements. These elements can either be locators that reference an element in another document, or resources that are defined locally. The linking of two or more elements is done with so-called arcs.

This blog post focuses mainly on extended links, as they are very important in XBRL linkbases. However, the XML Linking Language contains way more concepts. You can find the original specification here.

XBRL from the bottom up

2021-05-08T14:58:15+00:00

With this blog post I will try to explain XBRL as simple as possible using a problem-solving oriented approach. I will show the challenges in transferring financial data and explain how XBRL solves them. For a more detailed and traditional explanation, please check out this blog post: What is XBRL?.

Ok, so our goal is to transfer some financial data. Let’s say we want to tell the world that we generated 15.7 million USD in Revenue in 2020. We also want our revenue report to be machine readable, no old-school pdf’s! How can we encode and transfer our financial data?

The common approach would be to create another markup language, perhaps YAML 2.0 😉. On the other hand, it might also be smart to simply use an already existing and established standard. How about the most famous markup language in the world - XML?

In XML, we could encode our data as follows:

<?xml version="1.0" encoding="utf-8"?>
<report>
  <revenue unit="usd" from="01.01.2020" to="31.12.2020">15700000</revenue>
</report>

Great, our data point ($15.7M Revenue in 2020) is now machine-readable and encoded in a widely established standard. Now we can send out our report and tell the world how much profit we made, right?

Not so fast. There are a couple of issues with our report:

The recipient of the xml file does not know which company to congratulate for the $15.7M in revenues.
In an annual report, we will have hundreds of financial data points from the same period. We would have to redefine the period and the company (to which the number belongs) for every data point.
The unit of this example is quite simple. But how do we deal with financial data like “earnings per share” which would have the unit “USD per share”?

Ok, let’s make some improvements to our xml report:

<?xml version="1.0" encoding="utf-8"?>
<report>
  <unit id="usd">
    <measure>USD</measure>
  </unit>

  <context id="2020FY">
    <startDate>01.01.2020</startDate>
    <endDate>31.12.2020</endDate>
    <entity>865985</entity> <!-- This is our company identifier that the auditors gave us-->
  </context>

  <revenue unit="usd" context="2020FY">16000000</revenue>
</report>

We have now solved the problems from above relatively well, can we send the report now? Unfortunately not quite…

We are obviously not the only company in the world. If everyone did what we do, the persons receiving the reports would have a really bad time processing hundreds of slightly different reports. We need a way to define the general structure of the report so that all financial reports have the same structure. Fortunately, XML provides an excellent way to specify the structure of an XML file with XML schemas.

This is where the XML Specification comes into play. Fortunately, some clever minds have already created it, so we will just use it here for now and not go into the schema file itself.

<?xml version="1.0" encoding="utf-8" ?>
<xbrli:xbrl
  xmlns:xbrli="http://www.xbrl.org/2003/instance"
  xmlns:iso4217="http://www.xbrl.org/2003/iso4217">

  <xbrli:unit id="usd">
    <xbrli:measure>iso4217:USD</xbrli:measure>
  </xbrli:unit>

  <xbrli:context id="2020FY">
    <xbrli:entity>
      <xbrli:identifier scheme="http://www.sec.gov/CIK">0000320193</xbrli:identifier>
    </xbrli:entity>
    <xbrli:period>
      <xbrli:startDate>2016-09-25</xbrli:startDate>
      <xbrli:endDate>2017-09-30</xbrli:endDate>
    </xbrli:period>
  </xbrli:context>  

  <revenue unitRef="usd" contextRef="2020FY">16000000</revenue>
</xbrli:xbrl>

By using the xbrli namespace we show that we are using the XML elements (<unit>, <context>, <period>, <identifier> etc.) of the XBRL specification. An XML validator could now check for each element whether it has the correct children and all necessary attributes. For example, for the <identifier> element, the XBRL specification requires that it has an attribute scheme that indicates which type of company identification number the element contains.

By the way, the XML file we are creating is called Instance Document in the XBRL jargon. It holds all our financials that we want to publish. - So, we can check another box 🥳.

To summarize; the basic structure of our Instance Document (our XML report) is now defined by the XBRL Specification. We have introduced contexts that contain information about the timeframe and company a number is related to. We have also introduced unit-elements that define the unit that belongs to our number. Both units and contexts can be referenced many times in our Instance Document.

But one thing is missing. Currently no one tells us which financial information we can encode in our document. Currently we only have one <revenue> element. Can we add another called <cash>? This is regulated by a so-called Taxonomy. The taxonomy defines the different (accounting) concepts that can be used in the Instance Document. It also contains additional information about the relationships between multiple concepts and additional resources for concepts (e.g. labels), but I won’t go into that in this blog post.

Our Instance Document:

<?xml version="1.0" encoding="utf-8" ?>
<xbrli:xbrl
  xmlns:xbrli="http://www.xbrl.org/2003/instance"
  xmlns:iso4217="http://www.xbrl.org/2003/iso4217"
  xmlns:us-gaap="http://fasb.org/us-gaap/2020-01-31">

  <xbrli:unit id="usd">
    <xbrli:measure>iso4217:USD</xbrli:measure>
  </xbrli:unit>

  <xbrli:context id="2020FY">
    <xbrli:entity>
      <xbrli:identifier scheme="http://www.sec.gov/CIK">0000320193</xbrli:identifier>
    </xbrli:entity>
    <xbrli:period>
      <xbrli:startDate>2016-09-25</xbrli:startDate>
      <xbrli:endDate>2017-09-30</xbrli:endDate>
    </xbrli:period>
  </xbrli:context>  

  <!-- This is new, we are now using the us-gaap prefix -->
  <us-gaap:Revenue unitRef="usd" contextRef="2020FY">16000000</us-gaap:Revenue>
</xbrli:xbrl>

The Taxonomy:

<xsd:schema 
  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns:xbrli="http://www.xbrl.org/2003/instance">

  <xsd:element id="us-gaap-Revenue" name="Revenue"
    nillable="true" substitutionGroup="xbrli:item"
    type="xbrli:monetaryItemType"
    xbrli:balance="credit" xbrli:periodType="duration"/>
  <!-- Many more xml elements (Concepts)... -->
</xsd:schema>

Actually, this is just the Taxonomy schema. In the real world, a taxonomy would be much more complex!

Our Instance Document now uses the tag <us-gaap:Revenue> for the fact. The namespace http://fasb.org/us-gaap/2020-01-31 shows us that we are referring to the concept Revenue from the us-gaap taxonomy of 2020. The Taxonomy also stores additional information about the concept Revenue. This information also allows the receiver of our report to validate it.

Summary

To summarize: Our goal is to transfer financial data. Each financial data point is called a Fact. To each fact belongs a Context that stores information about the date or timeframe as well as the company the fact belongs to. Most facts also have a Unit attached to them. To transfer our facts, we start by creating an XML document. This XML document is called Instance Document. The structure of our Instance Document is defined by the XBRL Specification. The different concepts we can use for tagging our facts i.e.: (Assets, Liabilities, CashAndCashEquivalentsAtCarryingValue) are defined in the Taxonomy.

This blog post is written with the goal of providing the most easily digestible technical introduction to XBRL. However, it is therefore somewhat imprecise in some places and/or omits important elements. A more detailed description can be found in my Blog Post What is XBRL?.

Explaining what learned models predict

2021-04-05T14:04:26+00:00

Explained what learned models predict

This essay was originally created for a university application. But before the essay gathers dust on my hard drive, I’d rather share it here 😄.

Abstract

There are many problems in computer science that cannot or can only be solved with extreme difficulty using pre-programmed rules. An example here would be the recognition and classification of images. Here, machine learning (ML) algorithms offer a good solution approach by recognizing regularities from previous examples, storing them, and applying them to the new images. However, the safety and reliability of machine-learning systems cannot be readily assessed because the individual steps in the learning process of an ML system are not easily comprehensible to a human, making the decision path very opaque. Given the ever-increasing impact of ML systems in our lives, it is very important that these systems are reliable since wrong or unintended results could have extreme consequences.

This paper will discuss a small sample of possible causes of reliability problems and present some solutions.

Link to the document

Financial reporting in the digital age

2021-01-17T06:53:36+00:00

My Bachelor Thesis

At the end of my bachelor degree in business informatics at OTH Regensburg I wrote my bachelor thesis about “Financial reporting in the digital age”. In my thesis I discuss the XBRL standard and its technical structure. I also developed the Python XBRL parser “py-xbrl” while writing my thesis. To demonstrate the capabilities of the XBRL standard, I processed and analyzed tens of thousands annual and quarterly reports (10-K and 10-Q) using “py-xbrl”.

Unfortunately, my entire thesis is only available in German. Full Thesis (German)