Write a Purchase Requisition That Survives Supplier Questions

Overview

A purchase requisition should explain what the business needs, why it needs it, and how an acceptable delivery will be recognized. It should also reveal the assumptions a supplier would otherwise have to invent. The goal is a request that purchasing can turn into a clear commercial conversation without repeatedly reconstructing the user's intent.

A requisition is usually an internal request for approval to buy. It is not automatically a purchase order, a supplier contract, or permission to begin work. Yet weak internal requests often become weak external documents because nobody revisits the missing details. “Replace the reception system” can travel through approvals while still leaving the actual service, interfaces, and delivery responsibility undefined.

Start with the operational problem

Describe the situation that makes the purchase necessary. A team needing replacement shelving might have damaged units, insufficient capacity, or a layout that no longer supports its work. Each problem leads to different requirements. More shelves may not solve a poor layout.

Give the current process a short, concrete description. Who uses the item or service? What work stops or becomes difficult without it? What measurable improvement or restored capability is expected? This creates a basis for checking alternatives.

Avoid writing the justification as praise for a preferred supplier. “Vendor A has an excellent solution” does not explain the need. A stronger statement describes the required outcome and then, separately, any reason a particular supplier or compatible product is necessary.

Place the request at the appropriate stage of the procurement process. An exploratory request can identify uncertainties and authorize research. A request seeking final purchase approval needs a firmer scope and cost basis.

Define the deliverable in terms the recipient can verify

Name the physical goods, service outputs, or capabilities being purchased. Include quantities and units. “Ten licenses” is incomplete if the product distinguishes named users, concurrent users, devices, or locations. “Monthly support” is incomplete if it does not identify supported systems and service hours.

Use a concise requirements table when there are multiple characteristics. Possible columns are requirement, reason, acceptance evidence, and owner. The reason helps reviewers see whether a requirement is essential or merely inherited from an earlier purchase.

For a service, identify the result as well as the activities. US federal performance-based acquisition guidance provides an example of defining required outcomes and measurable standards. Those federal rules do not govern every private purchase, but the discipline is useful: an invoice for hours worked does not, on its own, prove the intended outcome was delivered.

Do not force every characteristic into a numerical target. A file format, required interface, location, or documented handover can be objectively checked without an artificial score. Choose evidence that matches the requirement.

Separate required features from permitted alternatives

A requisition can accidentally eliminate useful options by describing one product in unnecessary detail. If the need is to move supplies through a narrow doorway, the doorway clearance matters. A preferred handle color probably does not.

Classify requirements as essential, preferred, or open to proposal. Explain compatibility constraints that genuinely require a particular model, connection, or material. The supplier can then distinguish a hard boundary from an invitation to suggest a better approach.

Where an equivalent item is allowed, define how equivalence will be assessed. “Or equivalent” without criteria simply moves the disagreement to delivery. State which dimensions, performance, compatibility, documentation, and support characteristics must be preserved.

For a replacement part, the existing identifier may be a useful starting point. Confirm whether it is current and whether the manufacturer has changed the specification. A familiar item number should not substitute for checking that the replacement serves the current application.

State the quantity basis and variation

Explain whether the quantity is a firm purchase, an estimate for quotation, or an expected annual volume with separate releases. These distinctions affect pricing and supplier planning. A supplier may quote differently for a committed annual volume than for an optimistic forecast.

Include the expected distribution across sizes, locations, or variants. A total of 200 uniforms does not tell a supplier the size mix. A software request for 80 users does not identify how many need advanced permissions or occasional access.

Describe permitted quantity variation and who may approve it. If final site measurements will determine the amount, say when those measurements occur and whether the quotation should include a unit rate for adjustment.

Avoid treating estimated demand as a guaranteed order merely to obtain a better price. The commercial documents need to reflect the actual authority and commitment. Otherwise, a later disagreement may concern a promise the requisition author never intended to make.

Map the interfaces and dependencies

Many purchases fail at the boundary with something already owned. A machine may require a suitable electrical supply, a service may require access to customer data, and a storage installation may require clear floor space.

List those interfaces explicitly. State what the buyer supplies and what the supplier must provide. For digital services, identify the necessary data formats, authentication arrangements, supported environments, and handover expectations at an appropriate level of detail.

For physical work, identify access hours, loading restrictions, dimensions, site conditions, and any required installation coordination. Do not expect the supplier to discover every constraint after a fixed quotation is approved.

NIST's supplier scouting process matches specific technical and production capabilities to needs. A practical implication for your requisition is that a supplier search can only be as precise as the relevant requirements supplied to it. “Can make containers” and “can make this container for this application” are different questions.

Distinguish delivery from readiness to use

The date a box arrives may precede the date the business can use its contents. Installation, configuration, inspection, training, or internal preparation can create a second timeline.

Write the required milestones separately. An illustrative equipment request might need shipment confirmation, site delivery, installation completion, acceptance testing, and handover. Each has a different owner and evidence.

