Confirm, validate, cancel or reset expense payments
These actions operate on the linked payment record. They do not automatically reconcile expense counters, reverse journal recognition or move money externally.
Controls
| Payment state | Offered action | Result/authority |
|---|---|---|
| DRAFT | Confirm | IN_PROCESS; expense.payment.post |
| IN_PROCESS | Validate | POSTED; expense.payment.post |
| DRAFT or IN_PROCESS | Cancel | CANCELLED; expense.payment.cancel |
| POSTED or CANCELLED | Reset to Draft | DRAFT; expense.payment.reset |
New expense payments start IN_PROCESS, so Validate is normally the first lifecycle control. Confirm becomes relevant after a permitted reset to DRAFT. No independent two-person requirement is implemented simply because controls have different names.
Procedure
- Open the employee expense's payment page and verify the exact payment number/ID.
- Read amount, date, method and current state against approved evidence.
- Review the intended operation with finance where it affects an already processed record.
- Choose the specific permitted action once and wait.
- Reload and inspect the payment row and expense counters separately.
Only the active row shows its lifecycle busy state. That visual control is not an idempotency or global concurrency guarantee.
Important boundaries
Validate delegates posting of the payment. It is not a bank transfer instruction, external reconciliation or proof of supplier/employee receipt. The reviewed Expense path creates no dedicated automatic liability-clearing journal during these wrappers. Check actual accounting and settlement evidence separately.
Cancel is not a refund and does not restore expense Amount Due. Reset to Draft changes payment state; it is not an automatic inverse journal, withdrawal of a completed bank transaction or complete rollback of the expense workflow.
Example: A GBP 100 IN_PROCESS payment is cancelled. The row can become CANCELLED while the parent expense counter still includes 100. Stop and reconcile; do not assume Record Payment may now safely record another 100.
If an operation fails or the response is lost, reload exact current state before retrying. If the underlying record's unit differs from the expense because of the current dialog limitation, access outcomes may differ as well. Do not broaden permissions or use generic customer payment actions as an improvised repair.