Purchase requisition: Required Fields, Approval Steps, and a Worked Example

A Purchase requisition is an internal request to buy goods or services. It explains what the business needs, why it needs it, and who should approve the spend. It usually comes before a purchase order, which records the order sent to a supplier through the organization’s purchasing process.

This article explains the difference between these records, the fields a request needs, and a practical approval flow. You will also find a worked example, exception rules, and software checks for moving a request into an order without losing its history.

Purchase requisition versus purchase order

A requisition asks the business for permission to proceed. A purchase order records a purchasing commitment in the approved supplier process. Treat them as separate steps even when software connects them closely.

For example, a site supervisor may request replacement tools. Purchasing can review the specification and supplier before issuing an order. The requester’s suggested product may change during that review.

Microsoft’s purchase requisition overview describes the request lifecycle in Dynamics 365. It provides one implementation example, while each organization still needs its own authority rules.

Also distinguish a requisition from a supplier quote and an invoice. A quote proposes terms, and an invoice requests payment for a charge. Neither automatically proves that the business approved the original need.

When should a business use a requisition?

Use a request stage when staff need approval before purchasing or when purchasing needs to review the specification and sourcing. It can help with budget control, consistent records, and planning.

However, not every small purchase needs a long workflow. The process should fit the value, risk, and type of spend. A routine consumable request may need fewer steps than a new software service.

Next, define exceptions such as urgent work and approved recurring purchases. Staff need a valid route when the normal timing does not fit. Otherwise, they may bypass the system and reconstruct the record later.

Keep the policy easy to find. A form cannot tell people when to use it unless the business explains the rule. Name a purchasing contact for uncertain cases.

The fields a useful purchase requisition needs

Start with the requester, department, date, delivery location, and required date. Add a clear description of the need. The approver should understand the purpose without chasing a separate message.

Each line needs an item or service description, quantity, unit, estimated price, and relevant specification. Where the price is not final, mark it as an estimate. Do not make a provisional amount look like a supplier commitment.

Next, include the budget or project reference and suggested supplier if known. A supplier suggestion can help sourcing, but it should not imply that the supplier has already been approved.

Also give the request a stable reference. Keep that ID through approval, ordering, and later questions. A subject line alone becomes hard to track when people revise it.

Separate the need, budget, and supplier decisions

These decisions can involve different people. A supervisor may confirm that the item is necessary. A budget owner may approve the spend. Purchasing may check the supplier and commercial terms.

Therefore, define what each approval means. One general checkbox called approved can hide which questions remain open. The workflow should show the current decision and owner.

For a service involving access to systems or sensitive data, other reviews may apply. Route those questions to the responsible team rather than asking the requester to make a technical judgment.

Next, avoid unnecessary serial approvals. Independent reviews may run in parallel. However, a change in scope or price may require an earlier decision to return for review.

A practical approval flow

Begin with draft, submitted, under review, approved, rejected, ordered, and closed states if they fit the process. Add a returned-for-change route so staff can correct missing information without creating a new request.

Microsoft’s requisition workflow documentation shows header and line review concepts. A request containing several types of spend may need different decisions for different lines.

Next, define who can edit after submission. If the requester changes a significant field, the system should identify which approvals need another review. A previous approval should not silently cover different work.

Also set a clear handoff to purchasing. Approval may permit sourcing rather than authorize immediate supplier contact by the requester. State the next step in the status message.

A worked request example

Suppose a maintenance team needs four replacement inspection lights before a scheduled shutdown. The requester lists the required specification, delivery site, estimated unit price, and job reference. These details form an illustrative example.

First, the supervisor confirms that the equipment supports the planned work. Then the budget owner reviews the estimated total. Purchasing checks whether an existing supplier can provide an approved equivalent.

Next, the supplier quote changes the unit price and delivery date. The process should show the revised terms and route any required approval again. It should preserve the original estimate as history.

Purchasing then issues an order for the accepted items and links it to the requisition. When only three lights arrive, receiving records the partial delivery. The remaining quantity stays visible in the order process.

Finally, finance reviews the invoice against the relevant records. The requisition explains the approved need, while the order and receipt provide later evidence. No single document replaces the whole chain.

Handle estimates and budget checks honestly

A request often begins before the final price is known. Keep estimated, approved, committed, and actual amounts distinct. A dashboard should not add them together as if they were separate spend.

