Who Decides Which Department Is Spending
For most of your staff, the department on a purchase request is not a field — it is stamped from who they are, and the request is refused when it cannot be. For an administrator it is a free choice from the whole list, and nothing anywhere records that they made it on somebody else's behalf.
A purchase request has a department on it, and that single value decides whose budget the eventual order consumes. It is worth knowing, precisely, who in your organisation is allowed to set it — because in this product the answer depends on who is filling in the form, and the two answers are not variations of each other. They are different mechanisms.
This is not a criticism dressed as a description. The asymmetry is deliberate and mostly right. But it has one consequence that nobody notices until an auditor asks, and it is easier to explain before you need it.
For an ordinary member of staff, the department is not a question
When somebody without administrator rights raises a purchase request, the department is not read from what they submitted. It is looked up from their own login, written onto the request, and only then validated. Whatever was on the form is replaced.
If their login carries no department, the request is refused outright with a message telling them to ask an administrator. There is no default, no blank, and no request that proceeds with the field empty. The same pattern governs a quotation request, which additionally prefers the department already recorded on the requisition it came from.
This is the behaviour to want
A control that stamps a value from the actor's identity is stronger than one that offers a dropdown and trusts the choice, and a control that refuses is stronger than one that defaults. Neither is impressive to look at, and both are the reason a departmental spend report can be believed. The place the department comes from — a field on the login rather than on the employment record — is its own story, told in One Person, Two Departments.
For an administrator, it is a list
An administrator raising the same request is not forced, not defaulted and not refused. The department they submit is checked against the department list and accepted if it is a real name on it. Any real name.
That is necessary. Somebody has to be able to raise a purchase for a department they are not in — a finance officer processing a request that arrived by email, a procurement lead consolidating four requests into one order, an operations manager covering for a colleague on leave. A suite that made this impossible would be unusable in the first week.
Raised by a member of staff
- The department is taken from their login
- What they submitted is discarded
- No department on the login means the request is refused
- The department on the request is evidence of who raised it
- Editing the request keeps the department already on it
Raised by an administrator
- The department is whatever they choose
- Checked only against the list of real departments
- Never refused for a missing department
- The department on the request says nothing about who raised it
- The same freedom on edit
The consequence, stated plainly
Take a departmental spend report and read one line of it: Facilities, some amount, over some period. Every requisition behind that figure was either stamped by the system from the login of somebody in Facilities, or typed by an administrator who may or may not be in Facilities and may or may not have been asked by anybody in it.
Both kinds of line look identical. The record holds who created the request and when, so the trail is not lost — but it holds no statement that a request was raised for a department other than the raiser's own, and no report separates the two. Reconstructing which is which means comparing every request's department against its raiser's department, one at a time.
The audit question is not "who raised this?" — that is recorded. It is "was this raised by somebody in the department that is paying for it?", and answering it today means a comparison nobody has written.
What is genuinely enforced around it
It is worth being specific about the controls that do hold, because the useful version of this article is not "the field is loose" — it is "here is exactly how loose, and what is holding the rest of the line".
The department must exist
Both the requisition and the quotation request validate against the real department list. A department that is not on the list cannot be typed onto a request by anybody, administrator included.
A missing department is a refusal, not a blank
Where the department comes from the raiser's login and there is none, the request stops. Two separate refusals exist on the quotation request, one for a missing profile department and one for a missing selection.
The department survives editing by a colleague
When somebody without administrator rights edits an existing requisition, the department already on it is preserved in preference to their own — so a request raised for another department is not quietly relabelled by whoever touches it next.
Approval is required before an order exists
An order cannot be raised against a requisition that has not been approved. This is the strongest link in the chain and it is unaffected by any of the above.
Who raised it, and when
Every requisition carries its creator, its submitter, its approver or rejecter, and the timestamps. The trail exists; what is absent is the comparison.
A statement of whose behalf
A request raised by an administrator for a department they are not in, recorded as exactly that, so the report can separate the two kinds of line.
A delegation list
Naming the departments a given person may requisition for, so authority is a maintained list rather than a consequence of holding administrator rights.
What to do about it this quarter
-
Count your administrators
The freedom described here is a property of the administrator flag, not of a procurement permission. Every administrator can raise a request for every department. That is usually a smaller number than people expect, and occasionally a much larger one.
-
Decide whether that set is the right set
Some of those accounts hold administrator rights for reasons that have nothing to do with buying — they were the person who set the workspace up, or they manage users. Cross-department requisitioning came along with it.
-
Give the people who should requisition a department instead of administrator rights
A departmental buyer with a department on their login and the ordinary procurement permissions gets the stamped, refused-when-absent behaviour, which is the stronger of the two. Reserve the free choice for the people who genuinely buy across the organisation.
-
Write down the convention for cross-department requests
Until the record can hold it, the description field is where "raised on behalf of Facilities, requested by J. Otieno" belongs. A convention everybody follows is worth more than a field nobody fills in.
-
Sample the comparison once a quarter
Twenty requests, checked against their raisers' departments. It takes twenty minutes and it is the only way, today, to know whether the convention is holding.
Grade any procurement module on how it answers this
Ask about the ordinary member of staff first. Vendors demonstrate as administrators, and the administrator path is the permissive one in almost every product.
Where does the department on a request come from?
Make them prove it: Ask them to raise one as a non-administrator and watch whether the field is offered at all.
What happens when it is absent?
Make them prove it: Remove the department from a test account and try again.
Who can requisition across departments?
Make them prove it: Ask for the list, and whether it is a permission or a side effect of another role.
Is "on behalf of" a field or a convention?
Make them prove it: Ask to see it on a record, not on a slide.
Can you report requests raised outside the raiser's own department?
Make them prove it: Ask for the count for last quarter.
Does editing a request let somebody relabel its department?
Make them prove it: Hand a colleague an existing request and have them save it unchanged.
What AWRA OpsHub does today
- The department on a requisition stamped from the raiser's login for anybody without administrator rights, replacing whatever was submitted.
- A refusal rather than a default when that login carries no department, on both the requisition and the quotation request.
- Validation of the department against the real department list on every path, for every kind of account.
- The department already on a requisition preferred over the editor's own when a colleague without administrator rights edits it.
- Creator, submitter, approver, rejecter and timestamps on every requisition.
- Approval enforced before an order can exist against a requisition.
- A quotation request that inherits its department from the requisition it was raised from.
More we can add to your workspace
- A statement of whose behalf a request was raised, held on the record, so a departmental spend report can separate requests raised inside a department from requests raised for it.
- A delegation list per person — the departments this individual may requisition for — so cross-department authority is granted deliberately rather than inherited from the administrator flag.
- Cross-department requisitioning as its own permission, separable from the other things administrator rights carry.
- A report of requisitions whose department differs from the raiser's own, which is the sample check we currently recommend doing by hand.
- Value bands that route an approval to a different approver. Procurement approval today is a permission, held or not held, at every value.
Where we point you to a specialist
- Somebody must be able to buy on behalf of a department they are not in. We would not build a product in which a procurement office cannot consolidate four departments' requests into one order, and any control described above has to leave that possible.
- Whether a given person should hold cross-department authority is a decision about your organisation, and we point you at your own delegation-of-authority policy rather than shipping an opinion about it.
- We do not treat administrator rights as a procurement grade. Where the two need to be separated in a real deployment, that is a permissions design conversation and worth having properly rather than working around.
The first and fourth items are the pair that turn a convention into evidence — a field and a report. If your delegation of authority has to be demonstrable rather than merely followed, say so and we will scope both together.
Turning a convention into a record
The whole of this article reduces to one absent sentence on a record. Everything else follows from being able to write it down.
On whose behalf
A requested-by reference beside the department, set when a request is raised for a department other than the raiser's own. Small, and it makes the next two possible.
A delegation list
The departments a person may requisition for, maintained like any other list, replacing the current all-or-nothing that rides on administrator rights.
The exception report
Requisitions whose department is not the raiser's own, by period. Useful the day it exists, and useful for a different reason once the field above is in place.
We publish scope, not dates.
Scope requisitioning authorityOur take
The non-administrator path is the good one and it is the path most of your people are on: identity decides the department, the submitted value is discarded, and a missing department stops the request rather than blanking a field. The administrator path has to stay open, and today it is open all the way — not because a check was forgotten, but because "on whose behalf" has nowhere to live on the record. Until it does, the practical control is a short administrator list, a department on every ordinary buyer's login, and a written convention for cross-department requests. That is a governance answer rather than a software one, and for most organisations it is sufficient.
Four questions that separate a governed suite from a tidy one
Show me a purchase request raised by somebody who is not an administrator.
A good answer sounds like
A form with no department field on it.
What ours actually is
No field — it is stamped from their login. If a vendor shows you a dropdown here, the departmental spend report is a record of choices rather than of facts.
What stops an administrator raising a request for any department?
A good answer sounds like
A delegation list, or a candid nothing.
What ours actually is
Nothing, and the candour is the point: this is true of most products and is almost never said out loud.
Is cross-department buying a permission of its own?
A good answer sounds like
Yes, and here it is in the permission list.
What ours actually is
It rides on the administrator flag today.
Does approval change with the value of the purchase?
A good answer sounds like
Named bands, demonstrated.
What ours actually is
Approval is a permission, at every value. A field named like a threshold exists in the workflow engine and counts approvers rather than money — worth checking in any product, because the name invites the wrong reading.
Count your administrators this week
It is the one action in this article with an immediate effect and no build behind it. Every administrator can raise a purchase request for every department; most workspaces have more of them than they intended, for reasons unrelated to buying. We will walk your permission map with you if it helps.
Review the permission mapFrequently asked questions
Is this a security hole?
No. An administrator raising a purchase request for another department is an intended capability, the request still needs approval before an order exists, and the creator is recorded on the record throughout. What is absent is a statement of intent — that the request was raised on somebody else's behalf — and a report that separates those requests from the rest. That is a reporting and delegation matter, not an access-control one.
Why is the department taken from the login rather than the employment record?
Because procurement reads the login and nothing else, which is a real seam in the suite and has its own consequences the first time HR provisions somebody a login. It is covered in One Person, Two Departments, and it is worth reading before you set up requisitioning for a new team.
Can I stop administrators raising requests at all?
Not by a setting, and it would be the wrong lever anyway — you would lose consolidation and cover-for-leave along with it. The effective control is the size of the administrator list plus a department on every ordinary buyer's login, so the strong path is the one almost everybody is on.
Does approval get routed differently for a large purchase?
No. Approval in procurement is a permission somebody holds or does not hold, at every value. There is a field in the workflow engine whose name suggests a value threshold; it is read in one place and clamped into a number of approvers required for consensus, so it counts people rather than money. Two genuine value gates do exist elsewhere in the product — on stock adjustments and on high-risk asset movements — and neither is a procurement ceiling.
What does the department on the request actually control?
Whose budget the eventual order consumes. Budgets are held per department and category, and an order inherits its department down the chain from the request. So the field is not a label for reporting — it decides which budget line moves, which is why the difference between a stamped value and a typed one matters.
We run a central procurement office. Does any of this apply to us?
It applies more, not less. A central office raising every request means every requisition's department is a typed choice, so the stamped-from-identity control never engages and the departmental spend report is entirely a record of what the office selected. The convention in the description field and the quarterly sample check are doing all the work, and both are worth formalising.
Where does the department list itself come from?
One maintained list, edited under procurement, referenced by fourteen tables across the suite — and holding two fields. See A Department Is a Name and a Description.
