Purchase Approval Automation: From Requisition to Goods Receipt

A site supervisor sends a message: "we need the spare part today, can I order it?" A manager replies with a thumbs-up. The part is ordered by phone, the supplier invoice arrives four weeks later, and finance has no purchase order to match it against. Nobody did anything wrong by the standards of how the company works. But there is no record of what was approved, by whom, against which budget, or whether a second supplier would have been cheaper — and there are several hundred of these a year.

The request that starts verbally

Most procurement problems in mid-sized companies are not policy problems. The policy usually exists in a document. The problem is that the policy describes a process that starts with a form, while the real process starts with a conversation. Three consequences follow.

• The commitment happens before the approval. Once a supplier has been told to proceed, the approval becomes a formality performed after the money is spent.
• Spend is invisible until invoicing. A budget holder cannot see committed spend because commitment was never recorded, only actual spend once the invoice lands.
• Nobody can reconstruct the decision. Six months later the approval is a chat message in a thread that has scrolled past, or in the mailbox of someone who has left.

The fix is not to ban chat. It is to make the structured path faster than the unstructured one: a request that takes under a minute to raise from a phone, with the requester's usual categories and cost centre pre-filled, and an approval that is one tap.

Approval limits and delegation

An approval matrix is the core of the system, and it is the part that is different in every company. It is defined by three dimensions at once: the value of the request, the category being bought, and the role of the requester. A consumable below a low threshold and a capital item are not the same decision even at the same value.

Delegation is the detail that decides whether the system survives August. When an approver is away, authority has to move to a named substitute for a dated period, recorded as a permission with a start and end date. If it is handled by forwarding email or by sharing a login, segregation of duties is lost precisely when nobody is watching. Build delegation into the first release rather than treating it as a later enhancement — it is the most common reason approvals migrate back into chat.

Collecting and comparing supplier quotes

Where policy requires competitive quotes above a threshold, the requirement fails in practice for a mundane reason: the quotes arrive as PDFs in three different mailboxes and comparing them is manual work that has to be redone every time someone questions the choice. Put the comparison in the request itself.

1. 1. Attach quotes to the requisition, not to an email

   Each quote carries supplier, price, currency, lead time, payment terms and validity date as fields, with the PDF attached underneath. The fields are what makes comparison possible; the PDF is the evidence.

2. 2. Compare on landed cost, not headline price

   Freight, duty, minimum order quantity and payment terms change the ranking often enough that headline price alone misleads. Show the comparison on one screen with the same columns for every supplier.

3. 3. Require a reason when the cheapest is not chosen

   Lead time, quality history or an existing framework are all legitimate reasons. Recording the reason at the moment of the decision costs the requester ten seconds and answers the audit question permanently.

4. 4. Enforce the threshold in the form

   Below the policy threshold, one quote. Above it, submission is blocked until the required number is attached. A policy that is only enforced by an auditor after the fact is not enforced.

Linking to the purchase order and goods receipt

An approved requisition that does not become a purchase order in the same system leaves the same gap you started with. The chain has to hold end to end: requisition, approval, purchase order sent to the supplier, goods receipt recorded when the delivery arrives, invoice matched against both. That last step is the three-way match, and it is the control that catches quantity and price discrepancies before payment rather than during a year-end review.

Two design points matter more than they appear. Partial deliveries must be first-class: a receipt for six of ten units should leave four open on the order rather than forcing someone to close it and raise a second order. And the goods receipt should be recordable by the person who physically receives the goods, on a phone, at the point of delivery — for the same reason document capture belongs at source. Field and manufacturing systems such as Elevatora SAHA and Elevatora İMALAT are built around that assumption.

Hitting the right budget line

The budget line is chosen at the point of request, by the requester, who is the person least interested in the chart of accounts. Two things reduce the misallocation rate. First, default the cost centre and account from the requester's role and the item category, so the common case needs no decision. Second, show remaining budget on the request screen including committed but not yet invoiced amounts, because a budget holder who cannot see commitments is approving against a number they know is stale.

Decide deliberately what happens when a request exceeds the remaining budget: hard block, or route to an additional approver with the overspend shown explicitly. Both are defensible; leaving it undefined means the system will be worked around.

The audit trail, and why a fixed template does not hold

Every state change is recorded with actor, timestamp and previous value: raised, edited, approved, rejected, delegated, cancelled, ordered, received, matched. The trail must survive changes to the approval matrix, so store which rule version applied to each request rather than only the current configuration. An auditor asking why a request took a particular path last year needs the rules as they stood then.

This is where packaged procurement modules run into trouble. Thresholds, delegation depth, quote requirements, capex treatment and budget structures differ between companies and often between legal entities inside one group, and the template forces you to adopt the vendor's model or maintain the real policy outside the system. The trade-off is set out in packaged software versus custom; the build approach is described under custom software development.

Budget and timeline

• Single focused module: $3,000–6,000, 2–4 weeks. Requisition, approval matrix, delegation, audit trail.
• Multi-department procurement system: $8,000–15,000, 4–8 weeks. Adds quote comparison, purchase orders, goods receipt and budget control.
• Platform with AI on top: $20,000+, 3–6 months.
• Annual maintenance: optional, 12–25% of build cost.
• Licence: perpetual, unlimited users, source code delivered.

The first clickable prototype arrives within 2–4 weeks, so your approvers test the matrix against real requests before the rest is built.

Bring your approval matrix — even as a page of notes — and we will scope the first module against it. Request a quote, or review the delivery bands on the pricing page.

Frequently asked questions

What is a purchase requisition system?

The internal request that comes before the purchase order. Someone states what they need, why, and against which budget; the request is routed for approval according to value and category; only then does a purchase order go out to a supplier. Without it, the order is the first record anyone in finance sees.

How do approval limits and delegation work?

Each role carries a value limit per request and, usually, a monthly cumulative limit. Requests above a limit escalate one step up the matrix. Delegation is a dated transfer of that authority to a named substitute for a period, recorded as a permission change rather than as a forwarded email.

Do we need three supplier quotes for every purchase?

Most policies require competitive quotes only above a threshold and outside framework agreements. The system should enforce whatever your policy says: below the threshold, one quote; above it, block submission until the required number of quotes is attached and a reason is recorded if the cheapest is not chosen.

Why can't we just use an off-the-shelf approval template?

Approval thresholds, delegation rules, budget structures and quote requirements differ between companies and often between entities in the same group. A template forces you to adopt someone else's policy or to keep the real policy in a side channel, which is how approvals end up back in email.

What does a purchase approval module cost at KodDelta?

A single focused module is $3,000–6,000 and ships in 2–4 weeks. A multi-department procurement system with budget control and supplier comparison is $8,000–15,000 over 4–8 weeks. Annual maintenance is optional at 12–25% of build cost. The licence is perpetual, users are unlimited and source code is delivered.