IATI Consultations Archive

Live discussions and consultations can be found at discuss.iatistandard.org.

Add 'Incoming Commitment' to the Transaction Type codelist

The proposal is to add 'Incoming commitment' as a transaction type to the 1.x and 2.01 codelists. This is a crucial element for full 'chain transparency'.

In the current 2.01 standard the 'Incoming commitment' is missing in the Transaction Type codelist. In the Netherlands there are a lot of organisations which both have incoming commitments and outgoing commitments. Since the current standard only supports the 'Commitment' as a transaction type, it is impossible to distinguish between incoming and outgoing commitments. Without this element full chain transparency is therefore not possible.

This change should span both 1.0x and 2.01 since it is a crucial element for chain transparency for all publishers. I suggest to use ‘IC’ as a code for the 1.x codelist and 11 (numeric) for  2.x codelist.

This proposal has been discussed and agreed with Bill Anderson during the 2015 TAG in Ottawa for implementation in the 2.02 decimal upgrade before 1 December 2015.

Have more questions? Submit a request

13 Comments

  • 0
    Avatar
    Rolf Kleef

    I think it is perfectly possible to declare an incoming commitment already, by using the provider-org and receiver-org elements? I'd rather limit the number of codes to keep it manageable (for instance: 3-disbursement, 4-expenditure and 7-reimbursement leave room for differences in interpretation and implementation anyway).

    We shouldn't change previous versions of the standard, or introduce a third-level digit to separate codelist updates from other (structural/semantic) updates of the standard. (That also depends on the life cycle/life span for versions of the standard, a separate discussion.)

  • 0
    Avatar
    Herman van Loon

    Rolf,

    using the same reasoning we could depreciate the Incoming Funds transaction. Nonetheless we have the Incoming Funds transaction and it is widely used. Therefore we should be consistent in the use of the transaction types, and also have the Incoming Commitment as a mirror image of the Incoming Funds transaction. Otherwise users of IATI data will have to use different logic for identifying Incoming Funds and Incoming Commitments. This will make the usage of the IATI data more complex than necessary.

    Another compelling reason to add this transaction type is that the receiver-org and provider-org elments are not mandatory. This means that we can not always derive the direction of the flow of a commitment.

    Regarding the IATI versions to aply this change to: I agree that it is not very neat to also introduce this new transaction type in pre 2.01 versions. Since this is a backward compatible change, I do not thing there is any harm in it though.

  • 0
    Avatar
    Rolf Kleef

    Hi Herman, I actually deleted that suggestion of removing the incoming funds code before I posted my comment :-)

    I think we should indeed strive for more consistency:

    • Either we have incoming funds, incoming commitments, but then we don't need "receiver-org" in those, nor do we need "provider-org" in disbursements, expenses, and such.
    • Or we have disbursements and commitments, and the direction follows from having either the "receiver-org" or the "provider-org" (but again, not both at the same time).

    Personally, I'd rather reduce code lists, but if separate codes are preferred, lets then make provider/receiver fields mandatory in the appropriate places too.

  • 0
    Avatar
    IATI Tech Team

    This item has been moved to the '2.02 Decimal Upgrade Proposals' forum for inclusion the upcoming decimal upgrade.

  • 0
    Avatar
    Bill Anderson

    Herman I'm not sure I was in a position to do anything more than agree with you in a personal capacity (which I do) but Steven is right that we cannot make an embedded codelist (one which is defined by our own standard) applicable to earlier versions of the standard.

    Rolf' while your suggestions are equally valid, we can't add mandatory fields in a decimal and given the important work going on in the Netherlands I am politically inclined to support Herman's proposal.

    We currently already have ambiguity in the use of Commitments. I myself am guilty (in the past) of advising  NGOs to use "Commitment"  to mean an "Incoming Commitment" without necessarily specifying a provider-org. I think adding "Incoming Commitment" is a pragmatic best-bet. We will need to write some clear guidance so that publishers and users alike can get this to work.

  • 0
    Avatar
    Herman van Loon
    Hi Bill, I understand that you are reluctant to change the earlier versions of the standard. Having the incoming commitment in 2.02 only will help a lot to represent this flow unambiguously.
  • 0
    Avatar
    IATI Tech Team

    This proposal has been discussed amongst the IATI Technical Team following the end of the initial suggestion phase of the v2.02 upgrade.

    The IATI Technical Team supports the principal of this proposal as a non-mandatory addition to version 2.02 only.  Further work is needed to clarify the required changes to the schema in order to implement this proposal, with further discussion encouraged in the meantime.

  • 0
    Avatar
    John Adams

    This might be interesting particularly in humanitarian work, as commitments are often established early in humanitarian situations but funding does not flow for several weeks/months.

  • 0
    Avatar
    IATI Tech Team

    Please see below for the technical implementation that is suggested in the Version 2.02 - Formal Proposal:

    Codelist addition: Transaction Type

    • Add code:

      • Code: 11

      • Name: Incoming Commitment

    Description: 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.

  • 0
    Avatar
    IATI Tech Team

    This proposal has been added as a GitHub issue, for inclusion in the version 2.02 development branch of the appropriate code repository: https://github.com/IATI/IATI-Codelists/issues/88

  • 0
    Avatar
    Yohanna Loucheur

    I would like to seek clarification on this change:

    - There is no proposal to change the definition of "commitment", correct?  This remains "a firm, written obligation....to provide a specified amount of funds..."?  Since the definition of commitment seems to be quite unclear in the Activity Budgets discussion, I want to double-check that we are clear on the definition here and that we won't end up with an attribute for "tentative commitments" at some point.

    - I want to make sure I understand how the codelist will work.  If it's an incoming commitment we would code it 11, while for an outgoing commitment we continue using code 2 "Commitment"?  Would it be clearer to rename 2 "Outgoing Commitment", or would that be too much trouble for what it's worth?

  • 0
    Avatar
    Herman van Loon

    Yohanna, the definition of "commitment" will NOT change. It remains "a firm, written obligation....to provide a specified amount of funds...".  

  • 0
    Avatar
    IATI Tech Team

    This proposal has now been incorporated into a version 2.02 code repositories (see the above GitHub issue link for technical details). The relevant page on a development version of the 2.02 reference and documentation site is available to view here.

    We welcome scrutiny on the implementation of this proposal and encourage the community to feedback and suggest solutions for any errors, omissions and problems. This should be done before Monday 7 December, when the process will commence to release version 2.02 as a live version of the IATI Standard. More information on the inspection phase is available here.

Please sign in to leave a comment.