Tackling issues with operating lease data

[Teji Abraham]

Hi David:
I have seen some issues with Operating Lease data and posting here to both raise awareness and also to inquire if there are any causes/solutions for these. Not sure if this is because of wrong xbrl filing from the company or some other reasons

So the typical type of problems found are:
a) Operating Lease total not adding up to the current and non-current components of Operating Lease
b) Scale of Operating Lease data being wrong
c) Mixing up of various operating lease data elements

Thanks and look forward to your inputs.

Example 1:
Fonar Corporation
Period: 2019-12-31, cik: 0000355019

Per SEC Filing (all in thousands):
Operating Lease Liability: 31,867
Operating Lease Liability Current: 3185
Operating Lease Liability Non-Current: 28682

Per XBRL data feed (all in thousands):
Operating Lease Liability: -987
Operating Lease Liability Current: 3185
Operating Lease Liability Non-Current: 28682

Note: the negative Operating Lease Liability total despite the positive sub-components

Example 2: (Scale of one of data components off by a factor of 1000)
SecureWorks Corp
Period: 2020-01-31, cik: 0000355019

Per SEC Filing (all in thousands):
Operating Lease Liability: 29,554
Operating Lease Liability Current: 4,885 (implied, ie calculated)
Operating Lease Liability Non-Current: 24,669

Per XBRL data feed (all in thousands):
Operating Lease Liability: 29,554,000
Operating Lease Liability Current: NIL
Operating Lease Liability Non-Current: 24,669

Example 3: (Mixed up operating lease data elements)
American River Bankshares
Period: 2019-12-31, cik: 0001108236

Per SEC Filing (all in thousands):
Operating Lease Liability: 3098
Operating Lease Liability Current: 769
Operating Lease Liability Non-Current: 2329 (implied)

Per XBRL data feed (all in thousands):
Operating Lease Liability: 915
Operating Lease Liability Current: 3098
Operating Lease Liability Non-Current: NIL

Note: Two issues in this example: total Operating Lease Liability is presented as Operating Lease Liability Current and values don’t add up accurately.

[david.tauriello@xbrl.us]

Hi Teji –

In example 1, it looks like company is using the labels ‘Total lease liability’ for the tag FinanceLeaseLiability (31867) and ‘Present Value discount (5.5% weighted average)’ for OperatingLeaseLiability (-987) immediately above the total in the table.

Search the label linkbase at https://www.sec.gov/Archives/edgar/data/355019/000035501920000007/fonr-20190930_lab.xml for text ‘Total lease liability’ and ‘Present Value discount (5.5% weighted average)’ to see these elements.

In example 2, either the text “(in thousands)” is incorrect for the table – all of the values are in millions or the scale is incorrect on all of the values in the table (should be 3 not 6)

Search for 29,554 in the company inline, then click the corresponding value and look at the ‘scale’ line: https://www.sec.gov/ix?doc=/Archives/edgar/data/1468666/000146866620000019/scwx10-kfy2020x01312020.htm

I’ll circle back on example 3. FWIW, our Public Filings Database is a copy of what the SEC says it has accepted into EDGAR. The data is ‘as-filed’ – we don’t normalize what we get.

[Teji Abraham]

Thanks much David. Some clarifications below.

* Across all the data in my examples “(in thousands)” for xBRL data is from me to make the data more readable (I took the raw xbrl data and divided by 1000 to make it more presentable).

*For Example 1, I am assuming your conclusion is that the company made an erroneous filing? Is there a possibility that the company accurately files the sec text filings but somehow ends up filing erroneous xbrl filing ?

*For Example 2, as mentioned I made the divisions by 1000 for readability. And I did the division for all of the data items. For clarity the raw values from the xbrl api were: 29,554,000,000 (For Operating Lease Liability) and 24,669,000 (For Operating Lease Liability Non-current). And my apologies, the cik should be: 0001468666

*Sounds good regarding Example 3.
Thanks again, Teji

[david.tauriello@xbrl.us]

Teji – apologies for the delay in responding:

• In Example 1, I don’t know that changing the label is an error, per se – it may be part of the decision-making process at the executive level or in external reporting when it composes its financial report, which serves both its existing sharehholders (who may be accustomed to certain presentation characteristics and syntaxes relative to business) and regulators. Best course would be to look at the company’s other financial reports, to see if this is consistent with past practice.
• I’m not sure what the question is here (?) – can you post the exact reference to 29,554,000 as the company’s OLL data point in the SEC filing? The OLL value is 29,554,000,000 in the filing and it was scaled to millions by the filer <ix:nonFraction id="d22155653e1059-wk-Fact-8FBC6FAF198D16C38F98D6B453432F85" name="us-gaap:OperatingLeaseLiability" contextRef="FI2020Q4" unitRef="usd" decimals="-6" scale="6" format="ixt:numdotdecimal">29,554</ix:nonFraction> from https://www.sec.gov/Archives/edgar/data/1468666/000146866620000019/scwx10-kfy2020x01312020.htm (not thousands, as the ‘OLL Non-Current value is), so when you do your thousands recalculation for readability, it drops 000 from each number. If your question is on the NIL reported as OLL Current by the company, the Accounting Policies for the report looks like it explains the adoption of FASB ASU 2016-02, “Leases (Topic 842)” where the company elected ‘by asset class, not to record on the balance sheet a lease whose term is twelve months or less including reasonably certain renewal options’. As a result, your calculated ‘current’ value does not match what was reported (NIL)
• In your Example #3, Similar to the first example, this is a function of the company’s use of the label linkbase. It appears you are reading its Operating Lease Liability Current from <us-gaap:OperatingLeasesFutureMinimumPaymentsDueCurrent contextRef="E14Q1" unitRef="USD" decimals="-3">769000</us-gaap:OperatingLeasesFutureMinimumPaymentsDueCurrent> and the company has labelled its OLL Current inclusive of ‘other liabilities’ `Operating lease liability classified as other liabilities, which it looks like are OperatingLeasesFutureMinimumPaymentsDueIn 2 – 5 years and labelled as ‘Present value of lease liabilities’. (see note 12 – COMMITMENTS, CONTINGENCIES AND CONCENTRATIONS OF CREDIT RISK – https://www.sec.gov/Archives/edgar/data/1108236/000101905620000200/arb_10k19.htm)

