Developing Standardized Metric Mapping for Improved Consistency and Comparability

Developing standardized metric mapping for improved consistency and comparability

Fundamental Concept

In the JSON API, we report standardized metric names instead of XBRL QNames. This is done for many reasons, but the main reason is that this way we can compare figures across different companies, without losing the semantic context encoded in the name. To translate the XBRL QName to a standardized metric name, we use a mapping file called "Company map". If there is no map for a particular company, we use a generic map. Company maps are stored in ~/assets/standardized/ folder below the project folder. Company map files are named like this: <CIK>.json where CIK is the company CIK code. The generic map is stored in all.json file.

Let's say there are two companies, Company A and Company B, both reporting their financial data in XBRL format. Company A uses the QName "srt:Revenue" to report its revenue, while Company B uses the QName "ifrs-full:RevenueIncludingInterest" to report theirs.

To compare the revenue figures of these two companies, we need to map their QNames to a standardized metric name. Using the mapping file called "Company map", we find that "srt:Revenue" maps to the standardized metric name "Revenue", and "ifrs-full:RevenueIncludingInterest" maps to the same standardized metric name "Revenue". This means we can compare the revenue figures of Company A and Company B directly.

Now, let's consider another example. Company C reports its revenue using the QName "us-gaap:SalesRevenueNet", which does not have a corresponding mapping in their company map file. In this case, we would use the generic map file "all.json" to find the standardized metric name for "us-gaap:SalesRevenueNet", which is "Net Sales". We can then compare the revenue figures of Company C with other companies that report their revenue using the standardized metric name "Net Sales".

Making a Map of Company Metrics

We make a list called a "company map" by comparing different pieces of information from a company's financial reports. We do this by asking a website called Calcbench for help. We can only use one specific type of financial report, called a 10-K filing, to make the list. 

Different Scenarios

Direct match

If the name of the financial information in a company's report is the same as the name of a standard financial metric used by Calcbench, we just put a checkmark on our map to show that they match. 

1

Value-based match

If the numbers in XBRL and Calcbench are the same but have different names, we create a record in the map to connect the two names. It's important to know that sometimes one XBRL fact can match with multiple standardized names. 

2

Aggregation-based match

In a program, we have a group of numbers that are categorized based on something like a product or region. We add up these numbers and compare them to a number from Calcbench API. If the sum of our numbers matches the Calcbench number, we make a note of the XBRL fact name that corresponds to the standardized metric name. 

3

Separation-based match

If there's a fact that has some specific information, like a certain region or category, and its value matches a standardized metric, we create a map that links the XBRL element name and all its specific information to the standardized metric name. 

4

Getting information from XBRL filings and sharing it through the API.

First, we read facts from XBRL filings and identify their QNames. Then we match those QNames with standardized metrics and send the corresponding values to the API. 

 Different Scenarios:

Fetch facts using direct match

If the name of the fact in the XBRL file is the same as the name of a standardized metric, we simply report the value in the API without doing anything else. 

5

Fetch facts based on value match

If we have already mapped the name of the fact to a standardized metric in the company map, we report the value of the fact in the API using the matching standardized metric name. 

6

Fetch facts based on aggregation match

If we can match the name of an XML element and its associated dimensions to a standardized metric name from our company map, then we report the total value of all facts in that set as a single fact in the API using the resolved standardized metric name. 

7

Fetch facts based on separation match

If the name of an XML element and all of its associated dimensions (such as geographic region) match a standardized metric name from the company map, we report the fact value in the API using the resolved standardized metric name. This is similar to case 2, but we match the full fact signature instead of just the element name. 

8