Hoverview

beneficiaries · coordination · data quality · double counting · humanitarian

Why cross-partner overlap cannot be solved by better forms

Within-programme double counting can be fixed at the data entry point. Cross-partner overlap cannot, and pretending otherwise inflates every aggregate the sector produces.

A programme that distributes food to the same household every month can, in principle, record that fact. It requires a field at the point of data entry: is this household new or returning? The field is rarely present, as discussed elsewhere on this blog, but its absence is a design omission, not a structural impossibility. A single organisation that serves the same population repeatedly has the information needed to distinguish new from repeat recipients. It simply does not collect it.

Cross-partner overlap is a different problem entirely. When two organisations serve the same person in the same reporting period, neither organisation's data system contains the information needed to identify the overlap. Organisation A does not know that Organisation B served the same household last week, because Organisation A has no access to Organisation B's beneficiary records. No redesign of Organisation A's intake form will change this, because the information that would resolve the overlap does not exist in Organisation A's data at all.

This distinction matters because the sector's response to double counting has overwhelmingly been to improve forms, guidance, and data quality at the individual organisation level. That response is correct for within-programme repetition and irrelevant for cross-partner overlap, and the two problems are routinely conflated in guidance documents that instruct partners to "avoid double counting" without specifying which kind.

The scale of the problem

Cross-partner overlap is not an edge case. It is a structural feature of multi-agency humanitarian response.

In any cluster-coordinated response, multiple organisations operate in the same geographic area, often in the same district, sometimes in the same settlement. A household in a displacement camp may receive food from one organisation, cash from a second, WASH supplies from a third, and health services from a fourth. Each organisation counts the household in its own reporting. When the cluster aggregates those four reports, the household appears four times: once in each sector's total.

DG ECHO's Single Form guidelines (2021) address this within a single partner's submission: the overall number per sector-specific category cannot exceed the total number of beneficiaries in a given sector, meaning a partner serving the same people with food and nutrition should not count them twice in their own report. That rule is enforceable because the partner holds both datasets. The equivalent rule across partners is not enforceable, because no partner holds both.

FCDO's Afghanistan results methodology (2024 to 2025) addresses cross-partner overlap directly by including only the partner with the largest reach in each province in the aggregated total. The factsheet describes the result as a conservative estimate and says it should be interpreted as an "at least" figure. That is an honest response to an unsolvable problem: rather than summing partners and overcounting, it takes the maximum and undercounts, because undercounting is the less dangerous error when the number reaches a parliament.

OCHA's 2020 Global Humanitarian Overview guidance acknowledges the same constraint. Its definition of "people reached" counts anyone who benefited from one or several humanitarian activities at least once during the reporting period. The phrase "one or several" is doing the work: a person who received food assistance from one agency and cash from another has benefited from several activities. Whether that person appears once or twice in the aggregate depends entirely on whether anyone matched the records, and in most responses, nobody did.

Why forms cannot fix it

The reason cross-partner overlap resists improvement at the form level is that the overlap is a property of the relationship between two datasets, not a property of either dataset alone.

Organisation A's intake form can ask: "Has this household received assistance from another organisation in this reporting period?" The household may not know, may not remember, or may have reason to conceal it. Even if the household answers honestly, the answer is unverifiable without access to Organisation B's records. Self-reported overlap is better than nothing, but it is a declaration, not a datum, and its accuracy degrades as the number of organisations in a response increases.

The Food Security Cluster's beneficiary counting methodology (2020) handles this with a proxy: take the activity with the largest reach per location as the unique count, on the assumption that smaller activities are reaching a subset of the same population. The proxy is sound in stable settings where the same households receive multiple forms of assistance. It breaks in mobile populations, in urban settings where service delivery areas overlap without being nested, and in responses where two large organisations serve genuinely different populations in the same district.

The International Mine Action Standards technical note (2023) states the position with clarity: double counting should be avoided where possible, but it may be inevitable in some cases, and incidences of potential double counting should be made clear in reporting. That standard applies within a single organisation's reporting. For cross-partner overlap, the honest equivalent would be: overlap is certain in any multi-agency response, its magnitude is unknown, and the aggregate should state that it is an upper bound.

The one place it has been solved, and what it cost

Cross-partner deduplication has been achieved operationally in one context, and the cost of achieving it is instructive.

WFP's Building Blocks platform is a permissioned blockchain network that assigns each person a unique account, allowing multiple agencies to see what assistance has been provided and avoid unintended duplication. The system has been operational since 2017, initially for cash-for-food transactions for Syrian refugees in Jordan using iris-scan authentication. It has since expanded to Bangladesh, Ukraine, Syria and Palestine, serving over 4.8 million households. In Ukraine alone, the platform helped avoid an estimated $270 million in unintended duplicate assistance across the response.

