A Budget That Warns and a Status That Refuses
This module will refuse to move a project from planning straight to completed. It will not refuse to spend twice its budget. One of those is enforced by a state machine and the other is a percentage on a screen.
Every system draws a line between what it prevents and what it merely records, and the line is almost never where a user expects. Finding it is more useful than any feature comparison.
What is enforced
The project lifecycle. There is a real state machine here with a defined set of permitted moves, and an attempt to make a move outside it is refused.
-
Planning can become active, on hold, or cancelled
What it cannot become is completed. A project cannot be finished without having been started, which is a small rule that prevents a surprisingly common data mess.
-
Active can go on hold, complete, or be cancelled
The ordinary path, and the only one most projects ever use.
-
On hold can resume, complete, or be cancelled
Completing from on-hold is permitted deliberately — work that stalled and was then finished elsewhere is a real situation.
-
Completed can only reopen; cancelled can only revive to planning
Both are one-way doors back to a specific state rather than a free-for-all. A cancelled project returns to planning, not to active, so reviving it means re-planning it.
That is a considered design. The transitions that are missing are missing on purpose, and the two recovery paths land somewhere sensible rather than wherever the project happened to be.
What is not
Anything to do with money.
A project can carry a budget, and there is a figure showing what percentage of it the actual cost has consumed. That figure is a number on a screen. Nothing refuses a purchase, an expense, a stock issue or a time entry because a budget is exhausted.
There are no percentage thresholds, no warning at seventy per cent, no escalation at ninety, and no hard stop at any figure. The availability check that exists elsewhere in the product is binary rather than tiered, and a budget overrun is a warning.
This product's own feature page once claimed otherwise — thresholds, an escalation ladder and hard stops — and that copy was corrected rather than the feature being built, because the honest answer was that none of it existed.
What the projects module prevents versus records
| Action | Refused | Warned | Recorded only |
|---|---|---|---|
| Moving planning straight to completed | Yes | No | No |
| Editing a time entry already invoiced | Yes | No | No |
| Editing a time entry already paid out | Yes | No | No |
| Spending past the budget | No | Partly — configurable by you | Yes |
| Logging time into a closed month | No | No | Yes |
| Issuing more stock than the job needs | No | No | Yes |
Built and maintained Configurable by you, not maintained by us Not built
The top three are refusals in code. The bottom three are things you will find out about afterwards, from a report you have to open.
The state machine will stop you telling a lie about a project. Nothing will stop you spending its budget twice over.
Which is the right design
Both, arguably, and it is worth arguing rather than assuming.
A state transition is cheap to refuse because there is always a legitimate alternative — if you meant to complete a project, activate it first. Nobody is blocked from doing real work.
A budget refusal is different. The material has arrived, the hours have been worked, the invoice is on the desk. Refusing to record it does not un-spend the money; it produces an unrecorded cost, which is worse than a recorded overrun. The same argument appears elsewhere in this product about storage capacity, and the conclusion was the same: warn and measure rather than refuse.
What is missing is not the hard stop. It is the middle: a threshold that warns somebody at seventy per cent, while there is still a decision to make.
The middle, not the hard stop
We would decline to build a refusal and say why. The useful thing is the warning that arrives while the overrun is still avoidable.
A budget threshold that notifies
A percentage per project, or a default across all of them, that raises an alert to the project owner when actual cost crosses it. The notification machinery already runs for six other things in this product; what is missing is the evaluation.
A required note above a stated percentage
Not a refusal — a prompt for a reason when a cost is booked against a project already over its budget, recorded on the transaction. It keeps the record true, which a hard stop does not, and it makes the overrun explicable afterwards.
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. If you want an actual hard stop we will build it and note on the record that we advised against it.
Talk to us about budget controlsWhat AWRA OpsHub does today
- A project state machine with defined transitions, enforced — including no direct path from planning to completed.
- Cancelled projects reviving to planning rather than to active, so a revived project is re-planned.
- Time entries sealed once invoiced or paid out, with edits refused.
- A budget consumption percentage against actual cost, returning nothing when no budget is set.
- Actual cost assembled from logged labour, purchases, booked expenses and issued stock.
What it does not do
- Any refusal, warning or escalation based on budget consumption. No thresholds exist at any percentage.
- Any hard stop on spending against a project.
- Any budget by category, phase or period — a project has one money budget.
- The timesheet month lock on project time.
- Any check that stock issued to a job is proportionate to it.
Not ours, by choice
- A public feature page of ours once described budget thresholds, an escalation ladder and hard stops. None of it existed and the copy was corrected rather than the feature invented. We mention it because the same words appear on a lot of software.
- Declining to build a hard stop is a position rather than a limitation, and it is the same reasoning applied elsewhere in this product: a control satisfied by not recording something is a net loss.
- Nothing here is Mauritian, Seychellois or Malagasy. The Indian Ocean hub carries this because project work there frequently runs on fixed grants and fixed fees, where an overrun has nowhere to go.
Four questions about project controls
What will this system actually refuse to let me do?
A good answer sounds like
A short, specific list.
What it actually means
The best question in any evaluation. A long list is usually aspirational; a short one is usually true.
Does anything happen at 80% of budget?
A good answer sounds like
A notification.
What it actually means
Ours is nothing. "Warn at X, escalate at Y" is one of the most commonly claimed features that does not exist.
What happens when I book a cost over budget?
A good answer sounds like
It records, and warns.
What it actually means
If the answer is a refusal, ask what the user is expected to do with the invoice on their desk.
Can a project be completed without being started?
A good answer sounds like
No.
What it actually means
A small thing, and its presence tells you somebody thought about the lifecycle rather than shipping a status dropdown.
Our position
Treat the budget percentage as a report you open rather than a control that protects you, and put a standing review of projects over eighty per cent into somebody's week — that review is the control until a threshold exists. The state machine, by contrast, you can rely on: it refuses in code, and the transitions it forbids are forbidden for reasons.
Ask what it refuses
Not what it tracks, warns about or reports on. What it refuses. The list is always shorter than the brochure and it is the only part you can depend on.
Talk about project controlsFrequently asked questions
Can I set a budget per phase?
No — a project carries one money budget. Phases and milestones exist as structure but not as budget holders, so a phased budget is something you track alongside rather than inside.
Why does budget consumption return nothing sometimes?
Because no budget is set. A percentage of zero is not a meaningful number, so it deliberately returns nothing rather than a hundred per cent or an error — which is the right call and worth knowing when a tile looks blank.
Would a hard stop be safer?
Usually not. The cost has already been incurred by the time somebody is recording it, so a refusal produces an unrecorded cost rather than an avoided one. A prompt for a reason keeps the record true and still makes somebody stop and think.
