Purchasing and Vendors: How to Organize Requests and Approvals

Uncoordinated purchases rarely come from a lack of discipline. They come from the fact that asking the proper way takes more time than asking by message: if the procedure is a form to fill in by hand and a round of signatures, whoever has a job site sitting idle just buys and tells someone afterward. A purchasing process works when the correct path is also the fastest one.

The result you’re after isn’t control for its own sake. It’s being able to know, at any moment, what was requested, who authorized it, what was ordered, and what arrived.

The request: a few pieces of information, all mandatory

A long form produces requests that happen outside the system. The minimum information is whatever nobody can approve or order without.

• What’s needed, described in a way whoever buys can understand: not just the internal code, not just “the usual.”
• Which job order, department, or cost center it relates to. It’s the piece of data that’s missing most often, and the one that makes it impossible to figure out, at year’s end, where the money went.
• When it’s needed, with a real date. “Urgent” isn’t a date, and within a month it becomes the only priority that exists.
• The expected budget or the last price paid, if available: it gives whoever approves an immediate benchmark.
• Who requested it and who will use it, which are often not the same person.

Thresholds, owners, and backups

The approval rule needs to fit in three lines and hold true always, without anyone needing to ask someone else how it works.

Threshold values are company decisions, not something copied from outside: they’re worked out by looking at last year’s spending and picking the point beyond which an extra check is worth the time it costs. The practical criterion is simple: if a significant share of requests ends up with management, the threshold is too low, and management will become the company’s bottleneck.

Backups are the part that stalls out otherwise well-designed processes, and they’re almost always the last thing anyone thinks of. Three things are needed: a designated backup for every approver, a maximum time beyond which the request escalates on its own, and a record of who approved in place of whom.

From request to goods: a chain, not four separate islands

The value of a purchasing system lies in the links. Every document needs to carry a reference back to the one it came from.

1. The approved request generates the request for quote, or the order directly, and keeps a reference to it.
2. The accepted quote becomes an order, with the agreed terms: price, timing, delivery method.
3. Receiving records what actually arrived, when, and who checked it.
4. Exceptions — meaning a different quantity, a different price, nonconforming goods, or a partial delivery — get recorded on the order, not in a separate message.
5. The invoice is checked against the order and against receiving: it’s the one check that alone repays the time spent setting up everything else.

An example flow: urgent material and a partial delivery

A job site reports it’s short on material for Monday. The manager opens a request from their phone: description, job order, date needed, reason for the urgency.

• The request exceeds the low threshold and reaches the manager, who approves it that same evening. The system records the time and the person.
• The purchasing office orders from the usual vendor, who confirms half the quantity for Monday and the rest for Thursday. The order records two expected deliveries, not one.
• Monday, the first part arrives. Whoever receives it records the actual quantity: the order stays open for the remainder, and the job site can see something’s still missing without having to call anyone.
• Thursday, the second delivery is incomplete. The exception is recorded on the order, so that when the invoice arrives the story is already written and doesn’t need to be reconstructed from conversations that happened two weeks earlier.

The interesting part is that nobody did any extra work: the same information that used to circulate by phone was written down once, in the place where it would be needed later.

What needs to stay in writing, and when you don’t need a system

Traceable doesn’t mean recording everything. It means being able to answer, months later, four questions: who requested it and why, who approved it and when, what was ordered and on what terms, and what arrived and what was disputed.

• Changes need to be kept as history, not overwritten: an order changed three times needs to be able to show all three versions.
• Decisions made outside the system, like an exception granted verbally, need to be brought back into it. Otherwise the recorded history is false, and a record nobody trusts stops being used.
• People need to be identified by role as well as by name, because names change and old records need to stay readable.

What this guide doesn’t cover

This guide covers how to organize requests, approvals, orders, and receiving. AI-assisted comparison of vendor quotes — meaning what an artificial intelligence system can check regarding terms, prices, and differences between quotes, and with what precautions — is covered in a dedicated guide. Managing a job order in full, from sale to installation, has its own guide.