Approval complexity isn't about how many people sign off. It's about how many conditions decide who they are. Amount, business unit, location, cost center, project code, invoice type, supplier, whether it's PO-backed, whether it hit an exception. Multiply those together and you're no longer describing an approval chain. You're describing a rules engine and most platforms are only pretending to have one. A basic workflow asks who approves next. A real engine asks what is true about this invoice, then decides. Routing should key off amount, supplier, department, entity, cost center, or any combination of them, and it should support parallel approvals when two people need to see something at once rather than forcing a queue. If adding a new condition means a support ticket or a consultant, you have a flowchart, not an engine. Medius is built this way, with routing rules configurable on those criteria and support for multi-step and parallel approvals. Approval limits are the most common rule and the easiest to implement badly. Check whether thresholds can vary by entity and category rather than one global ladder, what happens when an invoice crosses a limit mid-approval after a price change, and whether someone can approve their own requisition to invoice chain. Policy that lives in a spreadsheet and gets enforced by memory is not enforcement. Every approval chain eventually points at someone who isn't there. The engine should handle that without AP chasing anyone. Reminders before a deadline, automatic escalation when it passes, and delegation and approver can set themselves before they leave. The part worth testing is whether delegated authority still respects the original limits because a stand-in who inherits an unlimited approval right is a control gap wearing a convenience label. A price variance, a missing receipt, a duplicate flag, and a first-time supplier are different problems, and sending them all to the same approver treats them as one. Ask whether an exception type can drive its own path so a quantity mismatch goes to receiving while a suspected duplicate goes somewhere with authority to stop payment. Exception routing is usually the difference between a workflow that scales and one that funnels everything through a single overloaded person. An audit trail should reconstruct not just who approved, but which rules sent it to them and what the invoice looks like at that time. Alongside that, workflow reporting should show where invoices sit, who owns them now, and which approvals are approaching their deadline. If you can't see a bottleneck until someone complains, the workflow is running you. Any platform can route an invoice to a manager. The question is what happens to an invoice for $40,000 in a foreign entity against a project code with a quantity mismatch when the usual approver is out. Ask a vendor to configure that in the demo rather than describe it. Medius will. Hand over your most tangled routing scenario and watch the rules get built in front of you.