The order sits in pending approval with no approver shown, or with an approver who says they never received it.
Three places to look
Nearly every instance of this is answered by one of three, in this order. The task history on the transaction shows every participant the task was routed to, when, and what they did. The worklist of the person it should have reached answers whether it actually arrived. And the approval rules, read as the engine reads them rather than as they were intended, show which rule matched. Start with the history: it is the only one of the three that tells you where to look next.
Most likely causes
- The approval rule found nobody — and what happens then is a setting, not a wait. A task that cannot be routed does not raise an error. Depending on configuration it is auto-approved, sent to an administrator, or it simply sits — and the requester sees pending approval while nobody has it. So the absence of an error tells you nothing about which of those happened; the configuration does.
- The approver is inactive or has left. A terminated worker can still be named in a hierarchy, and hierarchy-based routing stops where the chain stops — a requester with no supervisor recorded, or a chain that ends before the approval limit is reached, produces the same symptom. The fix for both is in the HCM data rather than anywhere in Procurement, which is worth knowing because it tells you who to ask.
- Routing succeeded and delivery did not. These are different failures with different fixes, and the second is the more common. If an approver's role was removed while items were still assigned to them, the tasks remain in a worklist the person can no longer open: the history says the task was delivered, the person says they never saw it, and both are true.
What to check
- The task history on the document — it usually names where routing stopped, and it separates what was never routed at all from what was routed and then ignored.
- Whether the named approver has an active assignment and a supervisor.
- Whether the amount crosses a limit that routes differently. Orders that approve fine below a threshold and stick above it point straight at the rule and leave the hierarchy innocent — a two-minute test that eliminates half the candidates.
- The approver's worklist directly, rather than asking them whether they received a notification.
The version of this that nobody reports
An approval control can fail in the direction of approving, and that failure is silent. A stuck order is reported within a day, because somebody is waiting for it; the opposite case has nobody waiting. Two are worth checking for while you are already in the rules: an unresolved chain that auto-approves, which is a control that quietly did not apply with nothing to distinguish it from one that did, and a general rule sitting above a more specific one, so the exception never fires. Everything is approved, by somebody, so nothing looks wrong — and a threshold can be inert for months and be found in a review rather than by a user.
Reassigning the task, or withdrawing and resubmitting the document, clears the symptom and leaves the rule broken for the next order. Worth fixing the rule in the same visit.
If none of the above explains it, raise a ticket and include what you checked. Reading this article cost you no hours.