Recently I’ve been looking at how we can best use Hierarchies in IATI. The tech team are looking to agree guidance in the interim before the next upgrade. See here for a post about our proposed Future use of Hierarchies.
Our draft guidance is here. Please do comment on this post and in the document.
Below is a summary of our reasoning behind the guidance:
Structuring data
Organisations can use multiple hierarchical models to structure their data. These should best reflect an organisation’s internal structure.
-
The original intended purpose of hierarchies was to enable the earliest reporting of an organisation’s own internal funding decisions and flows.
-
Any number of hierarchies can be used, provided that they are sequential (this rule to be added at the next upgrade).
-
For example, an organisation may need multiple hierarchical structures to reflect their allocation of funds (use-case from DFAT Australia):
Simple:
One bilateral program fund
All budget/ commitment/ expenditure in one country
Moderate:
One non-bilateral program fund
All budget/ commitment done at a higher (regional/global) level
Expenditure attributed to countries after the end of each financial year
Complicated:
Multiple program funds - bilateral and non-bilatera
Budget done at various levels e.g. country and regional
Commitment covers entire investment
Expenditure attributed to countries after the end of each financial year
Internal transfers
Incoming Funds and Disbursements should be used to show allocation of funding/transfers of funds within an organisation:
-
No new type of transaction can be added until the next standard upgrade.
-
Using ‘Incoming Commitment’ and ‘Commitment’ is not appropriate as this would require changing their definitions: http://iatistandard.org/203/codelists/TransactionType/.
-
Using Incoming Funds and Disbursements means the same principles of traceability apply, as with transactions between organisations.
Strongly advise organisations to include the name and ref in the <provider-org>
and <receiver-org>
transaction elements:
-
This should become mandatory at the next standard upgrade.
-
This allows internal transfers of funds to be identified by the matching provider and receiver org refs.
-
To avoid double counting, only transactions which have differing and should be counted.
Relating activities
Organisations should explicitly detail the relationship between different activities and the internal flow of funds through them using the Parent and Child relationships:
- When looking at the data, this will help the user navigate the activities.
Other points to note
-
Cannot have hierarchies across organisational boundaries.
-
Related activities can be declared across organisational boundaries, as per the current IATI schema. Our guidance is that Parent, Child and Sibling relationship types should not be used this way: http://iatistandard.org/203/codelists/RelatedActivityType/.
-
Organisations can choose how to structure their data. This allows their IATI data file to best reflect their practices e.g. creating hierarchies based on internal financial flows or results reporting.
Hi Amy Silcock , thanks for your reply.
amys:It would be great to understand in more detail the arguments about why this would be a good idea and how the benefits outweigh the (I would argue substantial) costs of even more disruptive changes to the Standard. Even when making integer upgrades, I think we should avoid breaking changes which significantly increase the costs for data users as well as for publishers. I really don’t see any demand or need for these changes.
amys:I don’t think representing financial flows within an organisation is the main reason for having hierarchies. It would be great to see arguments explaining why this would be desirable (and why those benefits offset the costs of additional complexity). I think the reason for having hierarchies is much simpler – as I argued in the guidance document:
amys:Having a consistent hierarchy makes it much easier to use the data. If it is really important for organisations to have multiple hierarchical structures (some specific examples would be helpful) then perhaps we can find a way for them to be able to publish in as consistent a way as possible without making their data more difficult to use.