Koldheim · Citrine

Spend Requests

Operations

Spending that cannot quietly go over budget.

Know what is left in the budget before anyone approves.

A request carries its lines, quantity, price and VAT, against a cost centre. The budget is checked when it is raised and the money is committed the moment it is approved, so the budget on screen is the budget that is left.

The problem

“People commit us to spending before anyone has checked there is budget for it, and I find out when the invoice arrives.”

What it runs

What happens, in order

Every one of these is a step the service takes itself. Nothing in this list is somebody remembering to do it.

9 steps
  1. The requester captures what it is for, the cost centre, the supplier and the lines, with any supporting documents.
  2. Totals are computed from the lines, with VAT per line.
  3. The budget is checked. A request that cannot be afforded stops here and the requester is told.
  4. The first approver is found by the amount, against your own approval limits.
  5. They approve or reject. A rejection takes a reason. Nobody approves their own request: if only the requester could, your administrators decide.
  6. If the amount needs a second signature, the next approver is found and decides.
  7. The budget is committed under a lock on the budget line.
  8. The requester is told the outcome.
  9. An invoice that arrives later is added to the same request. It is on the trail, whoever approved is told, and nothing already attached can be taken off.
It opens on these
  • Awaiting approval
  • Available
  • Committed
  • Approved

Every figure opens what it counts and offers the next action. Nothing here is compiled at month end.

Try the rule

Change the lines. Watch the route.

The arithmetic and routing the service runs: VAT per line, the budget checked before anyone approves, and approvers found by amount from your own limits. The figures are the example school’s.

The request
Allocated less committed less actual. Picking a line fills in the example school’s figure for it. Change it to try any amount up to R 10 000 000,00.
Line 1
Line 2
Unit prices exclude VAT. A quantity of 0 leaves the line out.
Your approval limits. These are the example school's: the bursar signs second from R5,000, the principal from R50,000.
Level 1 decides
Level 2 decides
The route
R 6 980,16Approved by the head of department, then the bursar, and committed

Subtotal, excluding VAT
R 6 069,70
VAT, per line
R 910,46
Total
R 6 980,16
Available on Natural Sciences: Teaching equipment
R 38 200,00
Available after
R 31 219,84
  1. Request raisedBy a teacher: 2 lines against Natural Sciences: Teaching equipment, prices excluding VAT.
  2. TotalledMicroscope: 4 × R 1 450,00 + 15% VAT; Prepared slides, box of 100: 3 × R 89,90 + 15% VAT. Total R 6 980,16.
  3. Budget check: enoughR 38 200,00 available for R 6 980,16. Checking holds nothing; the money is committed only on approval.
  4. Level 1: the head of department decidesThe Natural Sciences level 1 limit names the head of department. Never the requester.
  5. ApprovedThe next level is looked up by amount. The second approval starts at R 5 000,00 with the bursar and R 50 000,00 with the principal.
  6. Level 2: the bursar decidesFrom R 5 000,00 to under R 50 000,00, the level 2 limit names the bursar. Never the requester, and never whoever decided level 1.
  7. ApprovedBoth levels have signed, one after the other.
  8. CommittedR 6 980,16 committed on Natural Sciences: Teaching equipment under a lock on the line, leaving R 31 219,84. Had another approval taken the money first, this one would find too little and commit nothing.
  9. Requester toldApproved, and on the record.
Who sets what

Yours to change, and ours

Most vendors are vague about this line. Yours is everything about how your organisation works. Ours is the shape of the process itself.

Your administrators change these

  • Cost centres, expense categories and financial periods
  • Budget lines and their amounts
  • Approval limits: the bands, and who sits in each
  • Suppliers, with a flag for whether banking details were verified

Authored with the service

  • That approvers are found by amount
  • That two approvals happen in sequence, not in parallel
  • The conditions on each branch

A change here is a draft, checked and published. Work already under way stays on the version it started on.

Where it stops

The part most pages leave out

A service that only ever says yes is not evidence. This is the place it deliberately refuses, and the suite that proves it still does.

Refuses, on purpose

A failed run keeps its commitment

If a run fails after the budget has been committed, the commitment stays. A retry cannot double-spend, and it cannot lose its place.

Proof

Every claim here runs on each build

Not a policy, a suite. This one is npm run spend, and it fails the build rather than a report nobody reads.

The rest of the collection

One stone, many cuts

Keep exploring

Where to next

See it with your own process.

Book a demo