Purchase Requests and Approval Limits: Who Signs What?

Purchase Requests and Approval Limits: Who Signs What?

In part one we mapped the purchasing cycle as seven stations from request to payment, and suggested a simple exercise: take your last ten paid supplier invoices and trace each one back to its request, approval, purchase order and receiving record. The first document you looked for in that exercise was the purchase request. If some invoices had none, this is where we start, because every document after it needs something to point back to.

This part covers the first two stations together: the request that records the need, and the approval that decides the company will spend on it. It answers a question that sounds administrative but is really operational: who approves what, up to which limit, who approves in their place when they are away, and what happens when the need cannot wait.

The purchase request: the document everything after it hangs on

A purchase request is not paperwork added on top of the work. It is the moment a need stops being a sentence in a phone call and becomes a record with a number. Without it, the purchase order has nothing to point to, the person receiving on site does not know what to expect, and the accountant does not know why they are paying. A good request answers five core questions:

• Who needs it? The requester's name and role, not the name of whoever passed the message on: the site engineer, the production line supervisor, the hotel's maintenance lead.
• What exactly? The item, its specification, the quantity and the unit. A line such as plumbing materials is no reference, because nobody can check what arrives against it later.
• For which project, site or property? This field is what sends the cost where it belongs. A purchase that belongs to no project becomes a general expense nobody can trace.
• Why? One line is enough: an item in the bill of quantities, a part for a stopped machine, consumables for the coming season. That line saves the approver a phone call to ask.
• By when? The date you actually need it, not the word urgent on every request. That date is what purchasing compares supplier delivery times against.

The request also needs an estimated value, even a rough one, because approving by amount needs an amount. If the requester does not know it, purchasing adds it before the request goes for approval. Then the request gets a number that every later document links back to in the system: the approval, the purchase order, the receiving record and the supplier invoice. It is the same logic we set out in work orders and the request number that costs hang on: when every document links to the same number, you can start anywhere in the chain and reach its beginning without asking anyone.

The approval matrix: amount alone is not enough

An approval matrix is a table that answers one question: who can say yes to this request? The simplest matrix is built on a single axis, the amount: up to one limit the department manager approves, above it the finance manager, above that the owner. Amount is a valid axis, but the type of purchase changes the question the approver is answering:

• Stock materials. Steel and cement for a site, raw material for a production line, cleaning supplies for a hotel. The question here is whether you really need this quantity, and whether it already sits in another warehouse or on another site before you buy it. That is why it helps for the approver to see the item's stock at the moment of approval.
• Services and subcontractors. Lift maintenance, insulation work by a subcontractor, a cleaning contract. Here scope matters more than price: what exactly will be done, and how will we know it is finished. So the request needs approvers for two different questions: the person with the technical knowledge approves the scope, and whoever the matrix names for that amount approves the spend.
• Capital assets. Equipment, a vehicle, a generator, a machine for the production line. This is a commitment that lasts years and brings running and maintenance costs with it, so it can reasonably go to a higher level than its amount alone would require.
• Urgent purchases. These get their own path, covered below, because people go around a matrix that does not allow for emergencies the first time one happens.

The numbers themselves, the limits at which a request moves from one level to the next, are set by the owner, or by the board where there is one, because they reflect the company's size, its margins and how much the owner wants to see personally. There is no generally correct limit that fits every company, and a limit borrowed from another company may be too tight, so it stops work, or too loose, so it controls nothing.

Two rules apply to every type. First, nobody approves their own request; an approver's own request goes to the level above. Second, approval authority belongs to the role, not the person, so when a site manager moves to another site, the authority moves with the new role instead of waiting for someone to remember to change it. We explained that principle in detail in permissions: who sees what once data leaves the file; the approval matrix is the same principle applied to money.

And who approves when the approver is travelling? This is where a matrix that never planned for absence breaks, and the gap gets filled with a message saying approve it for me, or a password two people share. The fix is delegation set up in advance in the system: to whom, for how long, and within which limits. The delegate's approval shows under their own name, marked as on behalf of the original approver, the delegation ends automatically on its date, and the approver sees on their return what was approved while they were away. And if a request sits without a decision past a deadline the owner sets, it escalates to the next level instead of waiting in the inbox of someone on leave.

Two workarounds a system has to close

Around any matrix, however well designed, two workarounds stay open. Taking them needs no bad intent; it is enough that approval is slow and the work will not wait. So a system closes them from two sides: with a control that blocks the workaround, and with an approval fast enough that nobody needs one.

