Ask it on your next discovery call. By the end of this guide you'll understand the answer.

Why this existsWe build for work most of us have never done

A developer who has never seen a utilisation certificate will build a budget module that looks right and fails the first audit. A PM who doesn't know why a donor ID matters on a beneficiary record will cut it as "extra scope".

None of that is a skills problem. It's a context problem. This guide gives you the context: who's in the room, where the money comes from and what it's allowed to do, how a person moves through a programme, how anyone knows it worked, and where technology fits in all of it.

The big pictureEvery nonprofit runs three flows at once

Most requirements you'll ever write live where these three flows meet.

The convergence sentenceOne line that proves a system works

When programme, M&E and finance data can produce this sentence without a week of manual reconciliation, the organisation has a real system. Change the numbers and watch what happens to the last one.

How to use this guideFive things you'll keep bumping into

This isn't a document to skim. Each chapter mixes reading with small things to do. Give yourself 30 to 40 minutes per chapter.

The lenses we reuseHow EdZola looks at any organisation

MAP: Model, Align, Power with AI

The four seam tests

When we tear down how an organisation works, these are the four joints we check first. A broken seam is almost always where the pain lives.

Two more we'll use

• Programme, Paisa, People: programme data, finance, HR. Find where they're connected and where they're siloed.
• Maturity tags: for any capability, is it Live Built, not adopted In development Manual or Absent?
• ImpactOS: EdZola's standard data model and delivery lifecycle (Discovery, Architecture, Build, Dashboards, Deploy, Maintain). If you know ImpactOS, you know how EdZola works.

The chaptersFollow the actors, then the rupee, the person and the data

Chapters 2 and 3 can be read in either order. Chapter 4 needs both. Chapter 5 needs all four.

Where this endsThe Three Maps capstone

After chapter 5, put it all together for your chosen NGO. On your own it's a 2-hour exercise; in a team of 2 or 3, present it in 20 minutes. Tick things off as you finish them.

• Actors: who funds, who delivers, who benefits, who regulates (chapter 1)
• Money map: donor to grant to budget heads to spend to utilisation report (chapter 2)
• People map: entry to outcome, with the biggest drop-off marked (chapter 3)
• Evidence map: 5 indicators that matter, where each comes from, who sees it (chapter 4)
• Seam tests: which of the four seams is broken, and what it costs them
• MAP recommendation: one Model fix, one Align fix, one AI move with its failure mode (chapter 5)

Compliance figures (FCRA, 80G, CSR) reflect EdZola's Indian NPO Operations Playbook (March 2026) and public sources checked September 2026. Rules change; recheck before quoting them to a client.

Vote before you read. We'll come back to these.

1 · The big ideaA nonprofit is a business with two customers

A company has one customer who both pays and receives the product. A nonprofit splits that customer in two. The person who pays (a CSR department, a foundation, a donor) is not the person who receives the service (a student, a patient, a farmer).

So the nonprofit has to prove to one party what happened to another. That single fact explains most of what we build:

• Reporting is heavy because the funder can't see the service directly.
• Beneficiary IDs matter because you need to prove the same person was served, not counted twice.
• Feedback loops are weak because the beneficiary doesn't pay, so their voice has no built-in channel.
• Donor fields show up in programme forms because the money has to be traced to the person.

In a company, the customer tells you the product is bad by not buying it. In a nonprofit, the beneficiary usually can't. Our systems are part of how their voice gets heard.

2 · The actorsTen actors, ten sets of demands

Tap an actor to see what they want, and what that turns into when they ask for a system.

3 · Legal formsTrust, Society or Section 8: the 10-minute version

On top of the legal entity sit registrations. Each one unlocks a kind of money, and each one becomes a field.

4 · Operating modelsHow the work actually gets done

Most real organisations mix models. Akshaya Patra runs its own central kitchens (direct delivery), inside a government scheme (government partnership), funded partly by government cost norms and partly by donors. That mix shapes every requirement.

5 · The words that matterProgramme, project, grant, activity, beneficiary

Nonprofits use these words loosely. Our data model can't.

The classic mistake: one Excel sheet per donor, with the same child appearing in three sheets because three donors each fund part of the same school. The fix is one beneficiary record linked to many projects. The project link is what lets you answer each donor honestly without double-counting.

6 · The nonprofit yearA calendar of pressure

The Indian financial year, 1 April to 31 March, drives almost everything. Red months are bad months to launch a finance module.

