Purchase requests

The idea

At 200 people, buying stops being a conversation. A tool gets ordered on a company card, and an "updated bank details" email gets paid because nobody called. Three habits fix it: every purchase is asked for before it's bought, the yes comes from whoever owns the money, with more signatures as the amount grows, and finance checks the vendor before anything is paid.

Every ask is a Request, one record for one purchase from the first line to the paid invoice, and anyone in the company may ask. A request belongs to a Department, whose Budget owner says yes to its spending. Money lives in Budgets, which finance adds before each quarter, one per department, with the quarter's dates and an allocated amount; a request counts against its quarter when it's approved, not when the invoice arrives. The Vendor is who gets paid; finance checks it once. The signatures an amount needs are written in one record, the Approval policy, so a threshold change is an edit, not a project.

In any work tool, this becomes a few kinds of linked records: requests whose workflow runs from Draft to Paid, budgets that add up what each department has committed and what still waits for a yes, and vendors finance checks once. People live in a list of the requests waiting on them; a button signs a request with the name of whoever pressed it, and a request whose vendor isn't checked shows red before anyone pays it. It's the company's book of asks and promises, not its accounting system; invoices and payments live there.

How it runs

Follow one request, Booth at SaaS Summit, from the ask to the paid invoice.

1. Someone asks. Dana in marketing fills in the New request form: a name, her department and its budget for the quarter, the Amount, 18,000, a Needed by date, and the ask under What, Why and Alternatives in the Description. She is its Requester, the one who asked and who will place the order. From the policy's thresholds she sets its Tier, how many signatures the amount needs, One signature, Two signatures or Three signatures: 18,000 is two signatures. She adds the vendor, Summit Expo Services, with its website and contact email; a new vendor starts in New. The form submits into Submitted; a request started by hand waits in Draft until its requester moves it on.
2. The rule routes it. The Route for approval rule makes Marketing's budget owner its Approver, whose turn it is, and notes the day it was submitted.
3. The budget owner decides. The head of marketing, Marketing's budget owner, opens Awaiting my approval: the requests whose turn is hers, each with its Room left, what the quarter would have left after a yes, red when negative. She presses Approve, which comments who approved and when. At two signatures, she then moves the request to Finance review and makes the policy's Finance approver its approver. A no is a move to Rejected by the approver, with the reason in a comment.
4. Finance signs. The head of finance, the finance approver, presses Approve and moves the request to Approved; Approve has stamped the date on it. Three signatures would have passed through Executive review and the policy's Executive approver first, handed on the same way. The 18,000 stops waiting and joins Marketing's Committed, the total the quarter has said yes to, and the quarter's room shrinks by the same; This quarter shows it, one row per department.
5. Finance checks the vendor. In Vendors to verify, finance collects the vendor's tax form and ticks Tax form received, confirms the bank details by phone, on a number it already had, and enters Bank details verified on. With both set, finance presses Verify vendor, which moves the vendor to Verified with a comment; a blank in either says the check isn't done. A vendor finance won't work with goes to Blocked.
6. The invoice arrives and gets paid. Dana places the order; the approved request is the purchase order, the written yes the vendor can rely on. When the invoice comes, finance enters Due on and moves the request to Invoiced. On Thursday, in Payment run, the week's payments in one sitting, finance pays and presses Record payment, which stamps the paid date and moves the request to Paid, with a comment for the payment reference. A request whose vendor is still New is red there, and waits for the check.
7. Or it stops. A request no longer needed is moved to Cancelled by its requester or the budget owner, and its amount leaves Committed the same moment. A request waiting for a signature shows its Days waiting, red past 3 days, and from then on the Approval reminder nudges its approver every weekday morning until it moves.

What people look at

• Every morning — Awaiting my approval: the requests waiting on you, with their room left and days waiting. What must I decide today.
• Every Thursday — Payment run: approved and invoiced requests, due dates first, red when the vendor isn't Verified. What do we pay this week. Then Vendors to verify: new vendors and the requests waiting on them.
• Every Monday — This quarter: each department's quarter: allocated, committed, pending, left. Who is running out of room.
• Any time — My requests, your own asks; Open requests, every unfinished one by state; Paid requests, newest first; New request, the form; and the Committed by department and Paid by vendor reports.
• How to run purchase requests — this process on one screen, kept where the team works.

