One of things has continued to surprise me with the adoption of XBRL is the amount of discussion that the question of tagging figures with the correct sign can generate. Brendan Mullan recently managed to start no fewer than 12 separate threads on this topic on the xbrl-public list, some of which resulted in significant further discussion.
Marking up figures in electronic format is not a new phenomenon, and I’m not aware of any other domains that have managed to get so tangled up in sign issues. What is it about the application of XBRL to financial reports that causes such difficulty? I have some ideas, but first let’s look at how to do it right.
All you need to know to get the sign right
Let’s consider the following extract from a Profit and Loss statement:
| 2011 £’000 |
2010 £’000 |
|
| Turnover | 518 | 498 |
| Cost of sales | (321) | (299) |
| Gross profit | 197 | 199 |
| Administrative expenses | (211) | (105) |
| Operating profit/(loss) | (14) | 94 |
There’s a really simple way to get the sign right in XBRL, every time. Simply take the name of the concept that you’re using to tag the figure, and turn it into a question by prefixing it with “What was the… ”
For example, suppose our concept is called “Cost of Sales”.
Question: What was the Cost Of Sales?
Answer: £321,000
Even though the figure in the accounts is shown as “(321)”, you wouldn’t answer that question by saying “minus £321,000”, would you? So we tag a positive number.
On the other hand, if in your answer you need to correct the question, then the sign should be negative:
Question: “What was the Operating Profit?”
Answer: “Actually, there was a loss of £14,000.”
Our answer is the opposite of the question that was asked, so we’d tag a negative number against a concept called “Operating Profit”.
Sometimes the concept name will be more explicit about the sign convention. For example, you might have a concept called “Increase (Decrease) in Accounts Receivable”. In this case, just ignore the bit in brackets, so your question becomes:
Question: “What was the Increase in Accounts Receivable?”
If your answer starts, “actually there was a decrease…” then you should tag a negative number. Otherwise, you should tag a positive number.
It really is that simple. Nothing to do with balance attributes, negated labels, calculation weights or any of that stuff.
How did we end up in such a muddle?
There’s a number of reasons why what should have been a really straightforward issue has become confused into something much more complicated. I’ll address these in a series of follow-up articles:
- Names, labels and extensions
- Financial reporting has sign conventions, XBRL has a rule
- Balance attributes: help or hindrance?
- Calculation weights and negated labels
Logical, as always, the advice is correct and sound. However, as in life, there are always exceptions.
In the U.S. GAAP Financial Reporting taxonomy (“UGT”), there are cases where primary concepts have been modeled with incorrect balance types. In these cases, the Balance type (debit, credit) can be very important to deterring the correct polarity of an input (positive, negative).
For example, LossContingencyAccrualCarryingValueProvision – credit – duration – The charge against earnings in the period to increase loss contingency liabilities, net of any adjustments to reduce previously estimated charges.
This concept is defined as the charge against earnings, net of adjustments.
The credit balance requires a charge to earnings (i.e., expense) to be entered as a negative value.
If the value represents a net reversal of a previously recognized provision, the input would be a positive value.
The positive or negative input is not based on the label of the concept, but the concept’s definition taken in context of its modeled balance type.
As the example concept is a credit balance type, a charge against earnings for the period (i.e., a debit to earnings) is entered as a negative because a negative credit is a debit.
Gregg,
Your comment relates to a point that I will be covering in a follow-up article, which is that balance attributes add complexity, and in this case, ambiguity what should be a simple problem.
As you say, in the case of LossContingencyAccrualCarryValueProvision the balance attribute appears to contradict the name and definition of this concept.
Ignoring the balance attribute completely, if I asked you the question “What was the Loss Contingency Accrual, Carrying Value, Provision?” about a given set of accounts, would you have any difficulty in deciding how to respond?
Certainly if I turn the definition into a question, the sign convention is unambiguous: “What was the charge against earnings in the period to increase loss contingency liabilities, net of any adjustments to reduce previously estimated charges?” If there was a “charge against earnings” then you report a positive value. It’s all perfectly simple until you look at the balance attribute…
The existence of the balance attribute appears to have led XBRL “best” practice to follow an approach which is at odds with the simple and common sense approach that is common place in all other domains.
Paul
Logical, as always, the advice is correct and sound. However, as in life, there are always exceptions.
In the U.S. GAAP Financial Reporting taxonomy (“UGT”), there are cases where primary concepts have been modeled with incorrect balance types. In these cases, the Balance type (debit, credit) can be very important to deterring the correct polarity of an input (positive, negative).
For example, LossContingencyAccrualCarryingValueProvision – credit – duration – The charge against earnings in the period to increase loss contingency liabilities, net of any adjustments to reduce previously estimated charges.
This concept is defined as the charge against earnings, net of adjustments.
The credit balance requires a charge to earnings (i.e., expense) to be entered as a negative value.
If the value represents a net reversal of a previously recognized provision, the input would be a positive value.
The positive or negative input is not based on the label of the concept, but the concept’s definition taken in context of its modeled balance type.
As the example concept is a credit balance type, a charge against earnings for the period (i.e., a debit to earnings) is entered as a negative because a negative credit is a debit.
Gregg,
Your comment relates to a point that I will be covering in a follow-up article, which is that balance attributes add complexity, and in this case, ambiguity what should be a simple problem.
As you say, in the case of LossContingencyAccrualCarryValueProvision the balance attribute appears to contradict the name and definition of this concept.
Ignoring the balance attribute completely, if I asked you the question “What was the Loss Contingency Accrual, Carrying Value, Provision?” about a given set of accounts, would you have any difficulty in deciding how to respond?
Certainly if I turn the definition into a question, the sign convention is unambiguous: “What was the charge against earnings in the period to increase loss contingency liabilities, net of any adjustments to reduce previously estimated charges?” If there was a “charge against earnings” then you report a positive value. It’s all perfectly simple until you look at the balance attribute…
The existence of the balance attribute appears to have led XBRL “best” practice to follow an approach which is at odds with the simple and common sense approach that is common place in all other domains.
Paul
Logical, as always, the advice is correct and sound. However, as in life, there are always exceptions.
In the U.S. GAAP Financial Reporting taxonomy (“UGT”), there are cases where primary concepts have been modeled with incorrect balance types. In these cases, the Balance type (debit, credit) can be very important to deterring the correct polarity of an input (positive, negative).
For example, LossContingencyAccrualCarryingValueProvision – credit – duration – The charge against earnings in the period to increase loss contingency liabilities, net of any adjustments to reduce previously estimated charges.
This concept is defined as the charge against earnings, net of adjustments.
The credit balance requires a charge to earnings (i.e., expense) to be entered as a negative value.
If the value represents a net reversal of a previously recognized provision, the input would be a positive value.
The positive or negative input is not based on the label of the concept, but the concept’s definition taken in context of its modeled balance type.
As the example concept is a credit balance type, a charge against earnings for the period (i.e., a debit to earnings) is entered as a negative because a negative credit is a debit.
Gregg,
Your comment relates to a point that I will be covering in a follow-up article, which is that balance attributes add complexity, and in this case, ambiguity what should be a simple problem.
As you say, in the case of LossContingencyAccrualCarryValueProvision the balance attribute appears to contradict the name and definition of this concept.
Ignoring the balance attribute completely, if I asked you the question “What was the Loss Contingency Accrual, Carrying Value, Provision?” about a given set of accounts, would you have any difficulty in deciding how to respond?
Certainly if I turn the definition into a question, the sign convention is unambiguous: “What was the charge against earnings in the period to increase loss contingency liabilities, net of any adjustments to reduce previously estimated charges?” If there was a “charge against earnings” then you report a positive value. It’s all perfectly simple until you look at the balance attribute…
The existence of the balance attribute appears to have led XBRL “best” practice to follow an approach which is at odds with the simple and common sense approach that is common place in all other domains.
Paul
This blog makes sense. I also think the issue stems from rendering. Us accountants want correct reporting but we also like it to be ascetically pleasing. This need can add a level of complexity with the underlying data. I’m looking forward to the follow-up blogs and would suggest addressing the issue of a quality rendering versus the quality of the underlying data.
Charlie – you’re quite right that one of the things that causes confusion is the fact that the preferred rendering of the a particular figure is often different to the correct value for tagging in XBRL.
This is certainly something that I’ll be addressing in one of the follow-up posts. Getting a quality rendering isn’t at odds with the quality of the underlying data. On the contrary, getting the underlying data right is a necessary pre-requisite for getting a quality rendering.
This blog makes sense. I also think the issue stems from rendering. Us accountants want correct reporting but we also like it to be ascetically pleasing. This need can add a level of complexity with the underlying data. I’m looking forward to the follow-up blogs and would suggest addressing the issue of a quality rendering versus the quality of the underlying data.
Charlie – you’re quite right that one of the things that causes confusion is the fact that the preferred rendering of the a particular figure is often different to the correct value for tagging in XBRL.
This is certainly something that I’ll be addressing in one of the follow-up posts. Getting a quality rendering isn’t at odds with the quality of the underlying data. On the contrary, getting the underlying data right is a necessary pre-requisite for getting a quality rendering.
This blog makes sense. I also think the issue stems from rendering. Us accountants want correct reporting but we also like it to be ascetically pleasing. This need can add a level of complexity with the underlying data. I’m looking forward to the follow-up blogs and would suggest addressing the issue of a quality rendering versus the quality of the underlying data.
Charlie – you’re quite right that one of the things that causes confusion is the fact that the preferred rendering of the a particular figure is often different to the correct value for tagging in XBRL.
This is certainly something that I’ll be addressing in one of the follow-up posts. Getting a quality rendering isn’t at odds with the quality of the underlying data. On the contrary, getting the underlying data right is a necessary pre-requisite for getting a quality rendering.
Paul, the real reason for signage problem is that years ago there was an hours long knock-down drag out fight on the XBRL US domain committee between the pragmatist/users and semantic “visionaries” about what sign to put on items and the pragmatists lost the vote.
The real problem is the cash flow statement, as there is NO reason whatsoever why you would ever not match the sign in the printed cash flow statement because it is a simple positive cash in, negative cash out. That not doing this would cause a large number of filing errors was obvious to see, but the semantic visionary techno-countants wanted to make the sign label-based and they won on this (and most other issues.)
Now we are paying for it.
– Eric Linder
Eric,
I think you’re confusing two issues: how the sign convention is captured, and what sign convention is used.
It would be quite possible to adopt my common sense approach of giving concepts meaningful names, whilst adopting the property that a positive sign corresponds to cash in. For example, you’d have concepts such as “Decrease (Increase) in Accounts Receivable”.
Personally, I don’t think that defining concepts to match the sign convention used on the cash flow statement would help the problem (I guess that makes me a “semantic visionary techno-countant”), but it’s certainly not at odds with what I describe here.
In general, matching the sign on the printed statement is not possible as an approach, as different printed statements follow different sign conventions (I’ll cover this in my next post).
Paul
Paul, the real reason for signage problem is that years ago there was an hours long knock-down drag out fight on the XBRL US domain committee between the pragmatist/users and semantic “visionaries” about what sign to put on items and the pragmatists lost the vote.
The real problem is the cash flow statement, as there is NO reason whatsoever why you would ever not match the sign in the printed cash flow statement because it is a simple positive cash in, negative cash out. That not doing this would cause a large number of filing errors was obvious to see, but the semantic visionary techno-countants wanted to make the sign label-based and they won on this (and most other issues.)
Now we are paying for it.
– Eric Linder
Eric,
I think you’re confusing two issues: how the sign convention is captured, and what sign convention is used.
It would be quite possible to adopt my common sense approach of giving concepts meaningful names, whilst adopting the property that a positive sign corresponds to cash in. For example, you’d have concepts such as “Decrease (Increase) in Accounts Receivable”.
Personally, I don’t think that defining concepts to match the sign convention used on the cash flow statement would help the problem (I guess that makes me a “semantic visionary techno-countant”), but it’s certainly not at odds with what I describe here.
In general, matching the sign on the printed statement is not possible as an approach, as different printed statements follow different sign conventions (I’ll cover this in my next post).
Paul
Paul, the real reason for signage problem is that years ago there was an hours long knock-down drag out fight on the XBRL US domain committee between the pragmatist/users and semantic “visionaries” about what sign to put on items and the pragmatists lost the vote.
The real problem is the cash flow statement, as there is NO reason whatsoever why you would ever not match the sign in the printed cash flow statement because it is a simple positive cash in, negative cash out. That not doing this would cause a large number of filing errors was obvious to see, but the semantic visionary techno-countants wanted to make the sign label-based and they won on this (and most other issues.)
Now we are paying for it.
– Eric Linder
Eric,
I think you’re confusing two issues: how the sign convention is captured, and what sign convention is used.
It would be quite possible to adopt my common sense approach of giving concepts meaningful names, whilst adopting the property that a positive sign corresponds to cash in. For example, you’d have concepts such as “Decrease (Increase) in Accounts Receivable”.
Personally, I don’t think that defining concepts to match the sign convention used on the cash flow statement would help the problem (I guess that makes me a “semantic visionary techno-countant”), but it’s certainly not at odds with what I describe here.
In general, matching the sign on the printed statement is not possible as an approach, as different printed statements follow different sign conventions (I’ll cover this in my next post).
Paul
I like your “What is the …?” approach to determine the sign of a number complemented by the approach where the question is not applicable. It has always been yours and others’ idea. People have to ask the question using the standard label though or the element name, not a label from a report that may not be standard.
I may disagree with what you have to say about the debit/credit attribute though; at least if you think it has no useful purpose. I think it has a very important use. I have always wanted the power it provides, if it could be implemented consistently. I have always wanted to be able to determine if an amount is a debit or a credit, but for a while I argued against the use of a balance attribute as an attribute of a concept when I thought its application to concepts was arbitrary (and I was only thinking about data entry). I have seen that its assignment is not arbitrary and I am again all for the balance (debit/credit) attribute now, because it enables us to determine how a concept, rather its amount, contributes to the accounting equation or the change-in-cash equation. I have seen the unreliable records of businesses who could not respect the double-entry equation. I have argued before that the explicit attribute itself could be done away with (in XBRL), but that debits and credits would still be implicit within the relationships of concepts, but now I say it should be explicit where appropriate and having the balance attribute explicit makes the automated consumption of data easier (by being able to more easily (1) do transformations e.g. like the one I did converting accrual figures from multiple-period trial balances into of cash flow figures, (2) convert debits and credits into positive and negative numbers for comparison by addition, (3) aid set-based processing of numerical concepts, (4) compare similar concepts like LossOnSale and GainLossOnSale). I am only speculating here; I have not done any of these things (not yet with XBRL anyway), and you may be able to prove me wrong about the need for a balance attribute in XBRL.
Even if the balance attribute did not assist automated processing of data, its presence probably helps define a concept for a human (when assigned correctly of course) to such an extent its use is desired. It is all very well saying a concept (of which one is quite unfamiliar) takes a positive value (easy for an instance creator), but (without looking at calculation relationships or formulae) how does it fit into the accounting equation (a consumer of the instance might ask)?
The good thing is that the balance attribute when assigned correctly (and there is a correct non-arbitrary way to do it given our “normally positive” constraint and a consistency constraint) becomes irrelevant for choosing the sign of an amount to be entered against an XBRL concept. We can have our cake (not have to consider whether an amount or a concept is a debit or a credit when entering an amount against an XBRL concept) and eat it too (be able to know if an amount is a debit or credit when using XBRL facts).
The balance attribute though appears to be very relevant for interpreting amounts entered against concepts. It provides meaning that would have to be calculated tortuously if the balance attribute were not employed. Its use is a front loading of analysis into the concept carried with the concept. Assigning balance attributes makes creating taxonomies harder to the extent the authors have to know what they are doing, but it does not make using taxonomies any harder: it does not make entering data any harder (because it can be ignored when taxonomies are created correctly) and in fact it makes using data easier.
Somebody assigned the balance attribute to the LossContingencyAccrualCarryingValueProvision element incorrectly (and broke the taxonomy), but that is human error in application of the XBRL design (rather, an error in basic accounting), not an error in the XBRL design itself.
But getting back to your current blog; I am pleased to say I agree with what you say, and your expression of the rule appears to be an improvement on my “normally positive unless ‘abnormal'” expression of the rule, although both expressions are equivalent if you accept I was trying to say what you actually do say.
Brendan, I agree that this is the same as your “normally positive” approach, although I think that word “normally” implies a statistical dependency that isn’t there i.e. that it should be positive more often than not.
What I’ve been trying to get across is that there isn’t some great mystery to the way that signs work in XBRL. Provided that you give concepts meaningful names, and that that meaning includes the sign convention, then the correct sign to use is easy to determine.
Unfortunately, I think that the existence of the balance attribute, and also the multiplicity of label types, have distracted people from what should have been an obvious and fundamental requirement: that concepts should have meaningful and unambiguous names.
I’ve saved my thoughts on whether the balance attribute actually has any use for a future post, but I must say that I’m skeptical about the extent to which it can help automate the consumption of XBRL. If an application doesn’t know the meaning of a given concept, then I don’t see how knowing its sign convention will help.
Paul
I like your “What is the …?” approach to determine the sign of a number complemented by the approach where the question is not applicable. It has always been yours and others’ idea. People have to ask the question using the standard label though or the element name, not a label from a report that may not be standard.
I may disagree with what you have to say about the debit/credit attribute though; at least if you think it has no useful purpose. I think it has a very important use. I have always wanted the power it provides, if it could be implemented consistently. I have always wanted to be able to determine if an amount is a debit or a credit, but for a while I argued against the use of a balance attribute as an attribute of a concept when I thought its application to concepts was arbitrary (and I was only thinking about data entry). I have seen that its assignment is not arbitrary and I am again all for the balance (debit/credit) attribute now, because it enables us to determine how a concept, rather its amount, contributes to the accounting equation or the change-in-cash equation. I have seen the unreliable records of businesses who could not respect the double-entry equation. I have argued before that the explicit attribute itself could be done away with (in XBRL), but that debits and credits would still be implicit within the relationships of concepts, but now I say it should be explicit where appropriate and having the balance attribute explicit makes the automated consumption of data easier (by being able to more easily (1) do transformations e.g. like the one I did converting accrual figures from multiple-period trial balances into of cash flow figures, (2) convert debits and credits into positive and negative numbers for comparison by addition, (3) aid set-based processing of numerical concepts, (4) compare similar concepts like LossOnSale and GainLossOnSale). I am only speculating here; I have not done any of these things (not yet with XBRL anyway), and you may be able to prove me wrong about the need for a balance attribute in XBRL.
Even if the balance attribute did not assist automated processing of data, its presence probably helps define a concept for a human (when assigned correctly of course) to such an extent its use is desired. It is all very well saying a concept (of which one is quite unfamiliar) takes a positive value (easy for an instance creator), but (without looking at calculation relationships or formulae) how does it fit into the accounting equation (a consumer of the instance might ask)?
The good thing is that the balance attribute when assigned correctly (and there is a correct non-arbitrary way to do it given our “normally positive” constraint and a consistency constraint) becomes irrelevant for choosing the sign of an amount to be entered against an XBRL concept. We can have our cake (not have to consider whether an amount or a concept is a debit or a credit when entering an amount against an XBRL concept) and eat it too (be able to know if an amount is a debit or credit when using XBRL facts).
The balance attribute though appears to be very relevant for interpreting amounts entered against concepts. It provides meaning that would have to be calculated tortuously if the balance attribute were not employed. Its use is a front loading of analysis into the concept carried with the concept. Assigning balance attributes makes creating taxonomies harder to the extent the authors have to know what they are doing, but it does not make using taxonomies any harder: it does not make entering data any harder (because it can be ignored when taxonomies are created correctly) and in fact it makes using data easier.
Somebody assigned the balance attribute to the LossContingencyAccrualCarryingValueProvision element incorrectly (and broke the taxonomy), but that is human error in application of the XBRL design (rather, an error in basic accounting), not an error in the XBRL design itself.
But getting back to your current blog; I am pleased to say I agree with what you say, and your expression of the rule appears to be an improvement on my “normally positive unless ‘abnormal'” expression of the rule, although both expressions are equivalent if you accept I was trying to say what you actually do say.
Brendan, I agree that this is the same as your “normally positive” approach, although I think that word “normally” implies a statistical dependency that isn’t there i.e. that it should be positive more often than not.
What I’ve been trying to get across is that there isn’t some great mystery to the way that signs work in XBRL. Provided that you give concepts meaningful names, and that that meaning includes the sign convention, then the correct sign to use is easy to determine.
Unfortunately, I think that the existence of the balance attribute, and also the multiplicity of label types, have distracted people from what should have been an obvious and fundamental requirement: that concepts should have meaningful and unambiguous names.
I’ve saved my thoughts on whether the balance attribute actually has any use for a future post, but I must say that I’m skeptical about the extent to which it can help automate the consumption of XBRL. If an application doesn’t know the meaning of a given concept, then I don’t see how knowing its sign convention will help.
Paul
I like your “What is the …?” approach to determine the sign of a number complemented by the approach where the question is not applicable. It has always been yours and others’ idea. People have to ask the question using the standard label though or the element name, not a label from a report that may not be standard.
I may disagree with what you have to say about the debit/credit attribute though; at least if you think it has no useful purpose. I think it has a very important use. I have always wanted the power it provides, if it could be implemented consistently. I have always wanted to be able to determine if an amount is a debit or a credit, but for a while I argued against the use of a balance attribute as an attribute of a concept when I thought its application to concepts was arbitrary (and I was only thinking about data entry). I have seen that its assignment is not arbitrary and I am again all for the balance (debit/credit) attribute now, because it enables us to determine how a concept, rather its amount, contributes to the accounting equation or the change-in-cash equation. I have seen the unreliable records of businesses who could not respect the double-entry equation. I have argued before that the explicit attribute itself could be done away with (in XBRL), but that debits and credits would still be implicit within the relationships of concepts, but now I say it should be explicit where appropriate and having the balance attribute explicit makes the automated consumption of data easier (by being able to more easily (1) do transformations e.g. like the one I did converting accrual figures from multiple-period trial balances into of cash flow figures, (2) convert debits and credits into positive and negative numbers for comparison by addition, (3) aid set-based processing of numerical concepts, (4) compare similar concepts like LossOnSale and GainLossOnSale). I am only speculating here; I have not done any of these things (not yet with XBRL anyway), and you may be able to prove me wrong about the need for a balance attribute in XBRL.
Even if the balance attribute did not assist automated processing of data, its presence probably helps define a concept for a human (when assigned correctly of course) to such an extent its use is desired. It is all very well saying a concept (of which one is quite unfamiliar) takes a positive value (easy for an instance creator), but (without looking at calculation relationships or formulae) how does it fit into the accounting equation (a consumer of the instance might ask)?
The good thing is that the balance attribute when assigned correctly (and there is a correct non-arbitrary way to do it given our “normally positive” constraint and a consistency constraint) becomes irrelevant for choosing the sign of an amount to be entered against an XBRL concept. We can have our cake (not have to consider whether an amount or a concept is a debit or a credit when entering an amount against an XBRL concept) and eat it too (be able to know if an amount is a debit or credit when using XBRL facts).
The balance attribute though appears to be very relevant for interpreting amounts entered against concepts. It provides meaning that would have to be calculated tortuously if the balance attribute were not employed. Its use is a front loading of analysis into the concept carried with the concept. Assigning balance attributes makes creating taxonomies harder to the extent the authors have to know what they are doing, but it does not make using taxonomies any harder: it does not make entering data any harder (because it can be ignored when taxonomies are created correctly) and in fact it makes using data easier.
Somebody assigned the balance attribute to the LossContingencyAccrualCarryingValueProvision element incorrectly (and broke the taxonomy), but that is human error in application of the XBRL design (rather, an error in basic accounting), not an error in the XBRL design itself.
But getting back to your current blog; I am pleased to say I agree with what you say, and your expression of the rule appears to be an improvement on my “normally positive unless ‘abnormal'” expression of the rule, although both expressions are equivalent if you accept I was trying to say what you actually do say.
Brendan, I agree that this is the same as your “normally positive” approach, although I think that word “normally” implies a statistical dependency that isn’t there i.e. that it should be positive more often than not.
What I’ve been trying to get across is that there isn’t some great mystery to the way that signs work in XBRL. Provided that you give concepts meaningful names, and that that meaning includes the sign convention, then the correct sign to use is easy to determine.
Unfortunately, I think that the existence of the balance attribute, and also the multiplicity of label types, have distracted people from what should have been an obvious and fundamental requirement: that concepts should have meaningful and unambiguous names.
I’ve saved my thoughts on whether the balance attribute actually has any use for a future post, but I must say that I’m skeptical about the extent to which it can help automate the consumption of XBRL. If an application doesn’t know the meaning of a given concept, then I don’t see how knowing its sign convention will help.
Paul
Like we all agree, it is very important to known how to get the signs right in an XBRL instance. How easy or difficult this seems to be depends on the number of truths in the reporting chain. We have the issuer and the receiver and then (what makes XBRL tick?) the taxonomy. Taxonomy design is decisive for how the signs are understood. By simply stating in the description of the concept how the sign is interpreted by the receiver the designer helps translating between multiple truths.
When the designer just takes a P&L bill and BS and finishes the taxonomy before nightfall then we don’t translate and end up with three thruths but no communication.
Like we all agree, it is very important to known how to get the signs right in an XBRL instance. How easy or difficult this seems to be depends on the number of truths in the reporting chain. We have the issuer and the receiver and then (what makes XBRL tick?) the taxonomy. Taxonomy design is decisive for how the signs are understood. By simply stating in the description of the concept how the sign is interpreted by the receiver the designer helps translating between multiple truths.
When the designer just takes a P&L bill and BS and finishes the taxonomy before nightfall then we don’t translate and end up with three thruths but no communication.
Like we all agree, it is very important to known how to get the signs right in an XBRL instance. How easy or difficult this seems to be depends on the number of truths in the reporting chain. We have the issuer and the receiver and then (what makes XBRL tick?) the taxonomy. Taxonomy design is decisive for how the signs are understood. By simply stating in the description of the concept how the sign is interpreted by the receiver the designer helps translating between multiple truths.
When the designer just takes a P&L bill and BS and finishes the taxonomy before nightfall then we don’t translate and end up with three thruths but no communication.