1. IT Procurement System
  2. Features
  3. Review decisions
Feature · Review decisions

Review decisions

Record the person, revision, outcome and reason behind a purchase decision.

OverviewReview decision register
IT Procurement System · Review decisions

Review decision register

Review decisions

New
ParentReviewerSource revisionDecisionDecided atReason
PR-68462650Approve12 OctApprove rd-340
PR-70519410Return04 OctReject rd-861
PR-58850410Approve09 OctReturn rd-804
PR-58443870Return12 OctApprove rd-308
PR-48074140Approve10 OctReject rd-399
6 of 6 records
Approve rd-340Review decisions · RD-19085
Approve
ParentPR-68462
Source revision650
Decided at12 Oct
Operation keyOK-635
Example screen with sample data

What you can do

Review decisions in daily work

A submitted request has a revision and a requested amount. The reviewer records Approve, Reject or Return on a decision linked to that request, with the source revision, reviewer, time and reason. The operation key helps distinguish the decision action in the evidence trail.

The decision is a separate record from the request status. Its source revision matters when the Buyer changes a supplier, amount or required date. The Auditor can trace what the approver decided without assuming a later request status describes the earlier review.

How the work is organized

  • Ownership. Purchasing Approver records the decision. Buyer prepares the request. Auditor reads the decision record.
  • Record context. Use the parent request and its organization when checking a related record, then confirm the selected supplier and owner where relevant.
  • Evidence. Keep the decision, accepted quantities, attachments and operation outcomes with the same purchase context so later review has the facts in order.

What to agree during setup

Agree who can act as Purchasing Approver for each organization and how a returned request is revised. Keep the reviewer independent from request preparation. Make the decision reason meaningful enough to explain the amount, supplier and required date considered.

Rehearse an approval and a returned request. The Buyer changes the returned request; the Purchasing Approver compares the new revision with the earlier decision before recording a fresh one. Agree how the team will explain a rejection reason to the Buyer.

Check the handoff on an actual case

Open a submitted request, then read its decision record. The source revision should match the request the reviewer examined. Compare the reason and decision time with the status that followed. If the Buyer changes the request, ask for a new review of the new revision rather than treating an older decision as current.

The Auditor should find the reviewer, source revision, time and reason directly from the decision. A decision against an earlier revision does not establish approval of a changed amount or supplier; send the changed request back for review.

What your team sees

  • Requests awaiting review — Open submitted requests with the revision the approver must examine.
  • Review decision register — Read dated outcomes, reviewer names and reasons.
  • Purchase request board — Compare purchasing status without changing the decision history.

Follow the work through

Read request preparation, review and order and receipt reconciliation. The data model shows how the records connect.

What it keeps track of

Data model
Review decisions
Independent reviewer decisions recorded against a purchase request revision.
Purchase requests
IT purchase requests with lifecycle status, owner, counterparty and requested USD amount.
Team members
Authenticated platform identities with an active membership and role in an organization.

Who uses it

Permissions
Purchasing Approver
Records the decision.
Buyer
Prepares the request.
Auditor
Reads the decision record.
App Administrator
Maintains organization membership and supplier configuration.

Set up IT Procurement System your way.

Start free, then use Proto to change fields, steps and approvals before your team goes live.

How to get started