With 2.03 , there’s a proposal to change the name of the transaction code 2 from Commitment to Outgoing Commitment.
There was a long thread on this - but it seems to be now closed, hence this post.
In 2.02 a new transaction type “Incoming Commitment” was added to the standard.
Therefore, my understanding is that this change in 2.03 is to help clarify the differences between the two types. I don’t think we got to consensus on the original post - so would appreciate any insight Herman van Loon Pelle Aardema Rolf Kleef
On taking a look at 2.03 developments, I noticed a few things:
1. Different names, very similar descriptions
The description text for these two transaction types are still very very similar:
Outgoing Commitment:
A firm, written obligation from a donor or provider to provide a specified amount of funds, under particular terms and conditions, for specific purposes, for the benefit of the recipient.
Incoming Commitment:
A firm, written obligation from a donor or provider to provide a specified amount of funds, under particular terms and conditions, reported by a recipient for this activity.
There was some discussion about revising these descriptions, but this didn’t make it to the TAG standards day, or any further it seems (despite the GitHub issue being closed)
I do think people should take a look. With the renaming to “Outgoing”, the text inclusion of “from a donor” seems confusing. What do others think? Can we afford subtle differences in meaning?
2. Continued potential for different uses for Outgoing Commitment?
Secondly, here’s a point from the original thread, regarding two potential uses of the Commitment transaction type, amongst publishers:
We're committing this value to this activity aka the total-budget
We're committing this value to this partner
It seems that updating the name partly helps, but the lack of development of the description text means we are not fully addressing this. It’s very likely that we will leave people more confused, I would argue…
3. Impact on rules and norms established for Commitment
Finally, we should note where there are some rules and norms around data uses in place that seem to rely on the idea of a Commitment being something that applies to the whole project:
- In the budget element we have:
The total budget for an activity should be reported as a commitment in the transaction element.
- The IATI dashboard, for the forward looking calculations declares:
activities are excluded from forward looking calculations if they contain commitment transactions and 90% of the total commitment value has already been disbursed or expended in the corrsponding year or previously.
(NB: I noted a splling mistake in the dashboard via checking this)
- I believe d-portal uses Commitments to create visuals such as this, by comparing with Disbursements and Expenditures
Therefore, if the meaning of a Commitment now shifts to being something outgoing from one activity to another, do we need to consider the impact we might be having elsewhere?
Also tagging Yohanna Loucheur SJohns Bill Anderson John Adams Rolf Kleef as they commented on the original thread - but thoughts from all others welcome!
And, if you make it this far : I give you The Commitments
Herman van Loon thanks for the clarification. One thing: it might prove difficult to completely align the DAC and IATI definitions, precisely because the former is very donor-centric language.
Don’t want to take this thread off course but must disagree with you Herman van Loon on budgets. I don’t know where the idea of
comes from. It’s not in the standard.
For predictability it is helpful for recipients to understand how the total commitment for an activity (i.e. the sum of commitment transactions) is likely to be allocated over the lifetime of the activity. This is the only purpose of the budget element.
Yes Bill, you are completely right. I was referring back to point 2 of Steven’s original text. It suggests that there is something like committing to the total project budget. You always commit an amount to another recipient (external).
Wat is interesting though is the difference between the total budget of an activity and the total amount commited: this difference represents to amount still to be programmed. In other words the total amount for wich the donor expects to make new commitments in the future. Because this amount can easily be derived, it should not be part of the standard.
Steven Flower since this difference represents very valuable information, I think the guidance in the standard about commitments is wrong: during activity implementation the total amount committed may differ from the total budget. Only when the activity is finished, the total amount committed will be equal to the total project budget (assuming that the implementation went according to plan).
You are probably right. This definition is i.m.o. wrong though: at the start of an activity, the budget may be far greater than the amount commited, simply because not all contracts are made yet with all partners.
But - this has been in the standard since day one? I think that is my concern - we seem to be changing what a Commitment is/how it works – yet have long-standing assumptions about it elsewhere in the standard
Yes, that is a challenge. Notheless I think we should reconsider the current definition in the standard because the current definition assumes that the total amount committed is by defintion equal to the total budget amount. In fact IATI is implicitly redefining the meaning of the term ‘budget’. It assigns a different meaning to the word than the rest of the financial world. This is i.m.o. unacceptable for an international standard since it introduces a lot of confusion, and therefore is not helpful for producing quality data.
Agree with Herman.
“Commitment” has a clear definition as a transaction that nobody seems to question here. The problem does seem to be the use of the word “budget” in the current definition; it does not allow for cases where the full budget is not committed from the beginning.
I think we’re getting closer to consensus on the need for a “total budget” element. Although this total budget could be derived by adding up the amounts published in the existing budget element, could it not?
Going back to the three points I observed at the top of this post - in relation to looking at changes via 2.03:
I think the thread has clarified and illustrated around this, but add a fourth:
4. The long-stated use of Commitment transaction for the total budget is "disputed"
If this is the case, then I can’t see how we can tweak at the edges around changing the name of the Commitment transaction, as this doesn’t address any of the points. As I see it, we will have further “confusion”, as guidance, definitions and implementation are different:
Herman:Equally, we should be minded that 2.03 (as any decimal) can’t be a breaking change. Surely redefining how a Very Important transaction code is used, is?
Going back to the three points I observed at the top of this post - in relation to looking at changes via 2.03:
I think the thread has clarified and illustrated around this, but add a fourth:
4. The long-stated use of Commitment transaction for the total budget is "disputed"
If this is the case, then I can’t see how we can tweak at the edges around changing the name of the Commitment transaction, as this doesn’t address any of the points. As I see it, we will have further “confusion”, as guidance, definitions and implementation are different:
Herman:Equally, we should be minded that 2.03 (as any decimal) can’t be a breaking change. Surely redefining how a Very Important transaction code is used, is?
Yes, absolutely. Let us please not introduce a lot of confusion by introducing homonyms. Escpecially not for such a fundamental concept as the commitment. The DAC has more than 50 years of history with using commitment transactions.
stevieflow:It does not matter if you are a donor, multilateral, NGO, etc.Commitment transactions take place on all levels in the network. The commitment transaction is universal: it represents any legal binding agreement between two parties with financial an financial obligation from one partner to the other. Of course the DAC is donor centric, but the same definition applies to other levels as well.
Maybe in the schema - but this implementation guidance around the Commitment transaction has been in the standard since the very first version. 1.01 says:
Herman:This might be true - but I’m just trying to point to the fact (I think!) that this seems to be have been a common part of the standard since forever. Have I misunderstood?
Herman van Loon - I just wanted to check this. The DAC have published definitions for Commitments and Disbursements.
To be clear: are you thinking that the IATI & DAC definitions need be aligned?
For reference, the TransactionType IATI codelist is embedded (controlled by IATI) and there’s no reference or link to these DAC definitions.
Additionally, is it reasonable for us to recognise that many IATI publishers are not donors? We need to be clear if it seems that one transaction type is for a very particular use case.
Sorry - these are extra questions I got from our discussion!