The rules

These are all the automations; everything else in the story is done by people.

• Route for approval: when a request moves to Submitted, its department's budget owner becomes its approver and Submitted on is set to today.
• Approve (a button on a request): adds a comment that the request was approved, with the name of whoever pressed it and the day, and sets Approved on to today. It checks nothing: a press out of turn shows under its presser's name, and the approver moves the request on. A yes is a click that leaves its name.
• Verify vendor (a button on a vendor): moves the vendor to Verified and adds a comment with the name of whoever pressed it and the day. It checks nothing: a missing tax form or bank check is a blank on Vendors to verify.
• Record payment (a button on a request): moves the request to Paid, sets Paid on to today and adds a comment for the payment reference. It checks nothing: a request whose vendor isn't Verified is red on Payment run.
• Approval reminder: every weekday at 09:00, the approver of every request that has waited more than 3 days is notified, one message per request.

No automations in your tool? Then a person does each of these at the same moment, and the promises they keep below become practices.

What must stay true

Whatever anyone edits, adapts or corrects, these hold; each says what keeps it so.

• ★ A signature is a press of Approve by whoever's turn it is, and it leaves a comment naming who and when. Kept by Approve, whose comment carries the name of whoever pressed it, so a press out of turn shows. Handing the request to the policy's next approver, and pressing before moving it on, are practices: a request moved on without a press carries no signature.
• ★ The signatures an amount needs come from the policy's thresholds, read when the request is submitted, not from anyone's memory. A practice: the requester sets the tier from the policy, and the budget owner checks it beside the amount on Awaiting my approval before signing. An amount corrected while the request waits is sent back to Draft by its requester and submitted again, with its tier set afresh: a practice.
• ★ A request counts against the quarter it was submitted in, and as committed from the last signature, not from the invoice or the payment. The requester links it to the department's budget for the quarter, which the form asks for: a practice. Kept by Committed, which adds up only Approved, Invoiced and Paid requests, so a request cancelled after approval leaves it the same moment.
• ★ No vendor is paid before finance has checked it. Shown on Payment run, where a request whose vendor isn't Verified is red, and on Vendors to verify, where a missing tax form or bank check is a blank; finance pays nothing red and verifies no vendor with a blank: a practice. A vendor whose bank details change goes back to New and is checked again, however the news arrived: a practice.
• A paid, rejected or cancelled request is never reopened; the same purchase asked again is a new request, so the history of what was declined stays honest. A practice.
• Nothing waits unseen. Shown by Days waiting, red past 3 days on Awaiting my approval and Open requests; the Approval reminder asks the approver every weekday morning, and whether they act is theirs.

Making it yours

Decide these before you set it up; each has a default if you shrug.

• Under 50 people: one signature is enough: drop Finance review, Executive review, the Tier field and the Approval policy, so Route for approval sends every request to the budget owner and there's nothing left for a policy to say; finance keeps the vendor check and the payment run.
• Budget owners' own requests: a common choice is that the finance approver signs them first: the budget owner hands their own request to finance instead of approving it.
• Subscriptions and renewals: one request per renewal, the previous one linked in the Description; a Subscription database only when you want warnings before auto-renewals.
• Pushed too far: a state per signature, manager, director, VP, CFO, CEO, is a relay nobody finishes; three is plenty at 200 people.

Sources

• Electronic Purchase Requisition/P2PO, Northern Illinois University Procurement Services: approvals that start with the budget owner, grow with the amount and start again when the amount changes.
• Protect your vendor master file from fraudsters, Office of the Washington State Auditor, 2023: a new vendor's tax form, and bank changes confirmed by phone on a number already on file.
• Expenditure cycle definition, Steven Bragg, AccountingTools, 2026: the path from request to payment, and paying invoices in batches by their terms.