Invitation: IATI Standard guidance review webinar 3

Following the success of last year’s guidance consultations, the IATI technical team is inviting the IATI Community to join the third guidance webinar on 1st April. We’ll be reviewing the newly improved IATI results and conditions guidance and discussing what ‘recommendations’ should be included. You don’t need to have participated in the previous webinars to contribute. The deadline to sign-up is Friday 13th of March.

What will the webinar cover?

The IATI technical team has rewritten and added additional content to existing IATI Standard guidance currently published on the Activity and Organisation overview pages on This webinar will look specifically at the result and conditions elements. We want you to review the content of the new pages and provide feedback:

  • Review pieces of additional guidance

  • Highlight and suggest areas of the guidance which could be better explained

  • Identify gaps

  • Provide use cases for IATI data where relevant

If you are interested in helping us, please send an e-mail to indicating if you would like to join the webinar and / or the review process. We will share the guidance to be reviewed and commented on with participants before the webinars.

Why rewrite IATI Standard guidance?

The IATI technical team is undertaking this process as part of our ongoing project to consolidate and improve the guidance documentation and make it available on the IATI Standard website, which was launched in 2018.

We hope to:

  • Ensure the overview guidance pages are written in a user-friendly language to help data publishers and users better understand the IATI Standard

  • Add additional guidance for publishers to help improve the consistency of data published to IATI

Do note:

We have split the overview guidance pages into various groups. Further guidance pages will be reviewed throughout the year.

Webinar dates

  • Webinar 3 Wednesday 1 April 3.30pm - 4.30pm UK time. This webinar will cover three pages of guidance covering results and conditions.

  • Upcoming webinar 4 (tbc). This webinar will cover three pages of guidance, covering identifiers, converting currencies and extending the standard (namespaces). More details coming soon.

Cannot attend?

If you are keen to review the updated guidance but cannot attend the webinar, you can still add your voice by providing written feedback. The webinar will be recorded and can be sent to you to listen. Please let us know.

Sign-up by Friday 13th of March

To sign-up please e-mail letting us know you are interested in being part of the process and state if you can attend. We encourage you to share this invitation with relevant people in your networks.

Let us know if you have any questions and we look forward to working with you on this important piece of work!

Thanks for continuing to drive forward the need for more precise and thorough guidance material @IATI-techteam

Can I also highlight how this is related to the thread around how we best version control and safeguard such materials.

I am also keen to understand the status of the previous materials, and how these will be openly version controlled. Right now, it seems these documents are in PDF format, with no clear process outlined for querying their validity. For example, on document-link categories, the PDF guidance currently says:

This must be included at least and only once for
each document-link.

(my emphasis ^)

This seems to be in contradiction to the IATI schema, which says:

This element must occur at least once (within each parent element).

I would suggest as part of this consultative process it is made clear how we can share such observations, synch up the materials, and ensure collective and open version control.


+1 to this point. Back in September, I raised a github ticket for the bug given as an example in Steven’s post, but I’m unsure what the process is for addressing it:

Linking this conversation with other posts, all the new IATI guidance material can be found in the IATI-Guidance GitHub repo.

This means the IATI community can raise issues and make suggestions here. The tech team can also raise issues on behalf of users not familiar with GitHub.

Alongside this, we are working on establishing a process for managing the guidance going forward and will share when we are able to.

Please do continue to flag discrepancies between the schema and guidance pages! We will investigate them.

1 Like

IATI has launched new guidance on publishing and interpreting data on the results and conditions of development and humanitarian activities using the IATI Standard. The new guidance follows the third consultation on Standard guidance with IATI’s community.

IATI community consultation

The third round of IATI’s Standard Guidance Review consultations took place in March and April 2020. The IATI Secretariat then paused work on the guidance pages to focus on creating IATI COVID-19 data use and publishing guidance. As with previous IATI guidance reviews, the IATI community was invited to provide feedback on draft guidance pages. The IATI Technical Team reviewed incoming feedback then held a webinar to discuss areas requiring further detail; this included exploring differing views and whether we could include any best practice recommendations. Following the webinar, the Technical Team updated the new guidance, incorporating the feedback received and noting areas for further consultation or those which will require an upgrade to the IATI Standard.

Results guidance

There are now two new guidance documents on how to use the IATI Standard to publish and interpret data on the results that development and humanitarian activities have achieved:

  • Results information - provides an overview of IATI results data, an explanation of what data the IATI Standard requires and how results can be made useful for data users.

  • Understanding results data - presents results data based on a visualisation IATI’s d-portal. This allows users to understand how to combine and interpret the range of data published as part of a result.

Consultation participants recognised that the results guidance is a great start at explaining the elements and attributes available in the IATI Standard. However, the standard is not set up, nor does the guidance go far enough for us to be able to provide ‘best practice’. The group proposed that a working group, made up primarily of data users and M&E colleagues, should be formed to explore this area further.

Conditions guidance