• Splitting the request. A request above the site manager's limit gets split into two or three below it, for the same item from the same supplier within a few days. Each request is fine on its own; together they cross the limit without ever reaching the person who has authority for it. The system closes this by looking at the total, not the single request: requests on the same project that share an item or a supplier within a period the owner sets are added up, and if the total crosses the limit they go to the level that can approve it.
• Approval on WhatsApp. The manager replied OK to a photo of a quote in a group with dozens of other messages. The approval was real, but of what? Which version of the quote, what quantity, which project? Two months later the message is buried under thousands of others, or it sits on a phone that has since been replaced. Meanwhile, for a business subject to VAT, the invoice paid on the strength of it must be kept for at least six years from the end of the tax period it relates to under Article 66 of the VAT Implementing Regulations, while nobody knows where the approval behind the purchase will be.

The fix does not mean going back to paper and pen signatures. The Electronic Transactions Law gives electronic transactions, records and signatures binding effect, subject to the conditions it sets (Article 5), and when weighing the evidential value of an electronic transaction it considers how reliable the method used to create, store or communicate the record is, and whether it could be altered (Article 9(4)). The problem with a WhatsApp approval is not that it is electronic; it is that it is detached from the request it approves. So approval happens on the request itself inside the system, carrying the approver's name, the time, the amount and the version approved, and if the request changes afterwards in quantity or amount, it goes back for approval. WhatsApp stays the alert channel: the approver gets a notification with a link to the request and approves it from their phone without opening a laptop, so slow approval stops being a reason to go around it.

Urgent purchases: a declared path instead of a workaround

A water leak in a hotel room before guests arrive, a pump that stopped on the production line, a site waiting for material to finish a concrete pour already under way. In those moments nobody waits for a full approval cycle, and nobody should. A matrix that ignores this reality does not stop urgent buying; it pushes it outside the system, so the item is bought with cash or out of an employee's own pocket and turns up in the accounts two weeks later with no request and no approval.

The honest approach is a system that admits emergencies exist and gives them a declared path with clear conditions:

• Who can trigger it. Specific roles, such as the site manager or the maintenance manager on duty, not every employee.
• What counts as urgent. A written definition, not a feeling: a safety risk, a stopped operation, or damage that spreads with delay. It is the same logic we suggested for maintenance requests in from report to close: running maintenance requests.
• A minimum of details. What, why it is urgent, and a photo where possible, entered from a phone on site rather than a full form.
• A spending cap. A limit the owner sets on what the urgent path can buy; above it, the approver approves on the request itself, from their phone, before the purchase.
• Approval after the fact, with a deadline. The purchase goes ahead immediately, and its approval is completed within a deadline the owner sets. If the deadline passes without approval, the request appears on a list the owner sees personally.

Then watch the share of urgent requests in your total. Real emergencies happen, but when urgent becomes the normal route in a particular department or site, that is not people falling short; it is a sign that planning there needs a review, or that normal approval is slower than the work can bear.

The Origami view

When we build a purchasing workflow for a company, we start from its current matrix as it actually works, not as it is written in the policy manual: who approves today, where approval gets stuck, and where people go around it and why. The workaround a team takes tells us where the design needs changing before it tells us where control needs tightening.

Then we turn the matrix into a table the system enforces: the limits the owner sets, the type of purchase, delegation and escalation, and the urgent path with its deadline, with approval reaching the approver's phone and recorded on the request itself. We design it so the owner can change the limits when the structure changes, without needing a programmer. This is part of the custom systems we build, described in our services.

An exercise for this week: draw your matrix on one page

Before any system, write down the matrix your company works with today, even if it has never been written down. The owner can run this with the operations manager and the finance manager in one or two sittings:

• List your purchase types as columns: stock materials, services and subcontractors, capital assets, and urgent purchases. Add a type if your company buys something that fits none of the four.
• Put amount levels in the rows at the limits you consider right for your company, and in each cell write the role that approves, not a person's name.
• Name a delegate for each approver to approve in their absence, and set the deadline after which a request escalates to the next level.
• Define urgent in writing, and decide who can trigger it, its spending cap and the deadline for completing its approval.
• Go back to the ten invoices from part one's exercise, and ask of each one: if this matrix had been in force, who would have approved it? And did that person actually approve it?

The gap between the page and reality in that last question is what the system has to close. If you find gaps, check first whether the approver simply was not available at the time, because then the fix is clear delegation, not a stricter control.

In the next part

The need now has a numbered request, and the decision has an approval whose owner is known. The next part moves to the next two stations: the supplier and the quote, then the purchase order. We start with a supplier record entered once and checked when the supplier is added, then compare quotes on one basis, then turn the chosen quote into a purchase order that carries the price, quantity and terms and links back to its request, so it becomes a commitment the owner can see before any invoice arrives.

Sources

• Electronic Transactions Law, Royal Decree No. M/18 dated 8/3/1428H, Bureau of Experts at the Council of Ministers edition — Article 5 (binding effect of electronic transactions, records and signatures) and Article 9 (accepting electronic transactions as evidence, and what is weighed in assessing them).
• VAT Implementing Regulations, Zakat, Tax and Customs Authority (official Arabic text) — Article 66(1) (keeping invoices, records and accounting documents for at least six years from the end of the tax period they relate to).