From a requisition to a posted, balanced journal
The order, the goods and the payment each live somewhere else, so by the time an auditor asks, the chain has to be reassembled from memory and email.
Four different things get collapsed into the word "approved": someone authorised the purchase, someone committed budget, someone received the goods, someone posted the cost. This chain keeps them apart and records each one against the same project.
How the chain runs
Every step names the role that acts, the rule the server enforces at that moment, the record it leaves behind, and who holds it next.
-
Who acts
A programme or operations requester
Raises a requisition against a project and budget line.
What the server enforces
Saving a draft is a write; moving it to approved is not. The approve transition requires the procurement approval capability, and that capability is checked against the requisition’s own project — not tenant-wide.
- What it leaves behind
- A requisition carrying its project and budget context.
- Next owner
- The procurement approver for that project.
-
Who acts
A procurement approver
Issues the purchase order to an eligible vendor.
What the server enforces
The order and its budget commitment are written in one transaction: issuing the PO records a durable commitment against the project’s budget line, and cancelling it releases that commitment. Either both land or neither does — a committed amount cannot survive an order that was never issued. Vendor eligibility is enforced on the server, not by hiding a menu.
- What it leaves behind
- A purchase order plus a live commitment visible against budget.
- Next owner
- Whoever receives the goods.
-
Who acts
A store or receiving officer
Records what physically arrived against that order.
What the server enforces
The browser records quantities; it does not choose the accounting outcome. The server recomputes the match from the authorised order plus every earlier receipt, so full, partial and discrepancy are its decision. Damaged quantity above received quantity is rejected outright, and damage or over-receipt forces a discrepancy that has to be dealt with rather than quietly accepted.
- What it leaves behind
- A goods-received note with accepted quantities and a server-set match status.
- Next owner
- Finance.
-
Who acts
The assigned approver for the current step of the request’s chain
Approves the payment request, advancing it one step.
What the server enforces
Three separate gates, all server-side: the actor needs the finance approval capability; the person who raised the request cannot approve it; and only the approver assigned to the current step may act — having acted on an earlier step disqualifies you from acting again on a later one. Amount authority is resolved from the tenant’s own authority matrix, and a role label never waives it.
- What it leaves behind
- The approval chain, advanced and persisted on the request itself with who acted and when.
- Next owner
- The next approver in the configured chain.
-
Who acts
The system, on final approval
Posts one balanced journal for the approved request.
What the server enforces
The entries must balance or the write is refused. The journal is keyed to its source and the request it came from, so approving twice cannot post a second journal — the duplicate is recognised and the existing journal returned. A locked accounting period blocks the posting outright.
- What it leaves behind
- A posted journal that traces back to the payment request, the order and the project.
- Next owner
- End of the chain
What holds it together
Four guarantees that are true of the chain as a whole, not of one step.
Authority is checked per project and per step
Procurement approval is checked against the requisition’s own project, and payment approval against the step of the chain you are assigned to. A tenant-wide grant is not a licence over every project.
Separation of duties spans the whole chain
The person who raised a request cannot approve it, and anyone who has acted on an earlier step is blocked from acting again on a later one — so a single person cannot walk a request through on their own.
The accounting outcome is the server’s call
Receipt match status is recomputed from the authorised order and every earlier receipt. A journal must balance. Neither is something the browser gets to assert.
Posted once, and never into a closed period
The journal is keyed to the request it came from, so a repeated approval returns the existing journal rather than posting a second one. A locked period refuses the posting outright.
What you end up holding
The records this chain produces — the ones an auditor or a donor will ask to see.
- A requisition, an order, a receipt and a journal that all name the same project — each with its own authority record, kept distinct.
- A live budget commitment from the moment the order is issued, released if it is cancelled.
- A receipt whose match status was computed by the server from the order and every prior receipt.
- An approval chain persisted on the request: every hand that touched it, in order, with timestamps.
- One balanced journal per approved request, refused twice and refused into a closed period.
Scope and availability
What this chain does not do. None of it is behind a toggle, and none of it is coming "soon" unless we say so.
Not available today
- Records settlement — that the money actually left the account, with proof of payment.
- Has the goods-received note move stock on hand.
- A goods-received note does not move stock. Stock on hand and custody are a separate inventory record; receiving against an order and updating what is in the store are two different actions today.
- The hop from a goods receipt to a payment request is assembled in the browser, not on the server. The request does not yet carry the server-side source link that would make that step idempotent the way the journal posting is, so this part of the chain is convention rather than enforcement.
- There is no settlement record and no proof of payment. Approval and posting are recorded; whether the money left the bank is not. EMPOBase does not execute bank transfers.
- Approval authority is yours, not ours. Chain steps and amount thresholds come from your tenant’s authority matrix and the chain saved on the request. EMPOBase ships no donor thresholds and no statutory approval policy.
- This is grant and operational fund control, not your statutory books. The ledger here exists to keep commitments, receipts and approvals straight against projects and awards; it does not replace statutory accounting or an audited financial statement.
About the images on this page
The finance view on this page is an illustration drawn by this site, not a capture of the application — it shows the shape of the queue, not a real screen. The rest of this chain is described in text and diagram rather than mocked up, because a mock of a screen that has not been captured is not evidence.
Illustration
Illustration of a finance view with budget lines and a payment request queue
Open a free workspace and raise a requisition against a sample project, or ask us to walk through the authority matrix on a call.
The other workflow
From a field submission to a result you can report