How to Set Purchase Approval Limits by Amount

A Monday morning request for a packaging machine worth Rp18 million arrives in the operations WhatsApp group. A manager replies, “I’ll check,” and someone sends a supplier quote. The conversation moves down the screen as other messages arrive. Two days later, the supplier asks for a purchase order, but the team cannot tell who owns the final decision.

A useful purchase approval process answers practical questions: who submits a request, what information must be included, who checks the need, which amount determines the reviewer, and where the decision is recorded. With those steps written down, a manager can review a request without reconstructing its history from scattered chats.

This article covers internal company processes. Public procurement rules vary by institution and regulation. The Indonesian Ministry of Finance legal database, for example, lists Minister of Finance Regulation 223/PMK.01/2021 on procurement within the Ministry of Finance as effective from 1 January 2022 until revoked. That institution-specific rule does not automatically govern a private company. Set internal authority under your company’s own policies and obtain appropriate advice where needed.

Separate the request from the order and payment

A purchase request explains a need and asks for authorization. A purchase order records an approved commitment under the company’s process. Payment happens at another stage, after the team checks the invoice and its terms. When all three are represented by one status called “approved,” a manager cannot tell whether the team has only asked for permission, placed an order, received goods, or paid an invoice.

Create one master record for each request. Give it an identifier such as PR-2026-0018, then connect the supplier quote, approval, purchase order, receipt confirmation and invoice using that identifier. A shared reference reduces the chance that documents get separated when staff use different names for the same item or supplier.

An initial record might include the submission date, requester, department, branch or site, item or service, reason, quantity, estimated value, needed-by date, proposed supplier, quote, relevant internal budget reference, status, current reviewer and decision. Add a field only when someone uses it to make or check a decision. Unused fields make a form slower without improving the review.

Reference	Requester / department	Need	Estimate	Needed by	Evidence	Status
PR-2026-018	Operations	Packaging unit repair	Rp18,000,000	12 Nov	Two quotes	Manager review
PR-2026-019	People team	Training room chairs	Rp3,200,000	20 Nov	Specifications	Incomplete
PR-2026-020	Project A	Measuring sensor	Rp27,500,000	8 Nov	Quote and reason	Director review

These rows are a synthetic example, not customer records. The amounts, teams, dates and references illustrate a possible form. Replace them with fields that fit your organization.

Decide approval thresholds before requests arrive

Write a matrix that says who reviews each amount and condition. An example internal policy might send requests up to Rp5 million to the department manager, requests above Rp5 million through Rp25 million to both the department manager and finance, and higher requests to a director as well. These figures illustrate the shape of a rule; they are not recommended thresholds for your company.

The amount alone does not define the rule. State whether you calculate the threshold per line item, per request, or across related requests. Without an aggregation rule, someone could split one need into several forms to avoid a review level. Decide how to handle tax, shipping, installation, recurring purchases, emergencies and requests beyond the internally approved budget.

Example condition	Reviewers	Recorded action
Up to Rp5 million	Requester’s manager	Approve, reject or request a correction
Above Rp5 million through Rp25 million	Requester’s manager, then finance	Check the need and relevant internal budget
Above Rp25 million	Requester’s manager, finance, then director	Record each stage’s decision
Required information is missing	Requester completes it	Return status to “incomplete”

The owner and leaders authorized under the company’s governance set the actual amounts. Finance can help assess the review effort and financial impact. The form builder should not invent thresholds or copy another company’s examples without an internal decision.

Specify whether reviews happen in sequence or in parallel. If operations must confirm technical specifications before finance reviews the amount, make the steps sequential. If two reviewers provide separate input, state whether both approvals are required. Name an authorized substitute for absences and record who took over a review.

Make the form easy to complete correctly

Ask the requester to explain the need in working terms: what the team wants to buy, what problem it addresses, who will use it, when it is needed, and what happens if it is delayed. For goods, collect quantity, unit, specifications and destination. For services, record scope, period, expected deliverables and the basis for selecting a provider if company policy requires it.

Match attachments to the request. A supplier quote lets reviewers compare price and scope. Technical documents help confirm specifications. An internal budget reference can help the reviewer understand which resources are involved. Tell requesters who will inspect each attachment and what the reviewer needs to verify.

Use distinct statuses for draft, submitted, incomplete, awaiting approval, approved, rejected, ordered, received and closed where the process needs them. A team may not need every status, but “complete” should not stand for several different events. Approval does not prove that goods arrived, and receipt does not prove that an invoice was paid.

Keep the decision, reason and changes together

Each reviewer should see the request, its documents, prior decisions and the action needed. Offer clear choices such as approve, reject or request a correction. Ask for a short note when someone rejects a request or changes its scope so the requester knows what to fix. Keep the decision time and acting role when your internal controls require that record.

Decide what happens when the amount changes after submission. For example, an initial quote of Rp24 million might become Rp29 million after installation is included. If the revised amount crosses an authorization boundary, send the request to the additional reviewer before placing the order. Keep the earlier value and the reason for the change rather than silently overwriting the original figure.

Define an emergency route too. Specify who may use it, what qualifies as urgent, which minimum details remain mandatory and when a follow-up review happens. A fast route without limits or a record makes later checks harder.

Help the process move by showing a queue that can be filtered by reviewer, request age, amount, department and needed-by date. A notification should point to the request record; it should not become the only place where the decision exists. When someone is away or changes roles, the process owner should update the assignment so a request does not sit with an inactive reviewer.

Test the route with real process examples

Before wider use, test several situations drawn from your organization’s actual process, with sensitive details removed. Include a request below the threshold, one exactly at the boundary, one above it, a changed amount, missing documents, a rejection and an unavailable reviewer. Check that each case reaches the right person and that staff can find the decision later.

Walk through the test with requesters and reviewers. Can the requester tell which document to attach? Can a manager see the reason and the remaining work? Does a changed amount trigger another review? Does “ordered” appear only after the order is placed? Rewrite any status that two people interpret differently.

Common causes of delay include asking for approval in a chat without a request reference, deciding thresholds only after a purchase arrives, allowing someone to approve their own request, and treating approval as payment. A single threshold may also be unsuitable for recurring purchases and emergency work. Write down approved exceptions instead of relying on an unwritten habit.

When a spreadsheet becomes difficult to maintain

If requests, reviewers and statuses are scattered across spreadsheets, consider whether a team application would make the workflow easier to maintain. Sora’s business app overview presents templates by industry. The Sora homepage describes building an application from a team’s workflow or an uploaded spreadsheet. It presents roles, approvals, branches and reports. Its approval example is an illustration, not a customer outcome.

The public product pages also describe conditional approval stages, role-based access, branch records, automatic numbering, reports, version history and audit logs. Review the proposed changes before applying them. Your team still needs to define who has authority and what its purchasing policy requires. For related record-keeping examples, see how teams can track daily cash flow and how to track warehouse stock movements.

Start with one category of purchase

Today, choose one category that staff request often. Write a short form with the requester, need, amount, required date, quotation and decision. Ask the owner or authorized leader to set the approval limits and reviewer substitutes. Run one test request from submission through closure, then change any field or status that still forces someone to guess what happens next.