Charging Costs to the Right Job: Procurement, Stock, Time & Expenses
A cost that lands nowhere lands in overhead — and overhead is where project profitability goes to hide. The four routes cost reaches a job, and the one-field rule that closes all of them.
There is a number in almost every Kenyan organization that runs projects, and it is called overhead. Some of it is genuinely overhead — rent, insurance, the accounts team. But a large share of it is project cost that arrived without a job attached, got absorbed because it had to go somewhere, and now makes every individual project look better than it was while the business as a whole looks worse than it should.
This is the most common reason a portfolio of profitable-looking projects adds up to a disappointing year. Nothing is being stolen and nobody is incompetent. Costs simply arrive by four different routes, and only some of those routes ask which job they belong to.
The four routes cost reaches a project
Every shilling a project consumes arrives one of four ways. The discipline is identical each time — name the job at the point of entry — but each route fails differently.
-
Procurement — bought specifically for the job
A requisition or purchase order for this project. Easiest to get right and the one most often captured too late: if the project is only named on the invoice, you have lost the commitment for weeks.
-
Stock — issued from your own store
Material you already owned, leaving the store for a site or a job. This is the leak that feels controlled: the issue IS recorded, just not against a project. "Issued to the site" is untraceable the moment there are two sites.
-
Staff time — the largest and least visible
People are usually the biggest project cost and the one that lands nowhere by default, because salary is a monthly total. Time against tasks, costed to the project, is what makes a project cost real.
-
Direct expenses — the small ones that add up
Travel to site, per diems, transport, printing, subsistence. Individually trivial, collectively significant, and almost always coded to a general expense account because the claim form never asked which project.
A cost without a job is not an accounting problem. It is a decision you will make wrongly later, with confidence, because the number you based it on was flattering.
The one-field rule
Almost all of this is solved by a single rule, applied without exceptions: nothing gets committed, issued or claimed without naming a project or being explicitly marked as overhead.
The important half of that sentence is the second half. If "no project" is simply allowed, everything ambiguous drifts there. If choosing overhead is a deliberate, visible selection, ambiguity becomes a question someone answers at the moment they still know the answer. It is the same field either way; what changes is that silence is no longer an option.
Project field optional
- Anything ambiguous goes unassigned, because that is the path of least resistance
- Overhead grows steadily and nobody can decompose it
- Every project reports a margin over its direct costs only
- The business result never reconciles to the sum of its projects
- Allocation happens at month-end, by someone guessing from descriptions
Project field required
- Ambiguity becomes a question at the moment someone knows the answer
- Overhead is what somebody deliberately chose to call overhead
- Project margin includes materials, time and expenses
- Project results roll up to something recognisable as the business
- Allocation is a by-product of normal work, not a monthly exercise
Expect a week of friction
Requiring a project on every issue, order and claim is mildly annoying for about a week and then becomes invisible. Every organization we have watched do this reported the same two things: brief irritation, followed by the first genuinely accurate job costing they had ever seen — and usually one uncomfortable discovery about a client or a type of work they had assumed was profitable.
Shared costs, honestly handled
Some costs genuinely serve several projects. A vehicle covering three sites in a day. A site supervisor across two jobs. A bulk purchase drawn down by four projects over a month. Pretending these belong to one job is as wrong as leaving them unassigned.
Two honest approaches. Split at entry where the split is knowable — a delivery covering two sites is two lines. Or allocate by a stated driver where it is not: supervisor time by days on each site, vehicle cost by trips, bulk stock by quantity drawn. What matters is that the driver is written down and applied consistently, because an allocation rule that changes when the results are unwelcome is not a rule.
For donor-funded work this is a compliance matter rather than a management preference — shared-cost allocation methods usually need documenting and defending to an auditor. The practice is set out in multi-donor fund accounting and, for cross-office costs, in multi-country NGO operations.
The test that tells you whether it works
Pick a finished project and add up everything charged to it: procurement, stock, time, expenses and allocated shared cost. Compare that against what the project earned. Then do the same for every project in a period and compare the total against the business result.
If the sum of your project results looks nothing like your business result once genuine overhead is added, your allocation is leaking — and the gap tells you how much. Most organizations doing this exercise for the first time find the gap is large and sits mostly in staff time. That is uncomfortable, and it is the most valuable number the exercise produces.
What we do and do not do
What AWRA OpsHub does today
- Procurement tied to a project at requisition and order, so commitment is visible before the invoice — approved and completed purchase orders count toward project spend.
- Time entries costed to the project, whether billable or not.
- Expense claims coded to a project, so travel and per diems land on the job.
- Budget vs committed vs actual per line, on one view, while the job runs.
- Grant and budget-line tagging where the funding source matters.
- Stock issued from your own store, charged to the job. A check-out can name the project it is for, and the unit cost is stamped on the line at the moment of issue — so the job carries what the material actually cost that day, and a later purchase that moves your weighted average does not quietly rewrite the cost of a job that closed months ago.
More we can add to your workspace
- Only issues, not transfers. A check-out can carry a job; a warehouse-to-warehouse transfer cannot, because moving stock between your own stores is not consumption.
- Issues raised before this existed carry no stamped cost and are skipped rather than valued at today's average — an old job will not retrospectively gain a material line.
- Fixing a project structure that fails to reflect how you work is a decision we decline to make for you — if the project list is wrong, allocation to it will be too, and the list is yours.
Where we point you to a specialist
- We do not invent allocation rules for you. Drivers for shared costs are yours to define and defend.
- We do not compute statutory overhead absorption for financial-reporting purposes — that is your accountant's treatment.
- We do not do BQ measurement or take-off on construction work.
How costs should be treated for statutory financial reporting is your accountant's call and can differ from the management view described here. Confirm the treatment with them.
Anything above that you need, we can build for you
Everything listed above as something we can add describes what ships in the standard product today — it is a starting point, not a limit on what AWRA OpsHub can do for your organisation. Kenya's eTIMS integration and its maintained payroll engine are both in the product because clients needed them and commissioned them; neither appeared by itself, and the same door is open for whatever you just read about. One qualification so this is worth what it claims: a small number of things on this blog we deliberately leave to a specialist rather than build — a statutory ledger we will not sign our name to, a rule that would decide a tax question for you, a clinical or member-funds record that belongs in a regulated system — and where that is true the post says so in those words. Everything else is a scope, a timeline and a price.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
The module-shaped additions, which are the ones readers ask for most often
A price list with real discount authority, a customer-facing quotation that expires, a bill of materials or recipe costing, a staff advance that is issued, acquitted and chased, a member or unit ledger, a matching rule that holds a payment. Each of these is a build rather than a setting, and each has been quoted before — a bigger piece of work than a custom field, with a written spec and a date instead of a roadmap slide.
The report, document or pack nothing currently produces
The board pack in the shape your board actually asks for, a donor or funder layout, an invoice or receipt template carrying what your regulator or your customer expects, a dataset the report builder cannot reach yet. Usually the fastest thing on this list to deliver, because the data is already in the system.
Systems, rails and hardware you already run
The accounting package, CRM, online store, core banking or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed. Plus the physical edge: a scanner, a scale, a weighbridge or a till peripheral feeding the door it belongs to.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. Nothing here waits on a regulator or a published specification, which is why operational builds are the ones we quote fastest. Tell us the requirement that would otherwise rule us out — that is a better first conversation than a demo.
Tell us what your operation needsWhere to start
Do the easy route first. Making the project field required on purchase orders is a configuration change with a week of grumbling attached, and it typically recovers the majority of the invisible cost on its own. Time comes next, because it is the biggest but needs a behaviour change. Expenses last, because they are the smallest.
Material drawn from your own store is the awkward one, because it does not carry a project today. If a material job is largely supplied from existing stock, the workable pattern is to buy against the project rather than draw from general stock where the job is big enough to justify it — and to treat the store draw as a known blind spot rather than assume it is being captured.
Then read the results weekly rather than monthly — project budget vs actual covers the reporting rhythm, and project management software in Kenya the module as a whole.
Our take
Make the project field mandatory on purchase orders this month, with overhead as a deliberate choice rather than a default. It is the cheapest change on this list and it usually reveals that one client, one service line or one site was never profitable. That finding is worth more than a year of better estimating. Then decide deliberately how you will handle material drawn from your own store, because that route does not carry a project and will otherwise quietly understate your material-heavy jobs.
See every cost land on the right job
Procurement, staff time and expense claims all coded to the project that caused them — with budget, committed and actual on one view.
Explore AWRA ProjectsFrequently asked questions
What is the single biggest source of unallocated project cost?
Staff time, by a wide margin. Salaries arrive as a monthly total and land nowhere near a project unless time is captured against tasks and costed, so the largest cost on most jobs is missing from all of them. This is why organizations find that individually profitable projects add up to a business that is not — each project shows a margin over its direct costs while the entire salary bill sits outside every one of them.
How should we handle a cost that serves several projects?
Either split it at entry where the split is knowable — a delivery covering two sites becomes two lines — or allocate it by a stated driver where it is not, such as supervisor time by days per site or vehicle cost by trips. The critical part is that the driver is written down and applied consistently, because an allocation method that changes when the results are unwelcome is not a method. For donor-funded work, expect to document and defend it to an auditor.
Should we force a project on every transaction?
Yes, with overhead as an explicit, visible option rather than a blank. If leaving it empty is permitted, everything ambiguous drifts there and overhead becomes an undecomposable lump. Making overhead a deliberate selection turns ambiguity into a question answered at the moment somebody still knows the answer, which costs seconds and saves a month-end guessing exercise.
How do we know whether our allocation is actually working?
Add up every project result for a period, add genuine overhead, and compare the total against your business result. If they look nothing like each other, cost is leaking out of your projects and the size of the gap tells you how much. Most organizations running this test for the first time find a large gap concentrated in staff time — which is uncomfortable and is precisely the number that makes the case for fixing it.
Our project list does not really match how we work. Does that matter?
It matters more than the allocation mechanics. If projects are defined at the wrong granularity — one project covering work you actually manage as three, or thirty projects for one engagement — then costs will be allocated accurately to a structure that cannot answer your questions. Fix the structure first, at whatever level you actually make decisions and win work, then allocate to it.
