Skip to main content

Reject a pending expense and resolve rework

Rejection applies to a pending manager/director decision. It records Approval Status REJECTED, clears prior approval actor/time and retains the reason. It is not an expense CANCELLED lifecycle state or a payment cancellation.

Reject​

  1. Review the exact pending expense and supporting evidence.
  2. Choose Reject with expense.reject.
  3. Enter a meaningful reason in the prompt; blank/whitespace reasons are not accepted by the service.
  4. Submit and verify the rejection banner and saved reason.
  5. Arrange the appropriate authorised correction or withdrawal through the internal process.

Current resubmission limitation​

The rejection banner asks the user to correct the amount and resubmit. The actual code resets approval only when the total changes numerically. It has no dedicated resubmit/withdraw-decision endpoint in this workflow. Editing only description, account, date or vendor does not clear REJECTED, and manager/director decision commands expect a pending tier rather than REJECTED.

Do not change the amount by a token penny, lower it across a threshold or falsify spending merely to reset the decision. If a same-amount correction is legitimate, ask for the approved support/product resolution. An unused DRAFT may be deleted/recreated only where that is genuinely authorised, no financial effects exist and evidence handling is appropriate—not as an undocumented approval bypass.

Examples​

An entered 6,500 should actually be 6,000 according to evidence. Correcting the genuine draft total recalculates the manager requirement and clears the old rejection metadata. A new review is then needed.

A correct 6,000 amount with the wrong description remains rejected after description-only correction. The UI does not offer an ordinary direct resubmission for that case. Record the actual limitation and escalate.

If rejection fails, check the saved pending state, reason and permission. If the response is uncertain, reload before issuing another decision. No independent approver/submitter rule or full immutable decision history is implied by the current metadata fields.