One Project, Three Funders, One Customer Field
A project in our system has one customer. Organisations running one project on money from three funders need to say that a single cost belongs to all three, in different proportions — and our schema has nowhere to put that sentence.
Project management software is built almost entirely around an assumption so ordinary that nobody states it: a project has one paying counterparty. A client commissions work, you track the cost of delivering it, you bill them, the margin is the answer. Every field in the schema follows from that shape. It is the right shape for a consultancy, an agency, a contractor — and it is the wrong shape for a great deal of the work that actually happens in Central Africa and anywhere else where the money arrives as grants.
A single programme — a health outreach across four districts, a water scheme, an agricultural extension effort — is routinely funded by several organisations at once. Each of them pays for a portion. Each wants to know what its portion bought. And critically, they do not each fund a different activity that can be filed separately: they co-fund the same activities, and the vehicle, the coordinator's salary and the fuel are shared costs that have to be divided.
The finding, stated plainly
A project in AWRA carries one customer. There is no funder concept in the schema at all — no funder record, no funding source on a cost, and no way to express that one expense belongs 40% to one organisation and 35% to another. We checked before writing this rather than after somebody asked.
Why one field cannot be made to do it
The obvious workaround is to stop thinking of it as one project. Create three projects, one per funder, and post each cost to whichever one is paying. It works, right up to the first shared cost, and then it produces two wrong answers at once.
One vehicle, three funders, and the arithmetic that follows
Option B is the one most organisations end up on, and it deserves a closer look because it is usually described as a workaround rather than as the loss it is. Splitting the programme into three funder-shaped projects means the programme itself no longer exists as an object. Nobody can ask what it cost, whether it is on schedule, or how much of it is done, because there is no longer an "it" — there are three accounting fictions that happen to share a coordinator.
That is the same mistake in the opposite direction from the one we made when arguing that a project is the right unit of account for grant reporting. It is: the project is what the funder reports on. The correction this post adds is that the project is not what the funder owns, and collapsing those two ideas into one field is what produces the choice above.
What we do have, and what it is actually for
The customer on a project is not useless and this post is not an argument for removing it. It carries real weight: it is what makes time entries billable, what lets a cost rate and a bill rate diverge, and what connects delivered work to an invoice. For an organization doing paid client work it is exactly the right field.
It is simply not a funder, and the difference is not terminology. A customer is billed for work and pays what is invoiced. A funder commits an amount in advance, restricts what it may be spent on, wants a proportion of shared costs attributed to it, reports on a calendar it chose rather than yours, and expects unspent money to be accounted for rather than kept. A field designed for the first cannot be relabelled into the second.
The general version, which is not about grants
Any time a system gives a record one owner field, ask whether the real world ever gives that record two owners. Shared costs, joint ventures, co-branded stock, jointly-held equipment, split commissions — they all have this shape. A single foreign key encodes an assumption of exclusivity, and exclusivity is a claim about the world, not a technical detail.
What the missing dimension would have to be
Naming what is absent precisely is more useful than promising it, so: what is missing is not a funder field on a project. Putting one there would recreate the same problem one level up — a project with one funder instead of one customer.
What is missing is an allocation between a cost and several funding sources: a set of proportions that sum to the whole, attached to the cost rather than to the project, so that one expense can appear in three funder reports at three different values and in the programme total exactly once. Everything else a multi-funder organization needs — restricted-spend checks, a funder's own reporting period, unspent balances — hangs off that one relationship. Without it, each of those has to be reconstructed by hand in a spreadsheet, which is precisely where this work is being done today.
We would rather write that paragraph than a roadmap date. What we can say honestly is that the gap is understood at the level of the missing relationship rather than the missing screen, which is the difference between something that can be built correctly and something that will be bolted on.
The question to ask anybody, including us
Every project tool demonstrates well against a single-client project, because that is the shape they were all designed for. The demonstration will not tell you whether the multi-funder case works. These will.
- Ask them to post one cost to two funders at 60/40, then show you both funder reports and the programme total. Not a description — the three figures. This single request settles it, and it is why the table above is the shape it is.
- Ask what happens to the programme view when you split by funder. If the answer involves creating separate projects, the programme has stopped existing and somebody should say so out loud.
- Ask whose reporting calendar the report runs on. A funder's period frequently is not your financial year and frequently is not the other funders' either.
- Ask what the system does with money committed but not spent. A tool that only knows what was spent cannot tell a funder what is left, which is usually the first question asked.
Our answers, in order: we cannot do the first one — a cost has one owner and 60/40 has nowhere to live; splitting by funder does cost you the programme view, and Option B above is what that looks like; report periods are yours to choose and are not per-funder; and commitments are not modelled, so unspent balances are not either. If you run programmes on money from more than one organisation, that is four honest noes, and they are more useful to you today than a demonstration would have been.
The rest of the projects module — tasks, planning, time against cost and bill rates, budgets — does the work it claims to. This is a missing dimension in an otherwise real module, and the reason it is on the blog rather than in a backlog is that somebody evaluating us for grant-funded programme delivery should find it before they buy, not after.