Data on conditions helps users to understand what requirements are attached to an organisation receiving funds. For example, these could be the requirements issued by a funder who requires a six month review to assess whether or not the activity is worth continuing. The following guidance received updates during the consultation process:

  • Conditions - explains why conditions are useful and what kind of conditions can be published in IATI.

Whilst the conditions guidance has been updated, consultation participants questioned its current use and benefit in the IATI Standard. It has been in the Standard since version 1.01. However, due to it being rarely used by publishers, it could be a contender for removal at the next IATI major upgrade in order to help streamline the Streamline and simplify the Standard.


For any questions or comments on the guidance documents, please email the IATI Technical Team: or post a message on IATI’s forum, Discuss.

Next steps

The Technical Team will continue to identify additional areas of guidance for the IATI community to review and feedback on. If you would like to be a part of the guidance review process then do let us know by emailing the team at Alternatively, keep an eye out on Discuss and the IATI newsletter for additional information.

1 Like

Thanks, @IATI-techteam for this update!

I wanted to flag one issue:

I am not quite sure what this means – is it suggesting that the conditions element could be removed at the next integer upgrade?

I know that this is not an explicit proposal at this stage, but I would still really caution against this. Almost 20% of publishers are using the conditions element, and it’s an explicit commitment under the Accra Agenda for Action (§25b):

b) Beginning now, donors and developing countries will regularly make public all conditions linked to disbursements.

This is particularly important in the context of budget support, where the amounts can be large and have non-trivial impacts on the budget, so having clarity about the disbursement triggers is really important. It’s also important for civil society to be able to monitor conditionality that governments have signed up to.

However, it’s also important for large loan projects, where the country may already have started paying for the loan (because of commitment charges) but disbursements cannot yet begin as preconditions (e.g. establishing a bank account, passing certain legislation) have not yet been met. I guess publishing conditions may be less important for smaller grant-funded projects.


Thanks @markbrough. The idea of removing the conditions element was brought up and discussed in the consultation. It could indeed be a version 3 proposal and worthy of discussion.

As you’ve said. We’re not there yet.

What would be interesting is to look at how it’s currently being used by publishers. If used properly I agree it’s super useful. However, my hunch is that a lot of published conditions don’t provide useful information.

1 Like

Thanks for the clarification @amys! Agree it may well be the case that there is a lot of poor quality data in this element, though I think we should not lose sight of why this element was included in the Standard in the first place.

I would also suggest looking at some of the better examples (e.g. see this project, which is not bad) and the extent to which they meet organisations’ AAA commitments.

I’m not sure this example does makes the case. The conditions narrative has been copied from the finance agreement which is available (in all World Bank activities) via the document links.

Is the AAA commitment to be transparent on conditionality best served by a structured IATI field? Or by better linking to contract documentation?

Thanks Bill, I agree it’s great that the World Bank publishes a lot of documents alongside its projects, though I’m not sure I understand what you are saying here. Are you suggesting it doesn’t make a difference to transparency whether information is provided in a structured format or found somewhere within a long PDF?

I’m suggesting that free text (that needs to be read by a human) in a structured format is not particularly helpful and is equally served by a document link. The value of the standard (from my point of view) is to produce information by comparing activities (across publishers, countries, sectors, etc) - not just list and view.

Thanks Bill - I think it depends on what you’re trying to do with the data. I agree that cross-publisher/country/sector comparisons can be useful, but I don’t see how this negates the value of detailed activity-specific information which is not comparable across those dimensions (but which can still be very useful for the purposes of aid management).

I disagree. I think that the conditions element could be structured in a more helpful way, but having a list of conditions explicitly stated is much more useful than having to hunt around in a number of different PDFs which may or may not contain this information.

(NB you could also make the same argument about descriptions – why have the <description> element when you could just stick the same information in a PDF?)

I notice the new guidance has a “last updated” date, and a prominent link back to the source showing the changelog, which is excellent. It would be great to include something similar on reference pages, too.

However, it’s not clear to me how the last updated date relates to the source… In some cases it’s ahead, in some cases it’s behind. Is this expected, or is there an issue here, @IATI-techteam? Thanks in advance

Hi Andy,

Wagtail attempts to pick up the date encoded in the metadata of the guidance RST files, and failing that defaults to the date the page itself was updated. It’s hard to see the metadata tags because Github renders the RST, but you can see them at the bottom of the raw file:

Wagtail wasn’t picking up the date in “Understanding Results” before removing the meta tag from the rendered HTML, so I’ve modified the import procedure to retain the meta tags in the body of the rendered HTML. If you check it again it should say “July 27, 2020” to match the date at the bottom of the RST.

1 Like

Ahh, I see. Great – thanks for clarifying, @alex_miller.

EDIT: Did you consider fetching the last updated timestamp from version control, instead of using page metadata? Version control stores this information, and duplicating it adds extra work and is likely to cause discrepancies (as seen here).