Transactions
This page is currently flagged for review. We are undertaking an update of the information we publish about the IATI Standard, and the content here has not yet been checked.
Aid type information
There are four elements that specify different attributes of an aid activity:
- default-flow-type — the nature of the assistance provided (e.g. official direct assistance, private NGO funding).
- default-aid-type — the type of aid supplied (e.g. budget support, pooled funds).
- default-finance-type — the type of financing supplied (e.g. debt relief).
- default-tied-status — indication of whether the aid is tied to the purchase of specific goods or services.
- collaboration-type — indication of whether the project is bilateral or multilateral.
The first four elements provide a default value for all of the financial transactions in an activity report. When necessary, they can be overridden for individual transactions using the transaction/flow-type, transaction/aid-type, transaction/finance-type, and transaction/tied-status elements. Here is an example of the default aid type information elements in use:
<activity>
...
<default-flow-type code=”10”>Official Direct Assistance</default-code-type>
<default-aid-type code=”A01”>General Budget Support</default-aid-type>
<default-finance-type code=”810”>Bank Bonds</default-finance-type>
<default-tied-status code=”05”>Untied</default-tied-status>
...
</activity>
The human-readable content is optional (but helpful), and has no fixed format; it is also permissible to use only the raw codes:
<activity>
...
<default-flow-type code=”10”/>
<default-aid-type code=”A01”/>
<default-finance-type code=”810”/>
<default-tied-status code=”05”/>
...
</activity>
Unlike the other four, collaboration-type has no bearing on individual financial transactions, and can be specified only at the top level. It is most useful for major development activities funded by national donors, and specifies whether projects are bilateral (involving just one donor country and the recipient), multilateral (involving multiple donor countries), and so on (see the Collaboration Type code list for details):
<collaboration-type code=”1”>Bilateral</collaboration-type>
These elements use codes from the following lists:
- IATI Flow Type code list for default-flow-type (and transaction/flow-type).
- IATI Aid Type code list for default-aid-type (and transaction/aid-type).
- IATI Finance Type code list for default-finance-type (and transaction/finance-type).
- IATI Tied Status code list for default-tied-status (and transaction/tied-status).
- IATI Collaboration Type code list for collaboration-type.
Financial information
Financial information is at the heart of IATI — in many ways, it is the most important information about an aid activity, since it allows agencies, national governments, and others with planning future activities.
At the activity level, IATI supports both aggregate financial information for the entire activity in the total-cost element, and records of individual inflows and outflows of money, both planned and actual, in the budget-planned and transaction elements.
To understand how IATI handles financial values, it is useful to start with the total-cost element. The total-cost element specifies the budgeted cost of the activity over its entire lifetime, and appears at the top level of an activity record:
<total-cost currency=”EUR” value-date=”2010-03-31”>2000000</total-cost>
There are three important pieces of information here:
- The currency attribute provides the ISO 4217 code for the currency of the financial value, such as “USD” for US dollars, or “EUR” for Euros. This attribute is required unless the file specifies a default-currency attribute on the parent activity element — in that case, the default currency applies to any financial element that does not have its own currency attribute.
- The required value-date attribute provides an historical reference date for converting the amount to different currencies. For example, if an aid agency announced a project costing USD 500,000 on March 31, 2010, the exchange rate on that date should be used to calculate the equivalent value in other currencies (such as Euros or Pounds Sterling).
- The content of the element gives the total amount as an integer. It must include all required zeros (no abbreviations such as “M” or “B”), and include no commas or decimal places: in other words, “2000000” is acceptable, while “2M”, “2,000,000”, and “2000000.00” are not. IATI does not track fractional amounts, such as pennies.
Financial transactions
The transaction element lists money flowing into or out of an aid activity (possibly from or to another activity). Transactions are critical for tracking the flow of money across different activities and avoiding duplicate counting; for example, if Activity A gives €1,000,000 for Somalia to Activity B, Activity B gives Somalia €1,000,000 to Activity C, and Activity C spends €1,000,000 on a development project in Somalia, it must be possible to count that as only €1,000,000 in aid money for Somalia, not €3,000,000. To help accomplish this goal, IATI uses three kinds of unique identifiers:
- Transaction identifiers: when Activity A disburses €1,000,000 to Activity B, Activity A should use the same identifier for its outgoing transaction as Activity B uses for its incoming transaction, so that users know there are not two separate disbursements.
- Activity identifiers: When Activity A gives money to Activity B, the outgoing transaction in the Activity A report includes Activity B’s identifier, and the incoming transaction in Activity B’s report includes Activity A’s identifier.
- Organization identifiers: In addition to the activity, the transactions also identify the organization that is making the payment.
Here is an example of a £100,000 disbursement from the fictitious ACME Foundation to the fictitious ACE Agency, from ACME’s perspective:
<transaction flow=”outgoing” ref=”ACME:transactions:12345”>
<value currency=”GBP” value-date=”2010-03-15”>100000</value>
<transaction-date type=”announced” iso-date=”2010-03-01”/>
<transaction-date type=”committed” iso-date=”2010-03-15”/>
<transaction-type code=”D”>disbursement</transaction-type>
<provider-org ref=”ACME”>ACME Foundation</provider-org>
<receiver-org ref=”ACE”>ACE Agency</receiver-org>
<receiver-activity ref=”ACE:activities:12345”/>
</transaction>
This markup describes transaction “ACME:transactions:12345”, stating that ACME committed ₤100,000 to ACE’s aid activity “ACE:activities:12345” through the activity currently being described. The disbursement was announced on 1 March 2010, and a legally-binding commitment was signed on 15 March 2010, which should also be used as the reference date for converting to other currencies. The money is going into ACE’s activity “ACE:activities:12345”.
Here is the same transaction from the perspective of ACE’s activity “ACE:activities:12345”:
<transaction flow=”incoming” ref=”ACME:transactions:12345”>
<value currency=”GBP” value-date=”2010-03-15”>100000</value>
<transaction-date type=”announced” iso-date=”2010-03-01”/>
<transaction-date type=”committed” iso-date=”2010-03-15”/>
<transaction-type code=”C”>commitment</transaction-type>
<provider-org ref=”ACME”>ACME Foundation</provider-org>
<receiver-org ref=”ACE”>ACE Agency</receiver-org>
<provider-activity ref=”ACME:1011-12”/>
</transaction>
Most of the content is the same, except that for ACE’s activity, this is an incoming transaction (as specified by the flow attribute), and the provider-activity element specifies the activity that is providing the money (ACME’s), rather than its own activity that is receiving it.
The transaction-type element uses the IATI Transaction Type code list, which currently contains the following codes:
- C: commitment — a firm written obligation from the donor.
- D: disbursement — a transfer of funds from one organization to another.
- E: expenditure — a final outlay of funds on goods or services for an activity.
- LR: loan repayment — a final outlay of funds against the principal of a loan.
- IR: interest repayment — a final outlay of funds against the interest of a loan.
A transaction may additionally contain the elements flow-type, aid-type, finance-type, and tied-status. These have the same meaning and content as the default-flow-type, default-aid-type, default-finance-type, and default-tied-status elements for the activity as a whole (described above), but can be used to override any of the defaults for a specific transaction. For example, the following specifies that a specific transaction is tied:
<transaction flow=”outgoing” ref=”ACME:transactions:67890”>
<value value-date=”2010-10-01”>500000</value>
<tied-status code=”04”>tied</tied-status>
...
</transaction>
Planned expenditures
The budget-planned element lists the planned future expenditures for an activity. This element has many similarities to transaction:
<budget-planned period=”annual”>
<value value-date=”2010-10-01”>1500000</value>
<period-start iso-date=”2011-04-01”/>
<period-end iso-date=”2012-03-31”/>
<receiver-org ref=”ACE”/>
</budget-planned>
The period attribute specifies an accounting period; allowed values are “annual”, “quarterly”, and “monthly”. The period-start and period-end elements provide the actual start and end dates of the period — in this example, the organization’s fiscal year begins on 1 April and ends on 31 March. The value and receiver-org elements are the same as in transaction.
Note that there is no flow attribute, because IATI activity reports include only planned outgoing disbursements — the budget-planned element is meant to give an indication of how much an activity is planning to expend or disburse in the medium term, beyond the current commitment period. Any money which has been firmly commited should appear in a transaction element instead. There is also no receiver-activity element (though, as in transaction, receiver-org has an optional attribute receiver-activity-id to include the receiving organization’s internal identifier).
The budget-planned element should be repeated for each receiving organization and accounting period for which planning information is available:
<budget-planned period=”quarterly”>
<value currency=”GBP” value-date=”2010-10-01”>175000</value>
<period-start iso-date=”2011-04-01”/>
<period-end iso-date=”2011-06-30”/>
<receiver-org ref=”ACE”/>
</budget-planned>
<budget-planned period=”quarterly”>
<value currency=”GBP” value-date=”2010-10-01”>300000</value>
<period-start iso-date=”2011-07-01”/>
<period-end iso-date=”2011-09-30”/>
<receiver-org ref=”ACE”/>
</budget-planned>
<budget-planned period=”quarterly”>
<value currency=”GBP” value-date=”2010-10-01”>150000</value>
<period-start iso-date=”2011-10-01”/>
<period-end iso-date=”2011-12-31”/>
<receiver-org ref=”ACE”/>
</budget-planned>
<budget-planned period=”quarterly”>
<value currency=”GBP” value-date=”2010-10-01”>100000</value>
<period-start iso-date=”2012-01-01”/>
<period-end iso-date=”2012-03-31”/>
<receiver-org ref=”ACE”/>
</budget-planned>
In this example, the activity has budgeted a ₤175,000 disbursement to ACE in Q1, a ₤300,000 disbursement in Q2, a ₤150,000 disbursement in Q3, and a ₤100,000 disbursement in Q4, but has not yet made a legally-binding commitment to provide the money.