[Teji Abraham]

David,
Thanks much for the response. It seems we need to refine the xbrl api being used. Our current xbrl api for retrieving the Operating Lease data and its sub-components (using FONR with cik=0000355019 for period ending 2019-12-31) looks like:

https://api.xbrl.us/api/v1/fact/search?entity.cik=0000355019&concept.local-name=OperatingLeaseLiability&period.instant=2020-01-01&fact.ultimus=true&fields=concept.local-name,fact.value,%20fact.ultimus,%20fact.has-dimensions,fact.id

We are making the following assumptions when calling the above API:
1) concept.local-name=OperatingLeaseLiability retrieves the total value of the operating lease for the specified period

2) that as long as fact.ultimus=true is specified, the most recent value for the concept is retrieved

3) xbrl always returns the raw data without any scaling

We have some internal algos that cross-check on these and these seem to hold for most of the companies we are covering, except for a few outliers.

It seems 1) and 3) may not necessarily be true and perhaps we need to constrain the api further or check the result.

Any thoughts on how to augment the current api to also retrieve the label and scale for the concept’s fact.value ?

Thanks again, Teji

[david.tauriello@xbrl.us]

Teji – thanks for the example. There may be two other forces to consider that are creating ‘outliers’ in your results.

1. FASB’s ASU 2016-02 Leases (Topic 842)” became effective in December, 2019 – it may be an important read for your team, in understanding how companies might be revising their reporting relative to leases.
2. inline XBRL is a growing requirement – to accommodate the presentation characteristics of it, we have additional fact fields that may be useful in evaluating data. Consider returning fact.inline-display-value and fact.inline-scale to your query. This additional information may be an effective check on the calcs you’re doing. If you look back at the OLL I posted today for Example #2, you’ll see the ‘scale’ attribute. On inline filings, I believe we parse the data into our database using this integer, multiplied by the fact inline display value, dumping the result into fact.value. I’ll reply again if that’s not correct. Eventually all companies will report inline, and will need to report a ‘scale’ attribute.

On this Google Sheet, I’ve updated your query to include the two inline-related details that might be helpful (the report you shared is not inline, so these values are null and 0). The second query uses details from your query to get 1abel.text and other pieces of information, including the fact that this is a US-GAAP element (concept.namespace). The other queries would show dts.id for all US-GAAP and IFRS Taxonomies (if you wanted to investigate labels in base taxonomy versions).

[Teji Abraham]

Thanks David, much appreciate the inputs and yes, Topic 842 adoption is the reason why we have been using concept.local-name=OperatingLeaseLiability and other related concepts to retrieve operating lease related data.

The suggestions you have made make sense, essentially the process would become a two-stage process.

Is there perhaps a single-stage approach to retrieving the operating lease components, namely: OperatingLeaseLiability, OperatingLeaseLiabilityNoncurrent, OperatingLeaseLiabilityCurrent, and OperatingLeaseRightOfUseAsset ?

Thanks again, Teji

[david.tauriello@xbrl.us]

Teji –

To get the label detail will take two stages, because you’re dealing with two distinct components of the company’s filing:

• ‘label’ is part of the company taxonomy (the label linkbase) which imports US GAAP
• ‘fact’ is part of the reported data called the ‘Instance File’ on EDGAR pages like this: https://www.sec.gov/Archives/edgar/data/355019/000035501920000007/0000355019-20-000007-index.html

[Teji Abraham]

Thanks David.
I have noticed cases where multiple label texts are returned for e.g. if call xbrl api with dts.id=390342 and concept.local-name=OperatingLeaseLiability, two data points are returned for label.text.

How should we handle such cases.

Thanks again, Teji

[david.tauriello@xbrl.us]

Teji – my apologies for the slow reply. The /relationship endpoint can help where an element may be used for several facts in a company dts. This endpoint has details related to structuring the facts in the report.

If you return relationship.preferred-label for the concept as ‘relationship.target-name’, you can compare this parameter with label.role-short

See row 10 of the updated Google Sheet

[Author]

Posts