Outgoing Commitment - conflicting description & use?

Standard Management 2.03 Decimal Upgrade Proposals
#1

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 @pelleaardema @rolfkleef

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:

The total budget for an activity should be reported as a commitment in the transaction element.

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

d-portal (9)

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 @YohannaLoucheur @SJohns @bill_anderson @JohnAdams @rolfkleef 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

Proposal: update of budget element description text (in activity standard)
[Implemented as bug fix] ActivityStatus codes - mixup of descriptions for codes 3 & 4?
#2

Hi Steven,

I think the “incoming commitment” (transactionType 11) came into the standard when we were trying to accommodate requirements for the FTS/Humanitarian reporting. @bibhusan or @ximboden can chime in…

The term “Commitment” should remain as commitment (transactionType 2). This is an outgoing commitment to allow for comparisons with Disbursements and Expenditures, as you point out.

-MA

#3

Hi Steven,
Yes, the defintions look very similar. I would suggest to make both the transaction character and the perspective more explicit:

Outgoing commitment
A firm, written obligation from a donor or provider to a recipient to provide a specified amount of funds, under particular terms and conditions, for specific purposes, for the benefit of the recipient, reported by the donor or provider.

Incoming commitment
A firm, written obligation from a donor or provider to a recipient to provide a specified amount of funds, under particular terms and conditions, reported by the recipient.

Concerning the term commitment being used with regard to the activity budget: I think that is confusing and should be avoided, for the following reasons:

  • it conflicts with the OECD/DAC definition. The DAC regards both disbursements and commitments as flows. Not as an allocation of funds on the activity budget. So in fact both disbursements and commitments represent the transaction between a donor and a recipient.

  • ‘commiting’ an amount to a activity budget is an internal decision of an organisation. It is a means to improve financial planning, but has no binding or legal status. I think is is much more clear to use the term ‘commitment’ only for firm and written obligations between donors and recipients. A commitment is in this sense an externally focused term.

NB: if you want to represent you financial activity planning in IATI, you can use the ‘planned disbursements’ elements to indicate how you want to spend your budget in time.

#4

Don’t want to take this thread off course but must disagree with you @Herman on budgets. I don’t know where the idea of

‘commiting’ an amount to a activity budget

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.

#5

Thanks @makerman @Herman @bill_anderson

Can I share this guidance (for NGO publishers) from Bond:

Using IATI A guide for NGOs Bond

#6

Honestly I disagree with this guidance. A budget is not a financial liability legally speaking. A commitment usually is.

1 Like
#7

… but we have this guidance baked into the actual schema, dont we?

#8

Sorry, just to clarify. I agree with the response to the question for the most part. But based on the wording of the question, budgets and commitments are two separate things.

2 Likes
#9

To be honest I am not sure. But, if you look at us as an organization, there is a budget which may or may not be disbursed over the lifetime of a project. A commitment is an amount that we are liable against. With the exception of extenuating circumstances or reprogramming which would involve a new contract, we should pay out.

1 Like
#10

Yes. Since v2.01. Here’s the relevant commit; here’s the relevant issue (which links to a spreadsheet. That’s where the traceability ends. But perhaps someone else can find the genesis.)

Incidentally, being able to trace these things is super useful for newcomers like me. It would be awesome if version upgrades could link from commit to issue to proposal.

#11

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:

01

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?

1 Like
#12

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.

@stevieflow 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).

#13

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.

#14

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

#15

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.

#16

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?

#17

Going back to the three points I observed at the top of this post - in relation to looking at changes via 2.03:

  1. Different names, very similar descriptions
  2. Continued potential for different uses for Outgoing Commitment?
  3. Impact on rules and norms established for Commitment

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:

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?

#18

Hi Steven,
I fail to see that changing the name from Commitment to ‘Outgoing committent’ adds to the confusion. This name change only highlights the perspective: is the commitment transaction from the perspective of the donor, or is it from the recipient.

If we accept in real use cases, that the total amount commited may differ from the total budget amount, we need to solve this. I am not convinced that this would be a breaking change, but maybe I am missing something here. We could just relax the rule that total amount commited = total budget? Anyone who still wishes to keep these amount equal in their publications, are free to do so.

I agree with Yohanna that the total budget can be derived from the budgets by period. If I am not mistaken there was a heated discussion during the TAG to add the total budget amount as a seperate element though.

1 Like
#19

@Herman - 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!

#20

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.

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.