Define what needs a purchase order
A purchase order checkpoint starts with a written threshold and a list of exceptions. State the amount above which a purchase needs an order, and name the categories that always need one. Include software subscriptions, contractor work, and equipment even when the amount is small. The assistant should not decide the threshold case by case.
Separate a purchase from a reimbursement. A person who buys a low-cost item and claims it later follows the expense path, while a vendor who will invoice the company follows the purchase order path. Write both paths in one place. Confusing the two creates duplicate payments and missing approvals.
Capture the request
Use a short request form with the vendor, the item, the amount, the budget line, the needed date, and the business reason. Require a quote or a link to the vendor's offer. Ask who will receive the goods or service and who will confirm delivery. A complete request prevents most of the follow-up questions.
Give the request a reference number when it enters the queue. Use that number in every message and in the purchase order itself. The assistant can then trace the request from the inbox to the invoice. A request without a reference disappears when the thread is archived.
Check budget and approval
Check the budget line before sending the request for approval. Confirm that the amount is available and that the purchase fits the current plan. If the budget is exhausted, stop and ask for a decision rather than forwarding the request. An approval on an unfunded purchase creates a commitment the team cannot meet.
Match the approver to the amount and the category. A small routine purchase may need only the team lead, while a new vendor or a multi-year contract may need finance and legal review. Record the approval in the system rather than only in email. The assistant should be able to show who approved and when.
Track open orders
Keep a log of every open order with the request date, the approval date, the expected delivery, and the invoice status. Review the log at a fixed point each week. An order that has not moved in two weeks needs a follow-up. The log makes the delay visible before the vendor calls.
Set a rule for partial delivery and backorders. Record what arrived, what remains, and whether the invoice should be paid in part. Tell the budget owner about a change in the expected date. A partial delivery that is not recorded can be paid twice or closed too early.
Close the loop
Close the order only when the goods or service are confirmed and the invoice matches the approved amount. Compare the invoice with the purchase order and the delivery record. If the amount differs, resolve the difference before payment. A closed order should have no open questions.
Send the receiver a short confirmation request with the order number and the expected items. Ask them to reply with any shortage or defect. File the confirmation with the order record. The receiver's reply is the evidence that the purchase actually happened.
Review the log for bottlenecks
Once a month, count the time spent waiting for approval, for vendor confirmation, and for invoice matching. The largest interval shows where the process needs a fix. A slow approval may need a higher limit for routine purchases, while a slow invoice match may need a better reference field. Use the log rather than impressions.
Ask the assistant which request caused the most rework and why. The answer may reveal a missing quote, an unclear budget line, or an approver who is often away. Change one step and compare the next month. The checkpoint should get shorter as the process improves.
Sources
Open the original publisher and confirm the current version, definition, and scope before using a source for a business decision.
Turn the reading into a role brief
Bring the recurring tasks, tools, schedule, access limits, and owner-only decisions. Start with one work sample and one clear review path.
Plan a Philippines-based role