What does a purchase order log show about approval bottlenecks?

Question and scope

This review asks what a purchase order log can show about where an approval process stalls. The unit is a request that needs a purchase order before a vendor can be paid. The scope covers routine operating purchases handled through an assistant-managed inbox. The review does not estimate a universal cycle time, because the approval thresholds and systems vary by organization.

The question matters because a slow purchase is often described as a vendor problem when the delay sits inside the approval chain. A log with dated steps can show whether the request waited for a budget check, a manager, finance, or the vendor. Without those dates, the team argues from memory. The log turns the argument into a measurable path.

The review separates the request, approval, order, delivery, and invoice steps. Each step has an owner and a timestamp. A single end-to-end number hides the step that needs a fix. The useful measure is the interval at each step and the share of requests that return for more information.

What the log should capture

Capture the request date, the requester, the vendor, the amount, the budget line, and the business reason. Add the approver, the approval date, and the order date. Record the expected delivery and the invoice date. A log with those fields can answer most questions without opening the inbox.

Record the reason for every return, such as a missing quote, an unfunded budget line, or a wrong approver. A return is a rework event and should be counted. The reason points to the form or the rule that needs to change. Without the reason, the team only knows that the process is slow.

Keep the log in one system rather than a personal spreadsheet. The assistant and the finance reviewer should see the same record. Add a reference number that appears on the request, the order, and the invoice. A shared reference prevents duplicate entries and lost attachments.

Read the intervals

Calculate the median and the slowest cases for each step. The median shows the normal path, while the slowest cases show where the process breaks. A step with a long tail may have a single approver who is often away. A step with a high median may have a rule that is too complex for the risk.

Compare the intervals by amount and category. A small routine purchase that takes as long as a large contract suggests the threshold is too low. A large purchase that moves quickly may have a dedicated reviewer. Use the comparison to set different paths for different risk levels.

Count the returns separately from the elapsed time. A request that is returned twice may have a fast approval clock but a slow real cycle. The rework count often explains the tail better than the approval time. Fix the form before adding another approver.

What the log cannot show

The log cannot show a purchase that never entered the process. A person who buys with a personal card and seeks reimbursement later follows a different path. Those purchases are invisible in the purchase order data. A reconciliation with the expense system is needed to find them.

The log also cannot show the quality of an approval. A fast approval may be a rubber stamp rather than a good decision. A slow approval may include a useful review. Pair the timing with a sample of approved requests to see whether the control is doing its job.

Public guidance from the Small Business Administration and NIST supports written procedures and accountable access, but it does not supply a benchmark cycle time. The FTC's truth-in-advertising guidance is about accurate promises to customers, not internal approvals. Use the sources to justify the process, then rely on local data for the measurement. They explain why the log matters, not what the result should be.

Controls that reduce the bottleneck

Raise the threshold for low-risk, routine purchases and keep the higher review for new vendors and large amounts. A tiered rule lets the assistant move a small request without a manager. The log should show whether the tier reduces the cycle time without increasing exceptions. Review the exceptions after one month before changing the threshold again.

Give the requester a complete form with the vendor, quote, budget line, and reason. Validate the fields before the request reaches the approver. A returned request is more expensive than a longer form. Test the form on the next ten requests and count the returns.

Name a backup approver for each threshold and publish the response expectation. A single approver is a single point of failure during leave. The backup should see the same queue and the same rules. Record the delegation in the log.

Review the log monthly and change one step at a time. If most delays are in approval, adjust the threshold or the backup. If most are in invoice matching, improve the reference field. Compare the next month with the same definitions.

Method and limitations

This review describes a log analysis rather than a controlled study of approval times. The data depends on what the team records and when. A timestamp entered later may be approximate. A request that bypasses the log will not appear at all. Treat the result as a guide to where to look rather than a precise audit.

The log can also change behavior while it is being reviewed. Approvers may clear the queue before the monthly report, which makes the interval look better than usual. Use several months and note the reporting date. A sustained change is more convincing than a single good month.

Decision checklist

Capture request, approval, order, delivery, and invoice dates with one reference number. Record the reason for every return. Calculate the median and the slowest cases by step. Compare the intervals by amount and category.

Set tiered thresholds and name a backup for each approver. Validate the request form before approval. Review the log monthly and change one step at a time. Reconcile the log with the expense system to find purchases that bypassed it.