Explain whether the date is essential or preferred. If an event creates a firm deadline, state the event and the usable outcome required before it. A supplier should not have to infer that “delivery by Friday” means fully installed before customers arrive Saturday morning.

Identify dependencies on the buyer's actions. If the supplier needs a final design approval within three days to meet production timing, that obligation belongs in the schedule. A deadline dependent on unassigned buyer work is not yet a reliable plan.

Define acceptance before selecting the supplier

For each important deliverable, specify who will accept it and what they will check. Acceptance might involve counting goods, reviewing records, demonstrating an agreed workflow, or confirming compatibility in the actual environment.

Choose evidence the business can realistically evaluate. A requirement for a technical report is weak if nobody can assess whether it covers the requested item. Name the qualified reviewer or arrange support before the purchase.

Separate acceptance from warranty and ongoing performance. An initial demonstration can show that a service works at handover; it does not establish every future response time. Those later obligations need their own measurement and remedy arrangements.

Describe how discrepancies will be handled operationally: where they are recorded, who communicates with the supplier, and who can authorize acceptance with an exception. The requisition should not invent contract terms casually, but it should expose the decisions the commercial agreement must resolve.

Surface commercial assumptions without drafting a contract by accident

Include the proposed budget, expected cost components, and approval boundaries. Identify whether prices need to cover freight, installation, travel, consumables, training, support, taxes, or disposal. The exact treatment depends on the purchase and jurisdiction.

Business.gov.au's supplier guidance recommends clear written supply terms covering matters such as goods or services, price, timing, delivery, and quality. Use that as a prompt to identify commercial questions, while leaving contract drafting and approval to the appropriate people.

For recurring services, state the term being evaluated, renewal assumptions, and exit requirements. A low monthly price can obscure implementation charges or a lengthy commitment. Purchasing needs enough information to compare the complete obligation.

Flag uncertainty rather than silently inserting a guess. A budget based on a prior purchase may be suitable for early planning but insufficient for final approval if scope, volume, or market conditions have changed.

Work through an example requisition

Suppose a small distributor needs a new label-printing setup at two packing stations. The weak request says, “Buy two printers similar to the current model, budget $2,000.” It provides a quantity and a budget but little basis for determining whether the purchase will work.

A stronger request explains that both stations must print the existing shipping label format from the current order system. It identifies the label dimensions, connection environment, ordinary daily volume, peak workload, available workspace, and required handover date. It asks suppliers to identify any ongoing consumable or support dependencies.

The buyer also records what it will provide: access to a test workstation, representative non-sensitive print files, and a staff member who can verify the workflow. The supplier must explain installation responsibilities and provide the relevant setup documentation.

Acceptance could include producing readable labels from each station through the agreed workflow and confirming that staff can reload the chosen media. Technical or carrier-specific requirements would need suitable evidence rather than an improvised visual check alone.

The budget then becomes a total-cost question: devices, initial media, setup, adapters, software, and any recurring charges. A quote that omits a necessary connection component can be recognized before ordering.

Invite questions in a controlled way

Supplier questions often reveal a scope gap. Keep a shared question log rather than answering each supplier privately with different assumptions. Where responses affect the competitive comparison, ensure relevant bidders receive the same clarified requirement through the appropriate purchasing process.

Classify a question as clarification, proposed alternative, or scope change. Clarification explains an existing requirement. An alternative offers another way to meet it. A scope change adds or removes something the original request required.

When the answer changes price, quantity, timing, or acceptance, update the controlled request. An email explanation that never reaches the approved version can produce a quote against one scope and an order against another.

Use the supplier quote comparison to preserve those distinctions. Compare like-for-like offers where possible and show meaningful differences where they remain.

Make approval responsibility visible

Different people may approve the need, budget, technical suitability, security implications, and contractual commitment. A requisition should identify the required decision owners without turning every small purchase into a lengthy committee process.

Scale the review to the consequences. A routine replacement item with a stable specification may need a short request. A service handling sensitive business data or a custom installation may require several specialist checks. The value of the purchase alone does not capture every risk.

Name one coordinator responsible for resolving missing information. Without that role, reviewers can each approve their own narrow part while assuming someone else has checked the whole purchase.

Record approval conditions clearly. If funding is approved subject to a compatibility demonstration, the record should not appear fully cleared until that evidence is accepted. The purchasing team needs an actionable status.

Carry the final scope into the order

Before releasing an order, compare it with the latest approved requisition and supplier response. Check the identifiers, quantities, versions, dates, included services, exclusions, and acceptance arrangements. This is where an agreed clarification can otherwise disappear.

Use purchase order revision control for later changes. The original requisition remains useful history, but the current authorized commitment must be identifiable without reconstructing a chain of messages.

After delivery, note the questions that caused delays or disagreement. Update the next requisition's relevant fields, rather than adding a generic page of warnings to every purchase.

A strong requisition earns its detail by preventing a specific misunderstanding. When each requirement has an operational reason, a clear owner, and suitable evidence, the supplier can respond accurately and the business can recognize whether it received what it intended to buy.