For example, an approved request for 2,000 and a later order for 1,900 may describe the same need. Counting both as 3,900 would overstate the pipeline. Preserve the relationship between the records.

Next, define what a budget check means. The system may show a warning, reserve funds, or block a request depending on the platform and policy. Ask for a demonstration of the actual behavior.

Also review currency and tax assumptions. An estimate may exclude charges that the final order includes. Make those assumptions visible before comparing amounts.

Urgent requests need a controlled route

An urgent purchase may require faster review, but it still needs a record of the need and decision. Define who can authorize the exception and what evidence staff must capture.

Do not use urgency as a permanent substitute for planning. Track repeated urgent requests by cause. They may reveal a stock issue, unclear ownership, or a service planning gap.

Next, distinguish genuine emergency work from a request submitted late. The response may differ, but staff need a clear route for both. A rejected form alone does not resolve the operational problem.

Keep any after-the-fact review explicit. It should not appear as if approval occurred before an order when it did not. Accurate dates protect the usefulness of the record.

Changes, cancellation, and split orders

A requisition can change or end before purchasing acts. Give users a way to withdraw it and stop pending tasks. If an order already exists, the cancellation needs a separate supplier and order review.

Next, test a request split across suppliers. Each order should link to the relevant quantities or lines. The request should show what remains unfulfilled without duplicating the original need.

Also handle rejected alternatives. If purchasing proposes a substitute that the requester cannot use, retain that decision and the reason. This helps future sourcing avoid the same mismatch.

Anomoz’s article on construction procurement software explains related request-to-delivery controls for project work. Apply the same record discipline across departments.

What software should make easier

A useful tool provides clear forms, role-based reviews, reminders, change history, and links to orders. It should also show incomplete work to the responsible person. A searchable archive is useful, but it is not the whole workflow.

Next, check mobile entry. Site staff may need to submit a photo or specification from the field. Keep required fields practical so the team records the request while the information is fresh.

Test delegation and absence. A request should not wait indefinitely because one approver is away. Record the authorized substitute and actual decision maker.

Anomoz’s article on B2B procurement platforms covers wider purchasing capabilities. Start with the request process before expanding into every procurement function.

Integrate without creating duplicate orders

Decide which system owns the approved request and which owns the official order. Use stable references across the handoff. The requester should see the order status without editing the purchasing record directly.

Next, simulate a timeout after order creation. A retry should find the existing order or follow another safe check. It should not create a second supplier commitment.

Also test line changes and partial results. If only some lines transfer, staff need a clear account of what succeeded. A broad success message can hide incomplete work.

If your approval model needs a tailored layer, custom crm development may connect requests, projects, and purchasing. Keep official order and financial ownership explicit.

Measure a few useful outcomes

Track requests returned for missing information, waiting time by stage, urgent exceptions, and orders without linked approval. Define each measure before comparing teams.

Also separate active review time from waiting for the requester. A long total duration may reflect missing specifications rather than slow approval. The distinction helps the business fix the right problem.

Review repeated reasons for rejection or change. They can show where the form or guidance needs improvement. More mandatory fields are not always the answer.

Finally, inspect a sample from request through receipt. The team should be able to explain the need, decision, order, and outcome without reconstructing the story from inboxes.

Roll out the process in one area

Choose a department or purchase category for a pilot. Agree the rules, owners, forms, and handoffs. Then run normal requests and exceptions before expanding.

Train users on changes and cancellations as well as submission. These cases create much of the confusion. Keep a short guide that explains what each approval does.

Also assign an owner for maintaining the workflow. Authority levels, staff roles, and supplier processes change. A request system needs ongoing care to remain useful.

Define what happens when a request stops

Also give rejected, withdrawn, and expired requests clear outcomes. A requester should know whether to revise the same record or start a new one. Preserve the reason and any related discussion so the next reviewer has useful context.

For example, if the team delays a purchase until the next budget period, record the decision and remove it from the active approval queue. Before reviving it, check the need, estimate, supplier information, and budget again. An old approval should not silently become a current order.

Make the request easy to understand and trace

A good Purchase requisition connects a real need with clear evidence, authority, and the next purchasing step. Start with a practical form and defined decisions. Then preserve the links through ordering and receipt.