2

We use a XBRL processor to ingest filings from SEC. Often times, a company declares a metric in different filings with different concepts - with or without exactly matching values - but to be regarded as the same financial metric. Essentially when you want to create a stitched view of all the filings, these numbers should appear on the same row. I'd provide an example to make it clear:

ASGN's 2020 10-K filing uses us-gaap:IncomeLossFromContinuingOperationsBeforeIncomeTaxesMinorityInterestAndIncomeLossFromEquityMethodInvestments to report EBT.

enter image description here

ASGN's 2021 10-K filing uses us-gaap:IncomeLossFromContinuingOperationsBeforeIncomeTaxesExtraordinaryItemsNoncontrollingInterest to report EBT.

enter image description here

If you notice, even the figures for 2020 and 2019 do not match between the two filings. My question is - how do you reconcile these cases in code - to create a stitched/continuous view? Is this a solved problem or is it more of a process where you need to make manual interventions? Are there libraries that help with this? Is there mapping information available with the SEC that can be used - even when the data do not agree? Would be great if anyone can help with this. Thanks.

DebD
  • 373
  • 3
  • 20

3 Answers3

3

From personal experience I can give you a list of considerations when it comes to non-program-development people who work in the financial sector and submit standardized information:

  1. the level of respect they have for the "you have to do things this way" paradigm is effectively 0.

  2. expectance that filings aren't filled out properly/correctly should be at 100%.

  3. Even though sec filings are meant to consolidate data in a standardized, meaningful, and readily available transparent facet, the financial sector is plagued with ambiguity and interoperable terms which may differ from corporate entity to corporate entity.

... or in short ... in their point of view "ILFCOBITEINI and ILFCOBITMIAILFEMI look pretty similar, so they pretty much mean the same thing."

As far as I know, there is no support on behalf of sec or other federation entities which is in charge of controlling sec filing accuracy since the idea is " you file it wrong... you pay a fine " .... meaning that due to interoperability of forms that "wrong" level is pretty ambiguous.

As such, the problem is that you must account for unexpected pseudo-fails when it comes to filings, meaning that you should probably write some code which does structural-to-content identity matches across different entries.

I'd advise using a reasoning logic subsystem (that you'll have to write) instead of a simple switch-case statement operating on a "if-this-exists-else" basis. ... and always consider that the level of incompetence in the financial sector is disgustingly high.

EverNight
  • 964
  • 7
  • 16
  • 1
    Spot on! The gap between what is promised by the XBRL proponents and what is actually delivered is wide and deep... – Jack Fleeting Mar 24 '22 at 13:17
  • This was my hunch too - that it's unfeasible trying to make sense of filings through code with even 80% coverage. Can you give me an example of what you mean by "structural-to-content identity matches"? – DebD Mar 25 '22 at 12:49
  • @DebD the structure would be something like (1) "incomeStatement, revenue_simple, gross_profit" and (2) "incomeStatement, revenue_kindaSimple, gross_profit" ... i.e. 2 documents with 6 total fields, in which 2 differ from one another. content sould be their respective values. So a structure-to-content identity match routine would check whether the revenue_kindaSimple value is identical to revenue_simple... meaning that even though the "structure" of the two documents differs fundamentally, since they have the exact same value, they are objectively, evidently the same. – EverNight Mar 29 '22 at 09:49
  • the above should be taken with a grain of salt... because you could technically wind up in a situation in which two fields that irl have nothing in common just happen to share this kind of similarity when you check it... ... so i'd cross-reference multiple instances just in case checking one case leaves me open to false positives. ... i.e. profit = 0, debt = 0... false positive would essentially boil down to "debt" = "profit" – EverNight Mar 29 '22 at 09:52
0

It depends ...

Why is the data for the same "row" (ex. revenues), for the same time period (ex.the 12 months ending dec 31, 2020), different? (Merger or acquisition? Accounting restatement? Something else?)

How might you handle this example, if you were manually "by hand" creating a financial model for this company in a spreadsheet?

Possible approaches: "Most recent": For each row for each time period, use the most recently reported data.

"As first reported": For each row and each time period, use the "as first reported" data.

These are only two of several ways to present the data.

Neither of the above is "correct" or "better". Each has pros and cons.

Thoughts? Questions?

TC1
  • 21
  • 4
0

Point 1: differences aren't unusual, as companies make restatements and corrections from one year to the other. You will find them anywhere, not only with XBRL.

Point 2: they are using labels that look the same for two distinct concepts. At first, that should not exist in that case, as it induces to error if one is just downloading the labeled tables from the SEC. However, the FASB may have changed that from one year to the other. Did you check it? There are other reasons for this kind of error, which are actually subject of an ongoing research project of mine. They involve error and fraud. So, be careful. There could be more to it.

To answer your question, there is no way to make sure you are doing your work correctly given those discrepancies other than getting an accountant/lawyer to check them. You could also get an intern ;)

Denis Alves
  • 31
  • 3