Purchase Order Process for a Small Team: Who Approves at What Amount, and What Runs in Slack
A teammate sends the founder a DM: "OK to buy two monitors for the new designer?" The founder taps a thumbs-up between meetings. Three weeks later a bill for four monitors and a docking station reaches whoever pays the bills, and nobody can say what was approved, by whom, or for how much. At many 5 to 50 person firms that DM is the whole purchase order process, and its cost arrives later as bills nobody can explain.
This guide gives a small team a purchase order process it will actually follow. You get a two-band approval rule, the five fields every request needs, a way to record the approval in Slack where the request already happens, and a weekly check that catches the gaps. It also says plainly when you do not need a formal purchase order at all.
The short answer
For a team that works in Slack and has no purchasing department, the process fits in five steps:
- Ask in one place. Every purchase request goes into one Slack channel, as a thread, with five fields: what, from whom, how much, why, and by when.
- Approve by band. Under your small-purchase limit, the requester's lead approves. Above it, the owner approves. One written exception covers anything urgent.
- Record the decision where it was made. The approver answers in the same thread, and the request, the amount and the approval go into a simple log before anyone pays.
- Buy, then match. When the bill arrives, compare it with the approved amount before it is paid.
- Check weekly. Once a week, list requests still waiting for a decision and approved purchases with no bill yet.
The rest of this article explains why each step matters and how to run it without buying procurement software.
Why small teams end up with bills nobody approved
Most purchase order guides are written for companies with a purchasing function. Ramp's walkthrough of the purchase order process describes seven stages: identify the need, submit a requisition, apply policy controls, route for approval, issue the purchase order, receive the goods, then match the order, receipt and invoice before payment. Its example approval chain runs from a manager under $500 through a department head, a finance manager and a CFO above $10,000. ProcureDesk's purchase approval guide is explicit that its five-band table is written for mid-market finance teams of roughly 100 to 1,000 people.
A 20-person agency has none of those roles. The founder is the department head, the finance manager and the CFO. So the team copies nothing, and approvals happen wherever the request happened to land: a DM, a call, a comment on a shared doc, a card swipe nobody asked about.
Three things go wrong as a result:
- No record at the moment of decision. The approval exists only in someone's memory or a DM that will scroll away.
- No amount attached to the approval. "Yes, buy the monitors" approves an idea, not a price.
- No link between the approval and the bill. Whoever pays the bills sees an invoice and has to guess whether it was agreed.
The IRS guidance on business records asks that purchase records show who was paid, how much, when, proof of payment, and a description of what was bought. A DM thumbs-up gives you none of that. The request, the decision and the bill live in three different places, and nobody connects them.
Do you need a purchase order at all?
Often you do not. A purchase order is a document you send a vendor that commits you to a price before they deliver. Many purchases at a small firm never need one: a software subscription bought with a card, a one-off courier, a team lunch. What every purchase above a trivial amount does need is an approval with an amount on it, recorded before the money is committed.
Ramp's guide makes the same point from the other direction: it says even small businesses benefit from a basic process, and that you do not need enterprise software to start. A useful rule for a small team:
| Situation | What you need |
|---|---|
| Card purchase under your small-purchase limit, from a known vendor | A request and an approval in the thread. No purchase order. |
| Anything above the small-purchase limit | A request, the owner's approval with the amount, and a log entry before paying. |
| A vendor who invoices you after delivery for a large or custom order | All of the above, plus a written purchase order or quote you accept, so the vendor's bill can be matched to it. |
| A recurring contract or subscription renewal | Approval at the first purchase and again at any price change. |
If the last two rows rarely happen at your firm, your "purchase order process" is really a purchase approval process. That is fine. Name it honestly and keep it light.
Set two approval bands, not five
For a team under 50 people, two approval bands and one written exception rule do more than a five-tier chain copied from a mid-market guide. ProcureDesk, whose own table has five tiers, says that for companies under 50 people with a single person handling bills, a simple rule where the manager approves everything works. The tiers in vendor guides exist because large companies have many approvers with different budgets. A small firm has one or two.
This is our recommendation; no source sets it. Copying a five-tier table creates approval steps with nobody to fill them, so people route around the whole process. Two bands are easy to remember and hard to dodge:
- Band one, small purchases. Up to a limit you choose, the requester's lead approves, or the requester self-approves if they are the lead. Ramp's example puts its first threshold at $500; ProcureDesk's table auto-approves under $500. Pick the number that would not keep you awake if it were spent badly once.
- Band two, everything else. The owner or founder approves, with the amount written down.
- The exception rule. If something is urgent and the approver cannot be reached, the requester may buy up to band one's limit and must post the request in the channel the same day. Anything larger waits.
Write the bands in the channel description or a pinned message. If the limit changes, change it there, so the rule people read is the rule in force.
The five fields every purchase request carries
A request that says "can we get monitors?" forces a back-and-forth before anyone can decide. A request with five fields can be approved in one reply. Copy this into your channel's pinned message:
- What: the item or service, with quantity.
- From: the vendor, and a link or quote if there is one.
- Amount: the total including tax and shipping, or a ceiling ("up to $1,200").
- Why: the client, project or reason, in one line.
- By when: the date it is needed.
The first three map directly to what the IRS says a purchase record should show: the payee, the amount and a description. The approver's name and the date of approval complete the record. Together they let whoever pays the bills answer "was this agreed?" without asking anyone.
Record the approval where the request was made
Record the approval in the thread where the request was made, before the money is committed, because an approval reconstructed after the bill arrives is a guess. This is a recommendation built on the IRS record elements above and on how the failure in the opening example happens. When the bill arrives a month later, people remember approving "some monitors". They do not remember the price or the quantity.
In practice this means three habits:
- Requests go in one channel, for example
#purchases, one thread per request. - The approver answers in that thread with the amount: "Approved up to $1,200."
- The request and the decision are copied into a log, a table in Airtable, a Notion database or a spreadsheet, before anyone pays.
The log is what makes the later steps possible. A Slack thread is good for the conversation and poor for answering "show me everything approved this month that has no bill yet".
How this runs in Slack with the Kipwise agent
Steps 3 to 5 are exactly the chores a busy owner skips and the reason firms think about hiring a bookkeeper or office manager. The Kipwise agent can take the repetitive part, using only the access each person already has. Here is a made-up example of a single request.
> Priya in #purchases: Two 27-inch monitors for Sam, from our usual supplier, up to $900 total, needed by the 12th. @Kipwise add this to the purchase log. > > Kipwise: Shows an Approve card to Priya: create a record in the Purchases table with item, vendor, amount up to $900, reason, needed by, status "waiting". > > Priya approves the card. The record is created, written as Priya. > > Dana (owner), same thread: Approved up to $900. > > Priya: Mark it approved by Dana, today. > > Kipwise: Shows Priya an Approve card for the update; once she approves, the record shows approved by Dana with the date.
That example follows from how the agent works:
- One mention, then plain replies. You mention the agent once in a thread, and later replies in that thread continue the same conversation.
- Your own access. The agent connects to Airtable or Notion with each person's own account. Every record it writes is attributed to the person who asked.
- An Approve card before every change. Before it creates or changes a record, the agent shows an Approve or Deny card that only the person who asked can use, and the card expires after 30 minutes. That card confirms the agent's own action. It is not the purchase approval: Dana's reply in the thread is. The agent never approves a purchase on anyone's behalf. Our post on human approval in AI agent workflows in Slack explains the card model in more detail.
The weekly check. The owner asks once: "Every Monday at 9, list purchase requests still waiting for a decision and approved purchases with no bill yet, and post it here." Creating a scheduled task needs approval once, and later runs do not ask again.
Matching the bill. When the bill arrives, whoever pays bills asks in the request's thread: "Open the bill from our supplier in QuickBooks and compare it with the approved amount." With their own Xero or QuickBooks access, the agent can open a bill, read a vendor's balances and run an aged payables report. See the QuickBooks agent page for what it reads and changes there.
The agent does not create purchase orders or bills in Xero or QuickBooks, and it does not send anything to a vendor. If you need a formal purchase order for the third row of the table above, create it in your accounting tool or send the vendor's quote back accepted, and put the link in the thread.
Check approved purchases with no bill, not only bills with no approval
Check approved purchases that have no bill yet every week, not only bills that have no approval, because that open list is where amounts quietly grow. This is a recommendation. A check that starts from the bill works like this: an invoice arrives, and someone asks whether it was approved. That catches purchases nobody approved. It misses the quieter problem: something approved at $900 that has turned into a $1,400 order because a docking station and express shipping were added, with nobody asked again.
The weekly list solves that from the other end. Each approved row without a bill is a purchase in flight. Glance at it, and you can ask "is this still $900?" before the bill arrives, when changing it is still cheap. Once the bill is in, the comparison is a single question in the thread.
Pair it with one rule in your pinned message. If the final amount will exceed the approved amount, the requester posts the new amount in the same thread and the approver answers again.
Failure modes and trade-offs
People still DM the owner. The owner replies "please post this in #purchases" every time, until requests arrive there by default.
The log falls behind. If copying a request into the log depends on someone remembering, it will lag. Asking the agent in the thread takes one line, and the weekly list exposes any request that never made it into the log, because it will not appear there.
Card purchases skip the process. Card spend under band one is allowed by design. Above it, a card is just a payment method: the request and approval still come first. Your accounting tool's card feed is where the gaps show up, so compare it with the log monthly.
The bands are wrong. If the owner is approving ten small requests a week, band one is too low. If a few large purchases surprise you each quarter, it is too high. Adjust the number in the pinned message, not in people's heads.
Trade-off: a log versus procurement software. Software like the tools in the guides above gives you approval routing, purchase orders and three-way matching in one place. It also gives you another system to log into and pay for. Under about 50 people, with one person paying bills, a channel, a log and a weekly check usually cover it. Move to dedicated software when you have several approvers with separate budgets, or vendors who will only work from formal purchase orders.
How to know it is working
After a month, check three numbers from the log and your accounting tool:
- Bills with an approval: of the bills paid this month above band one, how many have a matching approved row? Aim for all of them.
- Amount drift: how many bills came in above their approved amount without a second approval? Aim for none.
- Time to decision: how long do requests wait in the channel? If it is more than a day or two, people will start buying first and asking later.
If those look right, the process is doing its job. When the bill arrives, follow it into the payment step with our guide to accounts payable for a small team, which covers who approves each bill and what runs in Slack once it lands.
What to do next
Today, create #purchases, pin the five fields and your two approval bands, and ask the next person who DMs you about a purchase to post it there. When you want the log and the Monday list to keep themselves, start a Kipwise trial in Slack, connect Airtable or Notion, and ask the agent to set up the purchase log and the weekly check.
