Opening a Branch Is a Project, Not a Budget Line
A new branch is the largest discretionary decision a SACCO board makes, and it is usually tracked as a budget line called "branch expansion" — here is why it has to be a project, and exactly how far a project model carries you.
Two years after a branch opens, somebody at an AGM asks what it cost. The answer is almost never available. There was a board paper with an estimate, there were payments spread across eleven months and six expense categories, some of the fit-out was capitalised and some was not, the launch event was coded to marketing, and the two staff recruited three months early sat in the general wage bill. The branch cost something. Nobody can say what.
This is a tracking failure rather than a governance one, and it has a specific cause. A branch opening is a bounded piece of work with a beginning, an end, a budget and a mixed cost base — labour, purchased goods and services, materials from your own store, and standalone expenses. That is the definition of a project. Recording it as a budget line called "branch expansion" throws away the boundary, and once the boundary is gone the total can never be reassembled, because the individual transactions look identical to routine operating costs.
Why a budget line cannot hold it
A budget in most operations systems, including ours, is scoped by a department and a spend category, for a period. Every one of those three things works against you here. The department is the wrong unit: the new branch is not a department yet, and the costs are incurred by whoever incurs them. The category fragments the total: partitioning is joinery, cabling is ICT, the counter is furniture, the licence is legal, and no category holds the branch. The period truncates it: a fit-out spanning eleven months crosses a budget year, so the figure resets halfway through the thing you were measuring.
A project inverts all three. It is not bound to a department, it accepts costs of any category, and it has no period at all — it runs from its start date to whenever it finishes, which is exactly the shape of the work. This is worth understanding as a general principle rather than a workaround, because it applies to every bounded, multi-channel spend a SACCO undertakes: an ICT migration, a rebrand, a members' education campaign, a head-office relocation. It is the complement to the recurring-cost discipline in SACCO expense control — envelopes for the spending that repeats, projects for the spending that ends.
The four components a project adds up
This is the figure a project actually produces, and it is worth being precise about one thing in it: the purchases component counts orders once they are approved, not once they are paid. That is the right behaviour for a board question — a signed order for joinery is committed money whether or not the invoice has arrived — but it means the number is a commitment figure rather than a cash figure, and the two will differ at any given moment. Say which one you are quoting.
What the model gives you, layer by layer
The container
A project with a name, a code, an owner, a start and due date, a status, and an optional department and customer. This is the boundary that makes the total reassemblable, and it is the whole reason to bother.
One budget figure
A single budget amount, plus a separate budget in hours. Consumed percentage, remaining, and an explicit over-budget figure with the overrun stated.
Four-channel actual cost
Labour from logged time at a cost rate, purchase orders once approved, material issued from your own store at unit cost, and standalone expenses. The four components are shown separately and add to the total.
Approval discipline on the way in
Every purchase order on the project went through a requisition, a threshold and an approval chain it could not skip. The project total inherits that governance rather than needing its own.
Payments to people outside payroll
A payout run against the project, drafted from unpaid hours or from manual lines, moving draft to approved to posted, and landing in the payments register. Useful for the contractors and casuals a fit-out attracts.
Phased or category-split budget
The budget is one scalar. You cannot budget 4M for civil works and 3M for ICT and see each against its own line — there is no category breakdown and no milestone phasing inside a project.
A budget per period inside the project
No monthly or quarterly profile, so there is no planned-versus-actual curve over time and no early warning from a burn rate. You see consumed against total, at whatever point you look.
Capitalisation into the asset register
Nothing turns project spend into fixed assets. The safe, the counters and the generator must be registered as assets separately, by hand, and nothing reconciles the asset values back to the project total.
The branch as an entity
There is no branch object. After opening, the branch becomes a department, a location or a warehouse by convention, and the project that built it does not become the thing that runs it.
A hard stop at the budget
Exceeding a project budget is visible, and visible is all it is. Nothing blocks the next order, so the discipline remains the approver reading the number before signing.
The two gaps that matter most are the phased budget and the capitalisation, and they matter for different reasons. The missing phasing is an inconvenience with a decent workaround: run the fit-out as several projects — civil works, ICT, furnishing, launch — and you get your category split back, at the cost of having to add four numbers for the board total. That is a reasonable trade and many organisations should simply do it.
The missing capitalisation is more serious and deserves an explicit decision rather than a discovery. When the fit-out is finished you have a project total of ten million and an asset register that knows nothing about it. Somebody has to sit down, decide which components are capital and which are expense, register the capital items individually with custodians and locations, and reconcile the registered values back to the project. Nothing prompts this, nothing checks it, and if it is not done in the month the branch opens it will not be done. Put it in the project plan as a task with a named owner, because it is the step that everyone forgets and the auditor always finds.
A single small branch, under three million, opening inside one quarter
One project, no phasing
Create one project with the total budget and code everything to it. The category split is not worth four projects at this size, and the whole thing closes before a budget period boundary complicates the reporting. Register the capital items in the month it opens.
A full branch fit-out spanning several months and cost types
Four projects under one naming convention
Split into civil works, ICT, furnishing and launch, each with its own budget, all sharing a name prefix so they group on a report. You get the category control the single budget figure cannot give you, and the board total is a four-row addition rather than a reconstruction.
A branch relocation rather than an opening
Two projects, deliberately separated
One for the new site and one for the exit — dilapidations, restoration, disposal of fittings. Exit costs are systematically underestimated and get quietly absorbed into the new site's figure, which flatters the relocation decision and misleads the next one.
A pilot or satellite you may close within a year
One project, and keep it open
Do not close the project when the site opens. Keep coding the running costs to it so that if the closure decision comes, the total cost of the experiment is a number rather than an argument. This is the one case where the project is a reporting unit for the life of the site, not just the build.
The board paper this makes possible
The reason to do any of this is a single page at a board meeting: approved budget, committed to date, spent to date, remaining, and the four components of the total. That page changes the conversation from whether management is being careful to whether the branch is on plan, which is a decision the board is actually equipped to take. It also makes the post-implementation review possible eighteen months later, and a SACCO that can compare the projected cost of a branch against its actual cost is a SACCO that gets better at opening them.
One honest caveat about that page: the income side of the branch — deposits mobilised, loans disbursed, interest earned — is not something an operations system can see. It lives in your core banking system, and the payback question needs both halves. What you get here is a defensible cost. The return is a figure you bring in and combine, and that is the right division of labour rather than a shortcoming to be engineered around.
What AWRA OpsHub does today
- A project with a budget amount and a four-component actual cost — labour from logged time, approved purchase orders, material issued from your own store at unit cost, and standalone expenses — with consumed percentage, remaining, and the overrun stated explicitly when there is one.
- Every component visible separately on one view, so the total is auditable rather than a single figure you have to trust.
- Procurement governance inherited: requisitions that cannot skip approval, value thresholds, RFQ comparison and supplier prequalification on every order coded to the project.
- Payout runs against the project for contractors and casuals — draft, approved, posted — landing in the consolidated payments register, with the option of routing an employee amount through payroll as a taxable earning instead.
- Tasks with owners, due dates and recurrence inside the project, which is where the capitalisation step and the licensing deadlines should live.
- An asset register with named custodians for the equipment once you register it, with movement history and verification dates.
What it does not do
- The project budget is one number. No category split, no phasing, no milestone budgets. Budgeting civil works separately from ICT means separate projects.
- No budget profile over time, so there is no planned-versus-actual curve, no burn rate and no early warning — only consumed against total at the moment you look.
- No capitalisation from a project into the asset register. Not a single field connects project spend to a fixed asset. Registering the assets and reconciling their values to the project total is manual work that nothing prompts.
- No branch entity. After opening, a branch is a department, a location or a warehouse by convention, and the project does not become it.
- No hard stop at the budget. Overrun is displayed, never enforced. The next order goes through.
- No income, no payback, no return. Deposits, loans and interest belong to your core banking system. We hold the cost half only.
- No committed-versus-actual split. Approved order value sits inside the purchases component rather than beside it, so a commitment figure and a cash figure are not separately reported.
The summary a board should hear: we will tell you what a branch cost, accurately, with every shilling traceable to an approved document — provided somebody creates the project before the first payment rather than after the tenth. What we will not do is turn that spend into fixed assets, warn you as the budget burns, or tell you whether the branch was worth it. The first is a task you assign, the second is a number you watch, and the third needs your core banking system.
Our take
Create the project when the board approves the branch, not when the invoices start arriving — that is the entire difference between a cost you can report and one you can only estimate. Split it into three or four projects if the fit-out is substantial, because a single budget figure will not hold civil works and ICT apart. And write the capitalisation into the plan as a task with a named owner and a date, because nothing in any system will remind you, and it is the step whose absence an auditor finds every time.
Track the whole opening in one place
A project with a budget, four-channel actual cost, governed procurement on every order and payout runs for the contractors — the cost half of a branch decision, traceable to documents. Capitalisation and the income side are not built.
See AWRA for SACCOsFrequently asked questions
We already approved the branch and payments started three months ago. Is it too late?
Not entirely, but recovery is manual. Create the project now, then work back through the expenses, purchase orders and stock issues of the last three months and code them to it. Standalone expenses and orders can be recoded; logged time generally cannot be reassigned as cleanly. Expect to reconstruct rather than retrieve, budget a day for it, and treat the experience as the argument for creating the project first next time.
Should the branch be a department as well as a project?
Yes, and for different jobs. The project is the build: bounded, one budget, closed when the branch opens. The department is the ongoing operation: employees carry it, purchase orders carry it, and departmental budgets are set on it. The awkwardness is that a standalone expense carries a project but not a department, so if you want per-branch operating costs after opening you will need a standing project per branch as well. Set both up at the start.
How do we handle staff recruited before the branch opens?
Two defensible treatments, and the important thing is to choose one openly. Either their pre-opening salary is a project cost, on the basis that it was incurred to open the branch, or it sits in the general wage bill and the project holds only non-payroll costs. The first gives a truer total cost of opening; the second keeps payroll reporting clean. What you should not do is decide silently, because it moves the reported cost of a branch by a meaningful amount and nobody reading the figure later will know which convention was used.
Can we see committed spend separately from money actually paid?
Not as two columns on the project. Approved purchase orders count into the purchases component as soon as they are approved, which means the project figure is a commitment total rather than a cash total. If the board needs both, the purchase order list for the project gives you commitments and the payments register gives you cash — two views rather than one number. Be explicit about which one is in the board paper, because a ten-million commitment figure and a seven-million cash figure are both correct and describe different things.
What stops someone coding an unrelated cost to the branch project?
The approval chain on the way in, and nothing else. Whoever approves the requisition or the expense is the control, and after the fact the project cost breakdown makes an odd charge visible because you can open each component and see the transactions. There is no restriction preventing a charge to a project, so a monthly review of the project's expense list by someone other than the person coding it is worth the ten minutes.
Does this work for an ICT project like a core banking upgrade?
It works well, and better than for a fit-out in one respect: an ICT project is mostly purchased services and licences, which flow through procurement and are therefore fully governed and traceable. The gap that bites instead is the phased budget — an upgrade with an implementation phase, a licence cost and a support tail really wants three budget lines, and it will need three projects. The capitalisation problem is identical, and arguably worse, because deciding what portion of a software implementation is capital is a judgement your auditor will want documented.
How do we do the post-implementation review properly?
Set the comparison up at approval, not at review. Record in the board paper the projected cost, the projected timeline and the two or three operational assumptions the case rests on — deposits mobilised in year one, break-even month, staffing level. Eighteen months later the project gives you the actual cost with its components, and your core banking system gives you the actual income. The reason so few reviews happen is not laziness; it is that nobody wrote down the prediction in a form that could later be tested.
