Concept explainer
Approval and second signature
Describes when Vault requires an approval or a second signature, who may give it, and how the record shows the approval against the charge.
Vault requires a second signature before certain money moves. This page describes when an approval is required, who may give it, and how the record shows the approval against the charge.
When a second signature applies
A defined set of actions wait on an approval from a second person. Each carries a risk that one person acting alone would leave unchecked.
| Action | Why it waits on a second signature |
|---|---|
| A write-off | It accepts a loss against the account. |
| A charge past the credit limit | It extends an account beyond its agreed limit. |
| A refund above the desk threshold | It moves money out of the hospital. |
| Waiving a discharge finance check | It releases a patient with a check bypassed. |
| A change to a payer's agreed rates | It resets what a payer is billed. |
| A change to the ledger account structure | It reshapes where money posts. |
| Reopening a sealed accounting period | It reaches into a closed period. |
| A change to the site's billing operating mode | It changes how the money of record is held. |
| Connecting a cashless claims channel | It opens a route to an outside payer. |
Who may give it
The second signer is a different person from the one who requested the change. The second signer holds the authority the action requires, which Vault reads from the hospital model rather than from the request.
A request and its approval are two people
Vault derives the second signer's authority itself, and reads it from the model rather than from the request, so the requester states the change while a separate authorised person decides it.
How an approval moves
A maker's change is held as a pending request that carries no effect yet. The effect applies once a checker approves it, and a rejected request rests as rejected.
- 1
Request the change
A biller requests the change. Vault records it as a pending request, and the money stays where it is.
- 2
Review against the reason
A second person with the required authority reviews the request against its stated reason from a fixed list.
- 3
Approve or reject
On approval, the change applies through its own recorded step. On rejection, the request rests as rejected and the account stays as it was.
Accepting a held charge
A held charge carries an unresolved pricing conflict. A Vault employee may consciously accept it, and the acceptance is recorded against the charge with the person and the reason. An accepted charge rests off any finalised invoice, so a conscious decision holds a bill line while the order proceeds.
What the record shows
Each approval and each executed override is stored as its own record. It names the requester, the second signer, the reason from a fixed list, and the account it applies to. A discharge waiver also records exactly which checks were bypassed.
requester person Required | The person who asked for the change. |
secondSigner person Required | The approver, a different person from the requester. |
action label Required | The kind of action, from a fixed list. |
reason label Required | The reason for the action, from a fixed list. |
target reference Required | The account, charge or setting the action applies to. |
status label Required | Pending, approved or rejected. |
decidedAt timestamp | When the second signer decided. |
bypassedChecks list | For a discharge waiver, the checks that were bypassed. |
Common questions
Can one person approve their own request?
The approver is a different person from the requester in every case, so a change carries two hands.
What happens to a rejected request?
It rests as rejected, and the account stays as it was, so a declined change leaves the money untouched.
Where does the approval show against the charge?
The executed record links to the account and the charge, and the audit trail carries an approval entry beside the change.
See how the discharge finance gate decides a release in the discharge finance gate.