• January to March: CSR money rushes in and utilisation reports pile up. Don't schedule a finance launch in March.
• April: budgets reset. Systems must default to the financial year, never the calendar year.
• May: 80G season. Donors wait on 10BE certificates, so donor PAN data has to be clean all year, not fixed in May.
• September to December: audit and returns season.

7 · Your turnMap the room

8 · Go furtherWatch and read

• Article
  The Nonprofit Starvation Cycle, Gregory and Howard, Stanford Social Innovation Review (2009). Why NGOs underinvest in systems, and why selling to them is hard. 20 min.
• Report
  India Philanthropy Report 2026, Bain & Company and Dasra. Who funds India's social sector. Skim in 30 min.
• Browse
  Any one annual report of Pratham, Akshaya Patra, Educate Girls or Goonj. Read it the way a donor would. 30 min.

Think of an NGO you know. Could they answer this in a day? In a week? Keep that answer in mind as you read.

1 · The lifecycleTwelve stages, one loop

Tap through the stages, or press play. Then say it out loud until it's automatic: donor, proposal, grant, agreement, budget, allocation, spend, utilisation, evidence, report, audit, renewal.

The last arrow matters most. A late, messy or unconvincing report doesn't just annoy the donor. It kills the renewal, and renewals are the cheapest money an NGO ever raises.

2 · Eight jobs"Fundraising system" usually means three of these

These get lumped together as "fundraising" or "finance". They're different jobs, with different users, often in different systems.

3 · SourcesWhere the money comes from

Paying for outcomes, not activities

The Educate Girls Development Impact Bond (Rajasthan, 2015 to 2018) was the world's first development impact bond in education. An investor fronted the money, and an outcome funder repaid it only if an independent evaluator verified results.

4 · VocabularyThe words finance people use, and why

Restricted vs unrestricted

Most institutional money is restricted. That's why every expense needs a project code and a budget head: so restricted money is provably spent on what it was restricted to.

Hard vs soft commitments

Tranches: the report module is a cashflow module

A ₹1 crore grant rarely arrives at once. It comes in instalments, and each one is usually unlocked by a report.

The fundraising gap: leadership's heartbeat number

Try it with your own numbers, in ₹ lakh. The 50% and 70% are EdZola playbook conversion assumptions from Indian NGO practice. Renewals convert better than new leads, so they're tracked separately.

5 · Budget, allocation, spendWhere CRM meets accounting

Rules that shape the design

• Budgets are multi-dimensional: programme × geography × activity × HR/non-HR × FCRA/non-FCRA × financial year.
• Activity codes must sum to the project budget. Validate it.
• Cost centres usually start in accounting (Tally or Zoho Books) and sync into the programme or grant system. Sync direction and frequency is a design decision, not a detail.
• Shared costs get apportioned. A programme manager on three projects at 40/35/25 is split across three grants. No timesheets? Then a quarterly staff-project matrix.
• Admin is capped. Donors often cap indirect costs at 5 to 15%. FCRA caps administrative expenses at 20% of foreign contributions received in the year.

Where it breaks

• A training request goes through without checking the remaining budget line, and the PM quietly moves it to another head. That's the request ↔ budget seam.
• Expenses are booked in Tally without a project code and reconciled by hand at year-end.
• FCRA and domestic money are mixed at the budget level, which makes FC-4 painful.

6 · Utilisation and reportingAnswering the ₹1 crore question

Two journeys, one story

A good utilisation report reads like this:

7 · ComplianceThe rules that shape a design

Keep this at "what it means for the system". Recheck the exact rules before advising a client; these are the details a client will test you on.

8 · Go furtherWatch and read

• Results
  Educate Girls Development Impact Bond final results, UBS (2018). Short, with the numbers.
• Research
  Bridging the gap on funding the true costs of NGOs in India, Bridgespan. The Indian evidence on underfunded indirect costs.
• Example
  The 100% model, charity: water. How they separate operating and project money.

1 · The journeyEvery programme has roughly the same shape

The shape of a real funnel

An illustrative skilling programme. The red bars are the stages with the steepest drop from the one before.

Each gap is a question a programme manager should be able to answer, and one our system should help with: who dropped, where, why, and what did we do about it?

Donors fund the top of this funnel. They judge you on the bottom. The system lives in between.

2 · Outputs vs outcomesThe most important distinction in the sector

