NGO Grant and Programme Management Software Problems: The 7 That Cost Awards, and How to Avoid Them

Why does the build become another dashboard instead of a compliance layer?

Because dashboards are easy to specify, easy to demonstrate and easy to fund. A results visualisation can be described in one meeting, shown to a donor, and put in an annual report. Enforced procurement thresholds cannot, and they make somebody's day slower rather than faster.

The pull is stronger in this sector than most because the funding often arrives as a restricted award with a systems line, and a visible deliverable is politically safer than an invisible one. So the specification describes indicator dashboards, geographic disaggregation and a consolidated results view, and quietly omits the rules that would have prevented the last three findings.

The specific harm is that dashboards do not protect the award. Rules applied at the point of transaction do. A grants director can name their last audit finding without hesitating, and it is nearly always documentation rather than fraud: a purchase needing three quotations with two on file, or a sole source justification given verbally.

The fix is to make the award the configuration object and say so in the first paragraph of the specification. Procurement thresholds, allowable cost categories, prior approval triggers, reporting deadlines and cost share obligations become attributes of the award, enforced in the workflow where the transaction happens. Then build reporting on top of that. If your specification does not contain a sentence about a request being blocked, you are buying a picture of the problem.

What goes wrong when award, budget and expenditure data are migrated?

Currency, and then the chart of accounts. Both look like configuration and both are structural.

Legacy expenditure records typically store one amount in one currency, with the rate applied at reporting time rather than captured with the transaction. Once that history is imported, no view can be reconstructed exactly, so a line that was on budget in local currency shows as an overspend in donor currency and a programme manager spends an afternoon proving that a variance is a rate movement rather than a control failure. Importing the number without the rate basis bakes that argument in permanently.

The chart of accounts is the second trap. Country offices that operate their own charts, or organisations that changed theirs after a restructure, cannot map historic expenditure to current budget lines one to one. Somebody will propose a best fit mapping. Accept it only with the original coding retained alongside, so an auditor can always see what was actually posted.

The workable approach is to migrate the award structure, budgets and open commitments properly, and to import historic expenditure at a summary level marked as such, keeping the finance system as the record for anything older. Every new expenditure carries its original transaction currency and amount, the rate applied, and the rate basis. That single decision is the reason your country directors will trust the system, and no amount of later engineering recovers it if you skip it.

Why do finance and results system integrations break after launch?

Because the two systems either side of your award layer are owned by people who did not commission it, and both change without telling you.

On the finance side, a new cost centre appears, a chart of accounts segment is repurposed, or a period is reopened and reposted after your nightly read has already run. The integration keeps running and quietly produces a budget versus actual that is stale in a way nobody can see. On the results side, DevResults or ActivityInfo receives a framework revision, indicator identifiers change, and your linkage between logframe targets and award reporting starts pointing at the wrong things.

The third failure is authentication. Service credentials expire, a finance system upgrade invalidates a token over a weekend, and the feed stops during exactly the week of quarter end when nobody has time to investigate.

Three defences worth insisting on. Every integration reports its own freshness and raises an alarm to a named person when it goes stale, rather than assuming silence means agreement. Reference data changes, meaning new cost centres, new budget lines or changed indicator identifiers, land in a reconciliation queue rather than being auto accepted or silently dropped. And integration maintenance is a named line in the support agreement, priced per system, because finance system upgrades are not a rare event and someone has to own the consequence.

What happens when subaward monitoring evidence is not covered?

Partners get modelled as vendors, and the compliance lifecycle you are actually responsible for never gets built.

Under United States federal award rules, pass through entities carry defined responsibilities for subrecipient risk assessment and monitoring, and equivalent expectations exist under other major funders. In practice that means a pre award capacity assessment, a risk rating, a monitoring plan proportionate to that rating, spot checks, an advance and liquidation cycle, and evidence that you did all of it. Project tools model a partner as a stakeholder. Finance systems model them as a payee. Neither produces the record an auditor asks for.

What that costs in practice is not theoretical. The programme team approves the next advance without checking the last liquidation, because checking takes twenty minutes and the partner has staff to pay. Nobody is being careless. The system simply does not make the check the path of least resistance.

