Leave Requests — Controller Guide
One screen, two audiences. If you hold approval rights it is the queue of time-off your team has asked for. If you do not, it is your own requests and where each one stands, plus the requests of anyone who reports to you. The server decides which you get — you cannot see somebody else's requests by asking for them.
Where it is: Labor → Leave Requests (/accounting/leave-requests).
Requests arrive here from the web and from the mobile app — including ones
submitted while the phone had no signal, which appear when it reconnects. A
supervisor can also decide their reports' requests from the Approvals tab
in the mobile app; a decision made there shows here, and the reverse.
Part 1 — The ideas you need first (read once)
On this page, approving is the only action that moves a balance
This is the sentence to carry into every other part of this guide.
- Approve draws the hours from the employee's accrued balance and writes the leave ledger row.
- Decline writes nothing. The balance is untouched.
- Withdraw writes nothing. The balance is untouched.
A request that was asked for is not leave that was granted. Only an approval makes it real.
Off this page, the employee's own timesheet also moves a balance: leave hours come out of it as they are entered. A day covered by an approved request is drawn once, not twice.
Declined and withdrawn are different facts, and Arcvue will not blur them
Two separate buttons, two separate words, never a shared "decide":
| Word you see | Who did it | What it records |
|---|---|---|
| Declined | The approver | Somebody refused this request. |
| Withdrawn | The requester (or an approver acting for them) | The requester took it back. Nobody refused anything. |
Collapsing these would make the audit trail say a supervisor declined something no supervisor ever looked at. If you are clearing out a stale request that the employee no longer wants, withdraw it — do not decline it.
Nobody approves their own request. Not even an administrator.
This is DCAA separation of duties, and it is the same rule journal entries enforce. On your own row the Approve button is simply not offered, and an amber panel says why:
You cannot approve a request you made yourself. Arcvue needs a second person on a leave approval, the same way it does on a journal entry — that is what makes the approval defensible in an audit. Ask another approver, or withdraw the request.
Withholding the button is a courtesy so nobody presses a control that cannot work. The server refuses regardless — that refusal is the actual control, and it does not care what the screen showed you.
Who counts as an approver
Two kinds of people decide a request. A controller — admin or finance_lead — can decide any request. A supervisor can decide the requests of the people whose time they approve: the queue shows them their own requests and their reports', and Decide appears on a report's pending row. Everyone else sees only their own requests and gets no Decide action on anybody's row.
If this page shows only your own leave, nobody's time routes to you for approval and you hold neither controller role. A supervisor is resolved the way the timecard approval queue resolves one, so if your reports' timecards reach you, their leave requests do too. Whether a role that supervises nobody should carry leave approval is a matrix question for your administrator.
Looking up somebody's balance and charge codes
Look up an employee sits under the request form for the accounting team and HR — the admin, finance_lead, controller, cfo, payroll_admin, staff_bookkeeper and hr_timekeeping_admin roles. Choose someone and it shows, as of today, their Leave — each kind they hold, with the hours available — and what they Can charge today. It answers "how much PTO do I have left?" and "why can't I charge that contract?" without opening anyone's timesheet.
It is read-only. Nothing on the panel changes a balance or an authorization. A balance that is wrong is corrected on Leave Plans, on its Balances table; see that guide. Everyone else sees no panel at all, and the server refuses the lookup to them however it is asked.
Part 2 — How to run it
One button on a row carries three labels and the one you see tells you your
standing on that request. It reads Decide if the request is yours to
approve, Withdraw if it is your own, and Close once the row is open in
front of you. Close only closes the row — it decides nothing.
Step 1 — Work the "Awaiting a decision" tab
Four tabs: Awaiting a decision · Approved · Denied · Withdrawn. The first is where the work is; pending rows are tinted so they read as open. A refused request is filed under Denied, and its Status column reads Declined — the same fact under two words.
If it says "Nothing is waiting on you", you are done. (An employee with no open requests sees "You have no requests awaiting a decision" instead.)
Step 2 — Open the row and read it before deciding
Click Decide. The expanded panel shows:
- Their note, if the requester wrote one. Read it — it is often the whole reason the request is unusual.
- Note (optional) — your reason, recorded against your name with the decision. Optional to the software and not optional to a reviewer: a decision with no reason is the one somebody has to ask you about in a year.
- Approve even if it exceeds the accrued balance — a checkbox, off by default, offered only to the approver.
The columns tell you the rest: Employee (who asked), When (the day requested, or the first and last day of a stretch with the number of working days it covers), Hours (the total across every day, against their accrued balance), Status, and Decided — who decided it and when, blank while it is still waiting.
A request can cover a stretch of days. People ask for a week or two off as one request, with weekends and observed company holidays already left out. Opening one lists every day it covers — N working days, H h in all, then the dates — so you decide on the days the person will actually be away, and approve or decline the whole stretch at once.
The last column is Row actions, and it explains its own blankness —
Decide appears when the decision is yours, Withdraw when the request is
your own, and it is blank once a request has been answered and on any request
you are not the approver for. So an empty cell is usually a fact about
you, not about the request — check you are on the Awaiting a decision tab
and that you hold approval rights before treating it as broken.
A refusal — the Denied tab, Declined in the Status column — is not
interchangeable with withdrawn: declining is an approver's act,
withdrawing is the requester's, which is the distinction Part 1 refuses to
blur.
Step 3 — Approve, decline, or withdraw
| Button | Effect |
|---|---|
| Approve | Draws the hours and writes the ledger row. Toast: "Approved. N h drawn from the balance." |
| Decline | Records you declined it. Toast: "Declined. No leave balance was drawn." |
| Withdraw request | Records the request was taken back. Toast: "Withdrawn." |
The balance is read at the moment you approve, not at the moment the request was made. A request submitted three weeks ago is drawn against today's accrual.
Step 4 — Deciding beyond the balance, deliberately
Tick Approve even if it exceeds the accrued balance only when you mean it. It approves against future accrual — the employee has not earned these hours yet.
Two things to know about it:
- It is the approver's call, never the requester's. It deliberately lives on the approval, not on the request form, so nobody can opt out of their own balance check.
- It is not remembered. It is off again the next time you open a row. There is no setting that leaves it on, and that is the design.
The control is Approve against future accrual — on screen it reads
Approve even if it exceeds the accrued balance. It sits on the
approver's side of the decision on purpose: "it is here rather than on the
request so nobody can opt out of their own balance check." The requester
cannot ask for it and cannot grant it to themselves. Leave it off unless you
mean it.
Part 3 — When something looks wrong
| Symptom | What it means → what to do |
|---|---|
| "Nothing changed — | Your action did not take effect. Somebody decided it between the moment you opened the row and the moment you clicked. Arcvue reads what the server actually did rather than assuming your click won, so this warning is the truth and a success toast would have been a lie. Refresh and look at the current state before doing anything else. |
| I see only my own requests and I expected the team's | You hold neither controller role (admin, finance_lead) and nobody's time routes to you for approval. A supervisor sees their reports' requests; everyone else sees only their own. This is enforced on the server by replacing the employee filter, not by checking it — so there is no way to ask for somebody else's and no setting on this page to change. If your reports' timecards should reach you, ask your administrator to set you as their supervisor. |
| The action column is blank on a row I want to act on | Three possible reasons: the request is already decided (only pending rows offer actions); it is your own request and you cannot approve it; or you do not hold approval rights. Check you are on Awaiting a decision first. |
| "Could not load leave requests." | The list did not load at all. This is not an empty queue — do not read it as "nothing pending." Reload. |
| The employee says they submitted from their phone and it is not here | The mobile app queues a request offline and sends it when the phone reconnects. If the phone has not had signal, the request has not reached the server yet. |
| I approved and the balance did not move | Check the row went to Approved. If it shows Declined or Withdrawn, somebody else decided it first and the warning toast said so. |
| I declined when I meant to withdraw | There is no undo. The record now says an approver refused it. Have the employee re-submit, and note what happened in the decision note on the new request. |
One-line summary
Approve, decline, or withdraw time-off requests arriving from the web and the mobile app — where approval is the only action that draws a balance, declined and withdrawn are deliberately different records, nobody approves their own request (DCAA separation of duties, enforced on the server), and approving beyond the accrued balance is an explicit, off-by-default choice the approver makes at the moment of approving.
Related
- Which leave types exist, how they accrue, and what the balances mean → Leave Plans (
/accounting/leave-plans) - Recording hours worked → Timekeeping
- Pay codes and how leave reaches payroll → Payroll & Pay Codes
- The same second-person rule on the books → Journal Entries (
/accounting/journal-entries)