• Outputs come from transactional data (attendance, deliveries) and can be counted automatically.
• Outcomes need a later event: a follow-up call, an endline assessment, a placement check. No follow-up entity in the data model means no outcomes, only outputs dressed up.
• Most "we need a dashboard" requests really mean "we can't count outcomes because nobody records follow-up".

3 · Sector patternsThe same shape in different clothes

From EdZola's ImpactOS entity library. The coral entity is the spine everything hangs off.

4 · Five rulesWhat makes journey data work

Rule 1: One person, one record

Sheet "CSR Co A 2025":  Priya S, 14
Sheet "Foundation B":   Priya Sharma, 14
Sheet "Baseline":       P. Sharma, age 13

→ counted 3 times, with 3 ages

BEN-00417  (one record)
 ├── Project: CSR Co A FY25
 ├── Project: Foundation B FY25-27
 ├── Assessment: Baseline
 └── Attendance: 38 sessions

Use a stable unique ID, duplicate checks (name + date of birth + guardian + village), and relationships instead of copies.

Rule 2: Status is a journey, not a checkbox

• Never just Active/Inactive when there are more real states.
• Every end state carries a reason from a master list: migrated, married, got a job, lost interest, family objection.
• Status changes are dated, so you see when people left, not just that they left.

Rule 3: Every data point earns its place

Name the decision each field serves and who looks at it. Every field is a tax on a field worker standing in the sun with a phone at 12% battery.

Rule 4: Data flows back

If the field officer who enters attendance never sees her own batch's attendance trend, the system is extractive. Adoption drops, data quality drops, and then the donor report is wrong. Design the field officer's view first.

Rule 5: Design for the real field

• Offline-first mobile forms that sync later
• Local language labels
• Photo and geo-tag where donors require it, not everywhere
• Fewer free-text fields, more dropdowns from master tables

5 · Consent and dignityNot optional, and not just a legal box

6 · Two journey typesCohorts vs case management

Clients often don't say which one they are. Ask.

A child development centre runs case management: each child has an assessment, an individual plan, therapy sessions across disciplines, and review points. Design it as "batches" and it breaks on day one.

7 · Your turnWalk the journey

8 · Go furtherWatch and read

• Explore
  Teaching at the Right Level, Pratham. How the approach works in classrooms.
• Law
  Digital Personal Data Protection Act, 2023, published by MeitY. Read the consent and data-principal rights sections.

1 · Why measureThree audiences, three purposes

Most NGO systems are built only for the first one. That's why they feel like compliance, and why field teams resent them. A good system serves all three, and management use is what keeps the data honest, because people fix data they rely on.

If data only flows up, people treat it as compliance. If it flows back, they treat it as a tool.

2 · ToC, logframe, indicatorsThe story, the contract and the data model

Theory of Change: the story

Logframe: the contract

Anatomy of a good indicator

The ToC is the story. The logframe is the contract. The indicators are the data model. Writing the definition down is the Model step. Until it's agreed, don't build the dashboard.

3 · Levels of evidenceWhat can you actually claim?

Tap a rung to see the claim it supports and what it takes.

Most client systems live on the bottom two rungs. Our job is usually to move them up one: reliably from outputs to outcomes. That means designing the follow-up and assessment entities properly (chapter 3).

4 · WorkflowsWho does the work

A workflow is a sequence of steps, owned by roles, with rules, approvals and handoffs. The EdZola rule: don't automate ambiguity. If the team can't draw the workflow on a whiteboard, the system will digitise the confusion.

Example swimlane: the monthly field activity plan

The workflows we build most

RACI: make ownership explicit

A RACI is almost exactly a permissions matrix. Flip the view to see it.

R Responsible (does it) · A Accountable (owns the outcome; one person) · C Consulted · I Informed

5 · Decision cadenceDashboards don't make decisions. Meetings do.

Map the meetings and you know what the dashboards need to show.

Dashboard design rules

1. One dashboard, one audience.
2. Answer questions, don't display data. List the 5 to 7 questions first.
3. Summary cards, then trends, then drill-down tables.
4. Remove anything that doesn't drive a decision.
5. Consistent colours: green good, amber at risk, red needs attention.

6 · Data qualityWhy the numbers are wrong

Data quality KPIs worth tracking: completeness (filled ÷ required), timeliness (entered within the agreed time), duplicate rate.

The six reasons data systems fail

Tick the ones you've seen on a real project.

• Data collected without purpose. No decision attached.
• Tool chosen before the problem is understood.
• Process confusion gets digitised.
• Built for donors, not teams.
• Launch treated as the finish line.
• AI added before the foundation is ready.

