Capex governance
A capex policy sets the rules. Capex governance is whether they hold when nobody is checking.
How the rules are set
In Weissr Capex the authority rules are part of the system, from the current long-term strategy down to the person who signs off the last overrun.
An approval route sets who must sign off on an investment, and in what order. Thresholds and other criteria decide when a given route applies.
Approval rights go to groups and sit on positions in the organisational structure. Sites follow the same authority matrix rather than maintaining separate interpretations. A new unit added to the structure runs on the group's rules from the start, and users with rights to that unit, or higher up, and the relevant roles can work in it straight away.
Setting up the rules carries no right to use them. Administrative access approves nothing until approval rights are granted on a position.
Compliance stops being your personal work. You set the rules, and you change them when the policy changes.
Governance in Weissr Capex
A request moves through preparation and decision, execution, then follow-up. It may return for rework inside a phase, but never between phases.
Two site managers can hold the same limit and still be unable to approve each other’s requests. Rights are held on a position, and every request belongs to one position.
Routing follows the request as it stands today. When it stops matching its route, it moves to the route it now belongs to.
Conditions are checked at every step. If one is not met, no approver can be selected and the failed condition is shown.
Fields made mandatory at one step remain mandatory afterwards. Document templates keep the case consistent between sites.
A route can require the current approver to name who takes the next step before confirming the decision.
Execution
Capex governance often stops at the original decision. In Weissr Capex the approved figures become fixed, and the rules keep working for as long as the money moves.
Each action is a request of its own. The permissions are separate, so authorising extra capital and moving capital between projects remain different mandates.
Strategy and budget
A group sets the long-term direction for its asset base, and the budgets and categories that govern later requests follow from it. Thresholds and authority levels follow your own internal policies. All of it is in place before anyone submits a request.
Where that strategy is builtNamed rights determine who may build it at group or division level.
Only the strategy marked as current reaches capex requests.
Allocation pools have owners, and transfers are decisions in their own right.
Both decisions must stand before a request moves into execution.
Evidence in Weissr Capex
The record builds as decisions are taken. Answering an auditor means opening the request, not reconstructing it.
A copy of the whole request at every step forward, with the person assigned to decide and the person who did. A rejected request keeps all its justification data.
Every change to the request and its numbers, with the value before, the value after, the date and the user. Searchable.
A route step that has been used stays visible on the requests that passed through it. Approved requests cannot be deleted with ordinary rights.
Changes to settings and permissions remain recorded. Approval history can be read directly by your ERP.
Weissr Capex governance end to end
| When | What is governed | How it holds in Weissr Capex |
|---|---|---|
| Before a request exists | Which approvals an investment needs, by value and category, and who may give them | Routes and thresholds set in advance, with approval rights held on positions |
| While it is prepared | What has to be in the request before approval | Required fields and templates present the case consistently from every site |
| At each decision | Whether the person deciding holds authority for the request and the amount | Rights, route and conditions checked at every step |
| After the decision | What happens when cost changes | Approved figures fixed and additional funding approved in its own right |
| Years later | Who approved what, when and on what basis | The request stored at every step with the assigned and actual decision maker |
Guides and reports
Report
A framework for judging how your organisation plans, prioritises and governs capital, and what the next level of control looks like in practice.
Download the report →
Guide
What to check when choosing capex software for approvals, audit trails and authority rules, and how to compare vendors on what matters.
Download the guide →Capex Maturity Assessment
Answer a short set of questions on process, data, visibility and cash flow, and get a report showing your level in each area.
Take the assessmentCapex governance FAQ
An approval workflow moves one request through a sequence of approvers. Capex governance covers how the rules are set, whether they apply without anyone remembering to apply them, whether they hold once the cost has changed, and whether the decisions can be evidenced afterwards. A workflow is one part of that. In Weissr Capex the rules are configured before a request exists, applied at every step it takes, and kept in the record once it is closed.
The budget decision and the project decision are separate in Weissr Capex, and a request needs both before it moves into execution. A budget allocates capital to a unit or category. Nothing is released until an individual request is approved inside it.
Nothing prevents the cost from rising. What it does is make sure the increase is approved rather than absorbed. Additional funding is a separate request with its own approval, routed on the new total rather than the original figure, so a project that crosses a threshold goes to the level that threshold requires. That also means the overrun reaches someone who can still decide to continue, pause or stop.
Yes. A shorter route can be set up for a given type of expenditure, so urgent investments of that type go through the steps they need without the full route. The thresholds and conditions on that route still apply, and the decision is recorded in the same way.
An ERP authorises a transaction against a cost centre once there is something to post. A capex decision is taken much earlier, on a business case rather than an invoice, before the scope is fixed and before any supplier exists. The two govern different moments. Weissr holds the investment from first idea to close-out, and actuals flow back from the ERP so nothing is keyed in twice.
See how your approval limits, group structure and budget rules would work in Weissr Capex.
Book a demo