Purchase approval software: who approves spending before an order is placed?

Short answer: purchase approval software connects an employee's request, the responsible approver, their decision and the purchase order. It shows what is waiting, who acts next and what was actually approved. Check your current business software first. A custom app is worth considering for rules or integrations it cannot support.

“Can I order the materials?” A manager agrees over the phone, the supplier's quote stays in an email and the invoice reaches someone else. When quantities change, nobody knows which amount was approved. The missing piece is not just a button. It is an agreed workflow, ownership and a decision history.

This guide covers internal purchasing in a private company, not public procurement procedures. Your company defines its rules and limits. Approving a purchase before ordering is also different from approving an invoice later.

When should you review your purchasing process?

• Requests are scattered across emails, messages and spreadsheets.
• Employees do not know who approves a particular cost or project.
• An absent manager blocks purchasing even when a substitute could act.
• An order is placed before the amount or supplier is approved.
• When an invoice arrives, someone has to find the quote, decision and receipt.

A few straightforward requests and one approver may only need a clear form and better configuration of an existing tool. Multiple roles, repeated exceptions and ERP retyping justify a closer review, not automatically a new system.

Six steps from request to receipt

An illustrative workflow, not a client's internal application. Approved, ordered and received are different states.

1. 01

   Request

   What is needed, why, for which project and by when?

2. 02

   Validation

   Required details, expected amount and the right approver.

3. 03

   Decision

   Approve a specific version or reject it with a reason.

4. 04

   Purchase order

   An authorised person places the approved supplier order.

5. 05

   Receipt

   Confirm the goods actually received or service performed.

6. 06

   Connected records

   A traceable connection between order, receipt and invoice.

What belongs in a purchase request?

Start with the item or service, quantity and unit, reason, proposed supplier, expected amount and currency, cost centre or project, and required date. Make it clear whether tax is included. Add an owner and a supplier quote attachment if the process needs one.

Do not ask for the same data twice. If your ERP already maintains suppliers and projects, use its approved records where the integration allows it. Free text entries such as “Project A” and “Project Alpha” can otherwise create apparently different categories for the same project.

Define approval rules before designing screens

For each cost type, record who may request it, who decides, who substitutes for an absent approver and which changes trigger a new decision. Specify whether every approver must agree or one is sufficient. A reminder is not approval, and an expired deadline should not silently imply consent.

Fictional example: an employee requests €1,240 of materials. Under an illustrative internal rule, the project manager and finance both decide. The approved version is preserved. A later change in quantity and amount triggers another approval. The amount is an example, not a legal threshold or a client's policy.

A substitute needs a defined scope of authority and validity period. Each decision records the person, time, request version and any reason. Other teams' or companies' records must not become visible merely because someone knows a request's URL.

Existing software, integration or custom development?

ODOS Nabava is an example of an existing Slovenian purchasing solution. Microsoft Power Automate also supports approval workflows. Check actual features, licences, connections and maintenance costs before buying. Having Microsoft 365 does not mean every required connector is included.

• Your ERP supports the workflow: configure its module, users and rules first.
• Simple approvals: test a standard workflow in tools you already use.
• The process works but data is retyped: review ERP integration.
• Important roles or exceptions remain unsupported: a focused custom app can complement the existing system.

What happens when something goes wrong?

A rejected request should explain what is missing and who corrects it. Editing an approved request must not overwrite the old decision. A double click must not create two purchase orders. If the ERP is unavailable, show “awaiting transfer”, not a false “ordered” confirmation.

A retry checks whether the record already exists. A partial receipt stays partial, with someone responsible for the remainder. Agree how cancellations work before rollout, especially when an order has already reached a supplier. Resetting an internal status does not cancel an external order.

First pilot: one team and one purchase category

Choose a recurring purchase and involve the requester, approver and person placing orders. Test an ordinary request, rejection, absence, amount change and failed transfer on an agreed sample. Define success before starting.

Compare decision waiting time, active handling time, incomplete requests returned and failed transfers. Do not combine waiting and work into one savings promise. Include licences, rollout and support. See more small business automation examples.

What affects cost and how do we start?

Rules, roles, connected systems, data quality and exceptions determine scope. User count alone is insufficient. Read what custom application pricing includes before comparing quotes with different scopes.

At ČrtaIT, we design and develop business process automation. Describe what you purchase, who approves it, where it gets stuck and your current software. If staff retype attachments, document data capture may be another useful step. A description is enough initially, without confidential quotes, price lists or employees' personal data.