Unclear +/- sign of some facts #91
Comments
|
I know this was raised a bug before, and was closed as an "accounting detail", but I am still unsure how to proceed. Prefix "-" means that calculation weight was "-1.0". In some cases even negative weight for an already negative value: |
|
Apologies for the spam, I am also only figuring this out as I go along.
|
|
@codinguncut As the pdf says in the previous comment, the weight is assigned to a particular calculation relationship, not the value. Depending on what is being calculated, a particular value could be added or subtracted (which is why it's modeled this way). One way you can tackle this is to parse the CALCULATION Linkbase as well as the filing. Once you have the calculation linkbase you can iterate over every concept in the calc linkbase, for each concept, fill in the value you found in the facts lists and you're set. I've been working through this exact exercise over the past couple weeks, so lemme know if we can help each other. @manusimidt please correct me if you've developed a different way to do this. |
|
Thank you both for your suggestions! Yes, if i understand correctly, the calculation linkbase does not indicate which sign the fact has, but how it relates to other facts.
Furthermore the calculation linkbase shows you that the one fact is substracted from the other: I know that its currently very tedious to work with the linkbases in A feature that also was requested by many people was to compile the presentation linkbase. So that i.e.: you call a function of Tomorrow I will look further into the exact submission (AAPL 2021-09) @codinguncut pointed out and think about solutions. Unfortunately, I currently only find time to implement new features in the libary during the semester break because I study full time and work part time on the side, but I'll still take a closer look at the issue tomorrow :) |
|
@manusimidt I've been grappling with this issue as well. Specifically where the filer overrides the base calculations which happens in all the filings I've seen so far (a few dozen). I'm only really interested in the us-gaap taxonomies, but I believe the following implementation should follow for all. Currently my implementation grabs what I call the referenced base taxonomy. For example, FilingA references the us-gaap 2022 taxonomy. For which I parse every calculation linkbase in the base taxonomy. Then I take FilingA's calculation linkbase and replace every concept defined in the base with FilingA's definition. So imagine the us-gaap has us-gaap_NetIncomeLoss = us-gaap_ProfitLoss + us-gaap_SomeOtherIncomeSource + ... I replace the definition in the us-gaap with FilingA's definition. In the next week or so I'll be running this across a large set of filings to confirm my implementation is roughly correct, but lemme know if you see anything glaringly wrong about this or if you need any further clarification. |
|
hi @Ajmed @manusimidt, I don't quite understand the relationship between the base schema and "overrides". I would have thought that "FilingA definition" would be a subset of the "us_gaap definition", otherwise the value of the whole XBLR thing would be a bit dubious. https://xbrl.us/forums/topic/how-to-find-a-complete-list-of-similar-concept/
|
|
Generally, regulators decide between one of two different reporting models. The Open financial reporting (like SEC uses it) and the closed financial reporting (like the company house in the UK uses it). In a closed reporting model the company must have the common taxonomy (IFRS for UK) as base taxonomy and is not allowed to add new concepts, relationships and resources. In an open reporting model the company is allowed to create its own extension taxonomy for every submission. The most common thing companies do in their extension taxonomy is to add new concepts, resources and relationships. For example: Apple might add a new concept "aapl_iPadMember", add the label (resource) "Total Iphones sold" and add the relationship (calculation) "us-gaap_TotalProductMember = aapl_iPhoneMember + aapl_iPadMember" To be honest I have never seen a submission that overrides important concepts of the base taxonomy. I mostly worked with SEC submissions and the us-gaap taxonomy which they import usually also has no presentation or calculation linkbase, which only leaves the calculation/presentation linkbases that the company provides. But yes, @codinguncut you definitely have a point. I also run into this issue some times. But I can tell you that from my experience most of the companies use common us-gaap tax on their three big financial statements (Cash-flow, Balance Sheet, Income Statement). So to summarize: Overriding relations in extension taxonomies is complex and theoretically a thing but not really relevant for SEC submissions (according to my experience). What is way more important is to capture the newly added concepts and relationships. |
|
I can also really recommend the book "XBRL for interactive Data" from Debreceny. It also has a chapter on this topic and it is explained quite well. (The following figure is from this book)
|
|
@Ajmed yes, this sounds pretty interesting! I looking forward to hear from you about your results! I have also often thought about how I can parse this in the easiest way. Until now I thought to make an artificial "final taxonomy", go recursively through all imports, start at the deepest taxonomy and gradually add all resources/relations to the "final taxonomy". If a relation is overwritten in a "higher" taxonomy, this would then also have to be overwritten in the "final taxonomy". The goal of the whole thing is to end up with just one taxonomy that is easy to work with and not (as it is currently) an import array in which further taxonomies are stored which in turn has also an import array that can contain further taxonomies (and so on). |
|
@manusimidt That's exactly as I have it currently. Still a work in progress and only focused on the us-gaap, but lemme provide an example filing: 0001090872-22-000012. Specifically you can open the calc linkbase and ctrl-f for us-gaap_NetIncomeLoss, below I have the relevant concept highlighted: {
"us-gaap_NetIncomeLoss": {
"children": [
{
"concept_id": "us-gaap_IncomeLossFromContinuingOperationsBeforeIncomeTaxesExtraordinaryItemsNoncontrollingInterest",
"weight": 1.0
},
{
"concept_id": "us-gaap_IncomeTaxExpenseBenefit",
"weight": -1.0
}
]
}
}As I understand it, the above is a complete override of the base us-gaap_NetIncomeLoss calculation. Specifically: us-gaap-stm-soi-cal-2022.xml "us-gaap_NetIncomeLoss": {
"children": [
{
"us-gaap_ProfitLoss": 10
},
{
"us-gaap_NetIncomeLossAttributableToNoncontrollingInterest": 20
}
],
}Sorry for the inconsistent formats. The former is redacted output from this library and the latter is how I've been parsing the calc linkbases so I get constant lookup by concept id. In any case, now, when I want to report to a business user the us-gaap_NetIncomeLoss of a filing. I use the calculation from the filer's calc linkbase instead of the us-gaap linkbase. To be explicit, I'm using the calculation: (Notice the minus sign on the second term from the weight.) |
|
@manusimidt Regarding Closed reporting, it appears that at least in Denmark it is possible to add concepts to IFRS-Full (parken:ResultFromOperatingActivitiesBeforeAmortizationTransferActivitiesAndSpecialItems):
Also in the UK (procookgroupplc:BonusIssue): |
|
I am really confused by the other tabular data formats provided by Edgar (xbrl-json, tsv, etc.)
If filers can arbitrarily assign "+" or "-" signs to their facts, or completely change calculation logic, then all of the above would be worthless because the sign to be used would not be clear from the json or tsv data. Not even to mention that at least the json data seems to completely throw away the schema versioning. |
|
Nice tool, also shows how much companies extend the base XBRL schema: |
|
@Ajmed Yes, in theory, it exactly works that way. Disclaimer: I am also not really familiar with the taxonomy architecture. But I try my best: Big taxonomies like the us-gaap have different entry points. If you i.e.: look at the taxonomy directory of the us-gaap 2021 you will see five different folders: I don't know exactly why but this is probably prescribed by the regulator. |
|
For some reason, i couldn't find a single file/website describing the architecture of the us-gaap taxonomy. I could only find one for the european ESEF taxonomy that was introduced last year:
I would understand it this way: if you import the full taxonomy ( |
|
@codinguncut "On a case-by-case basis" 😂🤦🏼♂️ defeats the idea of XBRL a bit... |
Hi,
thank you so much for the work you have put into this library.
I am using this library to process SEC XBRL filings to fetch information from P&L, Balance Sheet and Cash Flow Statements, etc.
A couple of challenges I have run into:
I.e. for AAPL 2021-09, IncreaseDecreaseInAccountsReceivable has a positive value, albeit in the PDF filing it is displayed as negative, and there is a
<link:calculationArc order="6" "weight="-1.0"Not knowing the sign up a value is a pretty big challenge to overcome ;)
to_json()processRegards,
Johannes
The text was updated successfully, but these errors were encountered: