Hierarchies - general guidance

Standard Management 2.03 Decimal Upgrade Proposals
,
#1

This proposal is part of the 2.03 upgrade process, please comment by replying below.

Standard
Activity

**Schema Object** None

**Type of Change** Addition of guidance

**Issue** Publishers and users require clearer guidance on how hierarchical business models are managed.

**Proposal** Add a section on use of hierarchies to the standard guidance on [Establishing Publishing Policies](http://iatistandard.org/202/guidance/how-to-publish/establish-publishing-policies/). This should include:

  • The scope of use must not extend beyond the reporting of the activities of a single organisation.
  • All types of transactions may be reported at any level provided that:
    • There is no double counting across the activities of a single organisation.
    • Transactions should not report disbursements within a hierarchical group. The flow of money down a hierarchical chain is implicitly assumed
    • Incoming Funds can be present at any level but must be reported only once and at only one level
  • Budgets & results can be defined at any number of levels
  • All mandatory fields should be present at all levels.
  • Hierarchical groups should be treated as a single activity for the purpose of publisher statistics assessments
**Standards Day** Proposals were accepted. There was a wider discussion in the room around different use of hierarchy, described as hierarchy of relationship as well as hierarchy of funding flows. However, there was confusion around the definition being used for double counting and how that relates to reporting hierarchies. It was clarified that as long as the flow of resources is reported correctly, there will be no double counting. However, a number of examples were given from organisations highlighting that that there is inconsistency in how they use hierarchies and their understanding of double counting. The issue of treating hierarchical groups as single activities for publisher statistics assessments was not discussed.

**Links** Previous discussions - https://discuss.codeforiati.org/t/tech-paper-hierarchies/539/21

#2

Some questions:
◦There is no double counting across the activities of a single organisation.

Does this mean that it is allowed to have an outgoing fund trx of X from hierarchy level 1 if there is an incoming fund trx X at hierarchy level 2?

◦Transactions should not report disbursements within a hierarchical group.
The flow of money down a hierarchical chain is implicitly assumed.

As mentioned in the previous discussion: it can be quite interesting to see what has been disbursed or committed from the program level (hierarchy level 1) to the activity level (hierarchy level 2) when you want to asses how far the execution of a program is.

◦Incoming Funds can be present at any level but must be reported only once and at only one level

This is far to restrictive. In practice incoming funds and commitments can be both at the program level (hierarchy level 1) and the activity level (hierarchy level 2). Eg when co-financing a specific activity under a program.

In summary: the scope limitation is fine. The other restrictions seem to restrict valid real word use cases being modelled in IATI. Avoiding double counting is i.m.o. something which needs to be done at the moment of usage of IATI data, not at the moment of the production of IATI data.

From the procedural pint of view: limiting the scope of hierarchies to 1 organization, is a breaking change. Therefore shouldn’t this proposal be part of the next decimal upgrade?

#3

I fail to comprehend the concept of ‘disbursement’ from programme to component, within one and the same reporting organisation. If the aim is to disclose how far the execution of a programme is, I would recommend to combine info on budgets (on both levels) with info on real disbursements (and expenditures) - i.e. outgoing flows from level 2.

As a parallel, from DAC-statistics: You don’t Count any ODA if you are just shoveling funds around between your own budgetlines or bank-accounts. So which type of aid were you considering to apply for such internal reclassifications?

#4

I can now see why we have confusion. The proposal as it stands suggests that intra-organisational disbursements (with matching incoming funds) can be made between a publisher’s activities provided that they are not part of an hierarchical group.

I suggest

  • We qualify the first proposition: There is no double counting across the activities of a single organisation. This excludes disbursements between activities which are matched by traceable balancing incoming funds transactions. (Traceable means that the incoming fund transaction specifies the provider-activity-id)
  • We remove the second proposition. (i.e. the first proposition refers to all of a publisher’s activities)

@OJ_ are you happy that making the balancing incoming funds explicit deals with shoveling funds around transparently?

#5
  • The intention here was to ensure that funds coming in from external sources are only reported once.
  • I agree that there does not appear to be a good reason for specifying ‘only one level’

Are you happy with

  • Incoming Funds can be present at any level. Funds received from external sources but must be reported only once.
#6

I certainly don’t want to block your constructive effort. Would it be worthwhile to consider a specific ‘type’ of transaction to be used for such internal transactions? It’s hardly in line with the common-sense concept of ‘disbursement’ that we usually apply. I would find it problematic along several lines (which type_of_flow of type_of_aid applies to internal disbursements? And can we rely on simultaneous reporting of the out- and in-going amount of each transaction? (otherwise we can’t really clam that there is no double counting)).

If we came up with a specific ‘type’ stamp, I would have no problem. Then these transactions could be entirely ignored if you wish to assess an organisations overall incoming/outgoing flows, and you could instantly verify whether the sum of transactions of that type is zero. I do understand the interest in disclosing the origin of ‘incoming’ funds in any activity.

#7

Yes, I am happy with that.

#8

That looks ok.

Regarding the flows between activities within 1 organization: it depends on the use-case if you are interested in the internal commitment and/or disbursement flows.

From the double counting perspective: you can avoid double counting at data use time, by ignoring/excluding all the transfers between programme and project level. So even when the flows between programme and project level do not balance, you can avoid double counting. I would be reluctant to add the balancing rule for internal flows, since organizations do internal tracking in many different ways. This rule would lead to constructing data which might in reality not be part of an organisation’s administration.

What’s i.m.o. important though is that all flows (commitments, disbursements and expenditures) crossing the organization boundary (incoming and outgoing), are only reported once by this organization.

#9

I think I agree with @OJ_'s point here. It would be helpful to make it clear in the data whether funds are a) actually being disbursed from the organisation or b) just moved around inside that organisation. I find a) is far more important than b), but it would be good if we can find a way to do both consistently.

Almost all of the official donors that have published so far are only publishing commitments / disbursements at one level. In this case, where donors are using multiple hierarchies, flattening them up can be achieved by taking all the transactions from h=2 to h=1. If transactions can be used at both levels, then it becomes much more complicated.

Consider the following:
h=1 activity DONOR-1
=> disbursement to activity DONOR-2: $500
=> disbursement to activity OTHERORG-1: 500

h=2 activity DONOR-2
=> incoming funds from activity DONOR-1: $500
=> disbursement to activity OTHERORG-1: $500

I am then not sure what the total disbursements of h=1+h=2 should be. Is this not overly complicated to handle (and inconsistent with most of the data that has been published to date) compared with just:
h=1 activity DONOR-1: no transactions
h=2 activity DONOR-2:
=> disbursement to activity OTHERORG-1: $500

Also wary of making things more complicated than they need to be, given that the standard is already a bit of a mammoth…

#10

@markbrough There are many publishers which are using two levels of activities (level 1 - programme, level-2 project) within one organisation. Of the organisations funded by the Netherlands MFA which report in IATI, the majority does.

Unless I misunderstand you, your example is about hierarchies spanning 2 organizations. The discussion here was, if I am not mistaken, how to handle transactions in hierarchies within one organization (•The scope of use must not extend beyond the reporting of the activities of a single organisation.). Maybe we are discussing two different subjects here?

As a matter of principle, i.m.o. the IATI standard should be able to reflect reality. We shouldn’t try to artificially simplify reality to accommodate to the standard. So I am very reluctant to accept any limitations on what you can model just to make interpretation of the data (e.g. avoiding double counting) easier. Sometimes you want to avoid double counting. Sometimes you wont. It depends on your use-case. This should be decided at the moment of consuming the data and not at the moment of producing the data.

#11

Hi @Herman, thanks for your response. My example (sorry, wasn’t terribly clear) is about hierarchies within one organisation - DONOR-1 and DONOR-2 projects are from the same organisation, with two levels of hierarchy. My concern is that it is complicated to add up the total amount disbursed if a) both levels can have disbursements to other organisations and b) both levels can disburse to each other.

I can imagine rules you could put in place to handle the example above - i.e. always ensure internal disbursements are balanced by incoming funds. But given how many people are using the standard incorrectly as it currently stands, I don’t think it is realistic to expect such rules to be followed. So users would have to decide whether they think the example means the amount being disbursed is $500, $1000, or $1500, and the correct interpretation might vary by publisher.

If it is important to show internal flow of funds (and I am not really clear what the use case for this is, or how generalisable that use case would be) then I think it would be preferable to explicitly state that the flows are internal rather than re-using the disbursement transaction type.

Basically, I agree with you on this point:

Sometimes you want to avoid double counting. Sometimes you wont. It depends on your use-case. This should be decided at the moment of consuming the data and not at the moment of producing the data.

But I think at the moment, it is not clear how a user would be able to reliably avoid double-counting in this example. And I think we should be trying to avoid adding additional burden to users at this stage.

#13

Agree with @markbrough on this. The use case is not terribly clear for tracking movements of funds within an organization, while the potential for it to be used erroneously appears quite high. The original proposal not to report “transactions” between different levels of a hierarchical group should be maintained.

(Mark, in your example above, total disbursements to OTHERORG-1 if you add h=1+h=2 are $1,000, no? $500 from DONOR-1 and $500 from DONOR-2?)

#14

Yes, in the example total disbursements to OTHERORG-1 are $1000.

However, it could also be that the disbursement from the DONOR-1 activity is a mistake, and that DONOR really meant that $500 was disbursed to OTHERORG-1. Maybe they were trying to say "$500 of project DONOR-1's funds went to OTHERORG-1; that $500 comes from this specific component DONOR-2".

My point being, when we make things much more complex in the standard, both publishers and users will be much more likely to misinterpret the standard and the data and thereby run into fairly significant problems…