Relief Applications

Cash and voucher assistance: what a CVA system must do

Cash and voucher assistance moves money, not goods, to the people you serve. That makes the list of households, the payment run and the reconciliation the places where things go wrong. This guide sets out what a CVA system has to do at each step, what to ask a vendor, and the data protection questions that come with payments.

The short answer

A cash and voucher assistance (CVA) system should register and verify households, catch duplicates across rounds and partners, apply your targeting criteria, produce payment lists that need approval, match what the payment provider reports to your list, and record monitoring and complaints afterwards. Choose on how it handles those steps with your own data, offline where you work, and with the least personal data you can get away with. Biometrics and data shared with payment providers call for a data protection impact assessment.

What CVA is

Cash and voucher assistance, or CVA, covers all programmes where people receive cash transfers or vouchers instead of goods or services. The CALP Network, the sector’s learning partnership on the subject, uses the terms below, and you will meet them in donor guidance.

  • Cash transfers give people money, as physical cash or electronically (mobile money, bank transfer, card).
  • Vouchers give people a paper or electronic token to exchange for set goods or services, at chosen vendors.
  • Unconditional transfers carry no requirement; conditional ones depend on an action, such as attending school.
  • Restricted assistance can be spent only on certain goods or services; unrestricted assistance can be spent on anything.
  • Multipurpose cash is an unrestricted transfer meant to cover a range of basic needs.

Each choice changes what you have to record and check, so settle it before you choose a system. A voucher programme needs vendor management and redemption tracking. A mobile money programme needs your records to match the provider’s.

The cycle, and where spreadsheets break

Assess and design
What happens: Choose the modality, transfer value, targeting method and delivery mechanism. Where spreadsheets fail: Assumptions and decisions live in documents, not next to the data
Register and verify
What happens: Record households or individuals, with consent, and verify identity. Where spreadsheets fail: Several teams build their own lists; the same household turns up twice
Target
What happens: Apply criteria and scoring to select who receives assistance. Where spreadsheets fail: Scoring rules change by hand, and no one can show why a household was in or out
Pay
What happens: Produce payment lists, get approvals, send to the provider or distribute. Where spreadsheets fail: Lists are emailed around and edited; approvals are informal
Reconcile
What happens: Match what the provider reports against your list and resolve the gaps. Where spreadsheets fail: Weeks of manual matching, often after the next round has started
Monitor and hear complaints
What happens: Post-distribution monitoring, complaints and feedback, corrections. Where spreadsheets fail: Findings sit apart from the household record and do not reach the next round

What a CVA system must do

Registration

Register households and verify them in the field, with consent, on phones and tablets that work without a connection and sync later. The record should carry the fields you need for targeting and reporting, and nothing you do not.

Deduplication

The system should catch the same household entered twice, within a round, across rounds and across partners. This is the most common source of waste and of donor findings. Ask how it matches (names alone do not work), what it shows the person reviewing a match, and who can merge or reject one.

Targeting

Eligibility rules and vulnerability scoring should be written in the system, versioned, and applied to produce a list that a person reviews. Anyone should be able to open a household and see why it was selected.

Payment rounds and approvals

A round has a list, a transfer value per household, a delivery channel and an approval. Look for two-step approval, so that the person who prepares the list is not the one who releases the money, and a lock on the list once approved.

Reconciliation

The provider sends a report of what was paid, failed or not collected. The system should match it to your list, flag the differences, and let you resolve each one. Reconciling a round should take days at most.

Monitoring and complaints

Post-distribution monitoring results and complaints should attach to the household and the round, so that what you learn changes what you do next. A complaints and feedback mechanism is part of a CVA programme, not an extra.

Reporting

Donors ask how many households, how much money, how much reached people and how much did not. The system should give those figures from the records, by round, location and group, without a rebuild each time.

Questions to ask a vendor

  1. Show me registration offline on a phone, with consent and verification, then the sync.
  2. How does it find duplicates across rounds and across partners, and who decides on a match?
  3. Can I write our targeting criteria as rules, change them with a record of the change, and see why each household was selected?
  4. Do payment lists need a second person to approve, and are they locked afterwards?
  5. Which delivery channels does it handle: cash, vouchers, mobile money, bank transfer? What does it do for each, and what is exchanged as files?
  6. How are provider reports loaded and matched, and how do I resolve what does not match?
  7. Where do monitoring results and complaints attach?
  8. What personal data is stored, where, who can see it, and can I turn off fields I do not need?
  9. Can I export everything in an open format if we part ways?
  10. Who supports me, in which language and time zone, during a distribution?

