From a requisition to a posted, balanced journal
When orders, receipts and payment requests live in separate places, preparing for a review can mean piecing together records from files and email.
Purchase authorisation, budget commitment, receipt of goods and ledger posting are different steps. This workflow keeps their records distinct and links them to the project.
How the chain runs
Follow your team's work from submission to reviewed results.
-
Who acts
A programme or operations requester
Raises a requisition against a project and budget line.
What this protects
Only staff authorised for this project can approve.
- 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 this protects
Purchase orders keep committed funds visible against the project budget.
- 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 this protects
Goods receipts highlight differences that need your team's attention.
- What it leaves behind
- A goods receipt with accepted quantities and any differences to review.
- Next owner
- Finance.
-
Who acts
An authorised payment approver
Reviews the payment request and records an approval decision.
What this protects
Only staff authorised for this project can approve. The person who raised a request cannot approve it. The same person cannot approve more than one step of a request. Approval limits are set by your organisation.
- What it leaves behind
- Review decisions record who acted, when and any notes.
- Next owner
- Finance.
-
Who acts
The system, on final approval
Posts one balanced journal for the approved request.
What this protects
Approved requests post to the ledger exactly once.
- 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
Controls in this workflow
Review these controls together with the scope and limitations below.
Approval access stays with your project team
Only staff authorised for this project can approve. Approval limits are set by your organisation.
Independent approval decisions
The person who raised a request cannot approve it. The same person cannot approve more than one step of a request.
Clear goods-receipt records
Goods receipts highlight differences that need your team's attention.
Balanced records and protected periods
Ledger entries stay balanced, and closed accounting periods are protected.
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 goods receipt with accepted quantities and any differences to review.
- Review decisions record who acted, when and any notes.
- Ledger entries stay balanced, and closed accounting periods are protected.
Scope and availability
Review the supported uses and reporting boundaries with your team.
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.
- Keep requests, orders and receipts together for review.
- 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 limits are set by your organisation.
- 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
Request a walk-through of this workflow using sample data. Review the approval roles and confirm plan availability with us.
The other workflow
From a field submission to a result you can report