The Food Security Cluster in Jordan has taken the further step of using Building Blocks for inter-agency deduplication of cash assistance, requiring that a household receives only one form of cash-based assistance covering the same needs in the same period. The deduplication runs on the shared platform with no personal data visible to other organisations: each organisation sees only its own beneficiaries, while the system flags overlaps.

That is the existence proof. Cross-partner deduplication is technically possible. But the conditions that make it work are specific and expensive: a shared technical platform that all participating organisations have agreed to use, biometric or identity verification at the point of assistance, a governance framework specifying what constitutes a duplicate, and a data-sharing agreement that satisfies every organisation's data protection obligations.

Those conditions exist in Jordan's refugee camps, where a bounded population lives in a defined area, registration infrastructure is mature, and WFP has the organisational weight to convene participating agencies. They do not exist in most humanitarian responses, where the population is mobile, registration is incomplete or absent, multiple coordination architectures operate in parallel, and no single organisation has the mandate or the infrastructure to run a shared deduplication platform.

The CCD Network's briefing note on humanitarian data models for deduplication (2024) confirms that there are currently no standards to support operational deduplication processes for humanitarian cash coordination. The governance challenge, it notes, is harder than the technical one: defining the data fields is straightforward, but determining the process for stakeholder agreement on those fields is much more difficult.

The honest alternative

If cross-partner overlap cannot be solved by better forms, and solving it through shared platforms requires conditions that most responses do not meet, what should be done with the number?

The answer is the one FCDO chose for Afghanistan and the one the IMAS technical note recommends for mine action: state the caveat.

A cluster aggregate that sums partners' reach figures without deduplication is an upper bound. It should say so. The number should carry a coverage statement: "This total sums reported reach across 14 implementing partners in Borno State. No cross-partner deduplication has been performed. The figure is an upper bound on unique individuals reached."

That sentence does not fix the problem. It makes the problem visible. A reader who sees the number without the caveat treats it as a count of unique individuals. A reader who sees the caveat knows it is a sum of potentially overlapping counts, and can adjust their interpretation accordingly. The adjustment is imprecise, because the overlap rate is unknown, but imprecise knowledge of a problem is better than confident ignorance of it.

The Food Security Cluster's proxy method (take the largest single activity's reach per location) is better than raw summation, and the caveat should say which method was used. "Cross-partner overlap estimated by maximum-activity proxy per admin-2 unit" gives the reader a way to evaluate the number's construction. "People reached: 340,000" gives them nothing.

Why the caveat is not adopted

If the caveat is cheap, correct, and recommended by at least one international standard, why is it almost never present in published aggregates?

Three reasons.

The first is that a caveated number looks weaker than an uncaveated one. A cluster coordinator who reports "340,000 people reached (upper bound, no cross-partner deduplication)" invites a question that "340,000 people reached" does not. The question is legitimate, but answering it takes time, and the coordinator has other claims on their time in the middle of a response.

The second is that the systems that produce the aggregates do not have a field for the caveat. A 5W spreadsheet has a "Total Reached" column. It does not have a "Coverage Statement" column, or a "Deduplication Method" column, or a "Confidence" column. The caveat has no slot, so it is not recorded, and it is not recorded because nobody designed the slot, and nobody designed the slot because the aggregation was always treated as a summation rather than as a statistical operation with stated assumptions.

The third is the one that matters most: the incentive structure does not reward honesty about uncertainty. A cluster that reports "we reached 340,000 people, but the true unique count is somewhere between 200,000 and 340,000 and we cannot say where" is reporting more accurately than a cluster that reports "we reached 340,000 people." It is also reporting a less useful number for a funding appeal, a less quotable number for a press release, and a less defensible number in a parliamentary question where precision is expected and ranges are read as evasion.

The problem is not that the sector does not know about cross-partner overlap. Every information management officer in every cluster knows about it. The problem is that the reporting infrastructure treats aggregation as arithmetic (sum the column) rather than as estimation (combine the data and state the assumptions), and the incentive to maintain that treatment comes from every direction except the one that cares about whether the number is true.

Whether a reporting system that requires a coverage statement on every aggregate, the way a scientific paper requires a confidence interval on every estimate, would survive contact with the operational reality of a humanitarian response is the question this post leaves open. The precedent from Building Blocks suggests the technical barrier is solvable. The precedent from every 5W spreadsheet suggests the governance barrier is not.

Sources

Donor guidance and methodology

Deduplication systems and standards

  • Building Blocks, WFP Innovation Accelerator. Source for the permissioned blockchain platform, the unique account per person, 4.8 million households served, and $270 million in avoided duplicate assistance in Ukraine
  • Guidelines for Deduplication, Food Security and Livelihoods Cluster, Jordan (October 2024). Source for the Building Blocks-based inter-agency deduplication of cash assistance
  • Humanitarian data models for deduplication in cash coordination: Briefing note, CCD Network / IFRC (October 2024). Source for the absence of standards for operational deduplication and the governance challenge exceeding the technical one

Operational methodology