Data protection in cash programmes

CVA collects names, identity details, phone numbers and sometimes biometrics from people who depend on you, and shares part of it with a financial service provider. That is the setting for a data protection impact assessment. The points to think through:

  • Collect the minimum. Ask what each field is for. If you cannot name its use, drop it.
  • Be careful with biometrics. They cannot be changed if they leak, and some contexts make them dangerous. Consider less intrusive options, and keep a fallback for people who cannot or will not enrol.
  • Agree what the provider receives. Share what is needed to pay, under a written agreement that limits their use of the data and says how long they keep it.
  • Check the legal basis. Consent is hard to rely on when people depend on assistance, so many organisations rely on another basis. Whichever you use, say so.
  • Plan for deletion at the end of the programme.

Our guide to DPIAs for NGOs includes a worked example on biometric registration for cash assistance, and a template.

Your options

Spreadsheets
Fits: A small, one-off programme with one partner. Watch for: Duplicates, version chaos and slow reconciliation as soon as there are several rounds
A platform made for CVA or beneficiary management
Fits: Large or repeated programmes that need specialised features. Watch for: Fit with your donors’ rules and your finance system, and how long it takes to switch
A general data collection tool plus spreadsheets
Fits: Registration and monitoring with limited back-office needs. Watch for: The payment and reconciliation steps stay manual
A module in a wider ERP
Fits: Organisations that want payments tied to grants, budgets and reporting. Watch for: Whether the module goes as deep as a specialised tool on the steps you need

There is no single right answer. What matters is that the household list, the payment and the reconciliation sit in one place, with the access and approvals that your donors expect.

Rolling it out

  1. Start with one round, in one location, with your own data.
  2. Test the full path from registration to reconciliation before the first payment.
  3. Train the field team in the language and conditions they work in.
  4. Run post-distribution monitoring and read the complaints, then adjust before you scale.
  5. Review what personal data you hold at the end of each round.

Where Relief One fits

Relief One’s CVA software, the Cash and Voucher Assistance module, covers this cycle: households registered and verified in the field with consent, offline; eligibility rules and vulnerability scoring with a reviewed list; duplicates caught across rounds and partners; distribution rounds through mobile money, bank, cash in an envelope or vouchers, with two-step approval; provider reports matched to the list; and complaints and post-distribution monitoring after each round. It sits on the same base as grants, finance and MEAL, so a payment round can be tied to the grant that funds it. See the other modules or pick the ones you need.

For the policy and assessment side, our team has run cash and voucher work for the sector, including a feasibility study on vouchers in food assistance and trainings for Red Cross and Red Crescent National Societies.

Questions and answers

What is cash and voucher assistance?

Programmes that give people cash or vouchers instead of goods or services, so that they can choose what they need. It includes cash transfers, electronic payments and vouchers redeemed at vendors.

What is the difference between cash and vouchers?

Cash can be spent on anything, unless restricted. A voucher can be exchanged only for specified goods or services, often at selected vendors.

What should CVA software do?

Register and verify households, catch duplicates, apply targeting rules, produce approved payment lists, match provider reports to your list, and record monitoring and complaints.

Do we need a DPIA for a cash programme?

Often yes. Vulnerable people, sensitive or biometric data and sharing with a payment provider all point to a high-risk processing. If you are unsure, do the assessment.

Can the system work in places with a poor connection?

Registration and field data capture should keep working without a network and send when it returns. Ask any vendor to show exactly which functions work offline.

How do we stop the same household being paid twice?

By registering every household once, in one register shared across rounds and partners, with a review step for suspected duplicates, rather than by comparing spreadsheets after the fact.

See a payment round, from list to reconciliation

Book a demo of Relief One. We walk through registration, a payment round with two-step approval, and the reconciliation.

Keep reading

This guide is general information, not legal or technical advice. Reviewed on 11 November 2026 by the team at Relief Applications.