Require the subaward as its own object with a lifecycle: capacity assessment producing a risk rating, the rating driving a monitoring schedule, monitoring visits generating findings with corrective actions and due dates that escalate, an advance ledger, and a hard block on the next tranche until the previous liquidation has been reviewed and the outstanding balance is within policy. Then when an auditor asks how you monitored a partner, you produce the record rather than the intention. This is also where document extraction earns its place, turning scanned liquidation packages into draft expenditure lines with vendor, date, amount and currency for a finance officer to confirm.

Should you build custom or configure what you already own?

If you run fewer than about six concurrent awards in one or two countries with few or no subawards, configure and stop there. DevResults or ActivityInfo for results, a competent finance system for money, and a disciplined grants manager will carry you, and a custom build at that scale is an overhead you will come to resent. TolaData is worth a look if budget is tight and your indicator work is straightforward.

Before commissioning anything, be honest about what your existing tools already do. DevResults and ActivityInfo are genuinely good at indicators, results frameworks and geographic disaggregation, and most organisations use a fraction of their configuration. If your problem is that indicator data is hard to collect, that is a configuration and training problem, not a build.

Build when two or more of these are true. You run more than fifteen concurrent awards across several country offices. Your funders impose materially different procurement and cost rules and field staff cannot see those rules at the moment of decision. You pass funds to partners and your subrecipient monitoring evidence would not survive scrutiny. Your award burn rate is always weeks stale. Or a finding has already landed on procurement or subaward monitoring.

Even then, keep your results system and keep your accounting system. Build the award compliance and consolidation layer between them. That removes both the riskiest engineering and the most painful migration.

How do hidden costs get into the quote?

A first release covering award records with donor rules as enforced configuration, multi currency budget versus actual synchronised with your accounting system, indicator targets tied to the results framework, and a subaward register with risk rating runs $85,000 to $170,000 and ships in 14 to 20 weeks in Digital Heroes delivery experience. A full platform adding procurement workflow, partner advances and liquidations, offline approvals, cost share and donor report generation runs $220,000 to $550,000 over 9 to 14 months.

Four things hide inside those numbers. The number of distinct funders, because each one's procurement rules, cost categories and report formats are separate work with no shortcut, and a quote priced for two funders that meets five is not a quote. Accounting system integration, which varies enormously depending on whether your system exposes a usable interface, and which nobody can price without looking at it. Offline capability for approvals, frequently deferred and then discovered to be the reason the system is bypassed. And donor specific report generation, where each output format is its own small project.

Ask for funder count, named accounting system, offline scope and report formats as explicit line items. The largest schedule risk is not engineering at all: it is getting the donor rules written down, because they currently live across award agreements, a compliance matrix and the grants director's judgement.

What separates a build that works from one that fails here?

Field offices use it, or it does not exist. A system requiring a stable connection to approve a purchase request is bypassed within a month, and the bypass is a message on a phone followed by retroactive data entry, which is worse than no system. Request creation, evidence attachment and approvals must queue locally and sync, with a clear conflict rule when approvals arrive out of order.

Delegation is recorded rather than shared. A country director travelling for a week delegates authority with a limit and an expiry, as an act the system records. The alternative is a shared password, and that is precisely what an auditor tests.

Variance is explainable. Budget versus actual shows rate effect as its own line rather than as unexplained movement a programme manager has to defend. If the first person to open the system does not trust the numbers, nobody opens it twice.

Ask the developer to model the award before you sign. A firm that has done this draws an award with donor rules as configuration, budgets in multiple currencies with a rate basis, an expenditure carrying its original transaction currency, a subaward with a risk rating driving a monitoring schedule, and a procurement record with threshold logic. A firm that draws projects and tasks has built a project management tool and will hand you a prettier version of the problem you already have.

Finally, own the repository and the infrastructure accounts, agreed in writing before kickoff. When a single restricted award funds a systems build, a vendor holding your code puts your compliance infrastructure inside someone else's commercial decisions.