Spend
Payment requests, requisitions and advances — what Spend is, who does what, and where each request ends.
Spend is how people ask the business for money. One person raises a request, someone else reviews and approves it, and the business either pays it, turns it into a purchase document, or hands the money over as an advance to be accounted for later.
It lives at /payment-requests.
The three workflows
| Workflow | Raise it when | It ends as |
|---|---|---|
| Payment Request | You already know who gets paid and how much — a supplier invoice, a reimbursement, a bill. | Paid, or converted to an Expense or a Bill. |
| Requisition | You need things, not money. You describe what you need; procurement sources the vendor and the price. | Converted to a draft Purchase Order. |
| Advance | Money has to be handed over before it is spent — travel, petty cash, an upfront cost. | Retired with receipts. |
All three share one spine. Only the last stage differs.
Two landings, one URL
| Who you are | What /payment-requests opens |
|---|---|
| Someone whose only reach into the app is raising requests | Spend home — a greeting, your own totals, one-tap shortcuts to raise, your outstanding advances, and your recent requests. |
| Everyone else | The Spend list — the operational table of every request you are allowed to see. |
Both read the same data. What you can see is decided on the server from your grant on the Spend feature, never by the screen you happen to be on.
Who does what
| Act | Where | Who |
|---|---|---|
| Raise | Raise a request, or + New on the list | Anyone with read access to Spend. |
| Review | The list, on selected rows | Administrators and Super Administrators. |
| Approve / Decline | The request page, or the list in bulk | Administrators and Super Administrators — never the person who raised it. |
| Post / Convert / Retire | The request page, or the list in bulk | Administrators and Super Administrators. Retire is open to anyone who can open the advance. |
The Payment Team roster — reviewers, approvers, payers — is configured on the Spend list and is what the API enforces behind those buttons. It is also who gets emailed when a decision lands or a reminder is sent. See Approve a request.
Approval is a second pair of eyes, so the requester can never be the approver. The single exception is a Super Administrator, so that a one-person business can still operate.
Status
Every line on a request carries its own status. A request with three lines can have one approved, one declined and one still waiting.
| Status | Meaning |
|---|---|
| Awaiting review | Submitted. Nobody has looked at it yet. |
| Awaiting approval | Reviewed. Waiting on the approver(s). |
| Approved | Cleared. It can now be posted, converted, or collected. |
| Declined | Rejected. It stays on the record with the decision and the note. |
| Paid | Posted — the payment has been recorded against the ledger. |
| Converted | Turned into an Expense, a Bill, or a Purchase Order. |
| Partly retired | An advance partly accounted for. A balance remains. |
| Retired | An advance fully accounted for. |
What Spend is not
- It does not move money by itself. Approving records a decision; posting is the moment anything reaches the ledger.
- It does not replace Purchases. A request that should live in payables is converted into a Bill or a Purchase Order and settled there.
Every screen says Spend. The underlying feature name, the permission and the URL are unchanged, so existing grants, links and bookmarks all still work.
Staff is self-service. A Staff user sees only the requests they raised themselves, and never Reporting — including Spend insights.
Related
Raise
The three forms — what each asks for, what is required, and what happens on submit.
Work a request
The request page and everything you can do from it.
Settle it
The three endings — record the payment, turn it into a purchase document, or account for an advance.
See across everything
The list you find one request in, and the report that shows all of them at once.