7 · Your turnBuild a mini logframe, then swimlane it

8 · Go furtherWatch and read

• Explore
  Why randomize?, J-PAL. Free, short explainer on randomised evaluation.
• Explore
  BetterEvaluation. A free library of evaluation methods and tools.

1 · The core ideaModel, Align, then Power

AI doesn't fix a broken data system. It's an amplifier, not a purifier: garbage in, confident garbage out.

Everything in chapters 1 to 4 is Model and Align work. This chapter is about building it well and then powering it.

How MAP maps onto the ImpactOS lifecycle

EdZola's partner engagement process: the prospect shares pain points, walks us through how they work today, we run MAP, prototype, build, and hand over to support and handholding.

2 · Choosing the systemMatch the job to the tool

The most common mistake is forcing one tool to do another's job.

Rule of thumb: CRM when the core object is a relationship that moves through stages (donor, partner). Creator when the core object is a person or activity with complex, custom relationships (beneficiary, session, case). When in doubt, draw the entities first; the tool choice usually becomes obvious.

Beyond Zoho, know these exist: DHIS2 (health information systems), KoboToolbox and ODK (field surveys), Salesforce Nonprofit Cloud, CommCare (frontline health workers). Clients will mention them.

3 · AutomationThe patterns we build most

When not to automate

Automation makes a good process fast and a bad process fast. Make sure it's the good one.

4 · AIWhere it genuinely helps

The AI maturity ladder

Where is your NGO today? Tap its rung.

Examples from the sector

The honesty test

Ask these of every AI idea. Tick them off for one idea you have right now.

• What happens when it gets this wrong? Who is harmed, and how would we know?
• What's the data prerequisite? Usually a single source of truth that doesn't exist yet, which sends you back to Model and Align.
• Where's the human review?
• Is AI even the right tool? Scanning messy paper forms with AI (OCR) is usually the wrong answer; redesign the form and capture digitally instead.
• Whose data is it, and where does it go?

5 · Safe AI and DPDPThe rules we live by

Your name on it means your responsibility. AI doesn't transfer accountability.

6 · Putting it togetherThe three maps, powered

7 · Your turnAI readiness map

That second question is the capstone. Head back to the Three Maps checklist when you're ready.

8 · Go furtherWatch and read

• Paper
  Technology as amplifier in international development, Kentaro Toyama (2011).
• Explore
  Wadhwani AI and Khushi Baby. Two Indian examples of narrow, well-scoped AI and data work.

The instinct"Why don't they just…"

Every new joiner from another sector says some version of this in their first week:

The instinct is well meant, and part of it is right: most nonprofits genuinely could use their data far better. What's wrong is the diagnosis. Nonprofits aren't behind because people there are less capable or less willing. They're behind because the conditions they work in are different, and most technology (and most consultants) are designed for conditions they don't have.

Nonprofits don't lack software. They lack the money, time, people and process clarity that make software stick.

The constraintsTen things that are structurally different

Tap each constraint to see what it means in practice and what to do about it.

Side by sideCorporate assumption vs nonprofit reality

Boiling the oceanWhy trying to fix everything at once fails

A typical "transform everything" plan looks like this: new CRM, new MIS, new HRMS, new dashboards and an AI layer, all in one financial year. Here's what usually happens next.

One pot at a time

The alternative is less exciting and far more likely to work.

What transfersYour corporate experience isn't wasted

Plenty of what you know is exactly what nonprofits need. It just has to be applied at the right size and pace.

Your first weekFive habits for people new to the sector

1. Visit the field before you design anything. Sit with a field officer for a day. Watch where the data actually gets written down.
2. Learn their words. Participant, learner, member, child. Use theirs, not yours.
3. Ask about the last system. "What did you try before, and what happened?" The answer tells you what they're afraid of.
4. Find the calendar. When are reports due? When does the CSR money arrive? Plan around it.
5. Assume competence. The workaround that looks messy usually exists for a reason. Find the reason before you remove it.

Go furtherWatch and read

• Article
  The Nonprofit Starvation Cycle, Stanford Social Innovation Review (2009). The single best explanation of why NGOs underinvest in systems.
• Research
  Bridging the gap on funding the true costs of NGOs in India, Bridgespan.
• Book
  Geek Heresy: Rescuing Social Change from the Cult of Technology, Kentaro Toyama (2015).