Give stores a clear authorization to release materials, then reconcile what was issued, what remains open and what came back.
A material requisition is an internal request for stock your organization already holds. It is not an instruction to buy from a supplier. For service and facilities teams, the useful record connects a job, an approved quantity and the storekeeper’s actual handover—not just a list of things someone wants.
This material requisition form template is complete inline. Copy the header, line table and movement log into a shared document or spreadsheet. The rules below are a suggested operating design for ordinary consumable supplies; adapt them to your own approval policy. They are not a purchasing policy, inventory valuation method or authorization to handle regulated materials.
Choose the right record before requesting stock
The University of Oxford’s stock requisition form separates requested and issued quantities and records authorization, project coding and picking evidence. Those are useful distinctions even in a much smaller stores operation.
- Materials already in stores: use this requisition to request their release.
- Materials must be bought: use a purchase requisition. Link the buying request to any stock shortage; do not treat a stores approval as spending approval.
- The job itself needs authorization: keep its scope and execution in a work order. One work order can reference several material requisitions.
- A reusable item must come back: use an equipment checkout record for its identity, borrower and return date.
Copy the material requisition header
Create one request per job and issuing store. Use a new request for a different store, with a cross-reference if needed. Keep the template version on each record so later changes do not silently change an earlier approval.
Template version: MR-1 Requisition ID: [unique, never reused] Created at: [date/time and time zone] Requester: [name, team, contact] Job/work order ID: [reference] Purpose: [what the materials support] Cost center/project code: [validated internal reference] Issuing store: [site/store code] Delivery/pickup point: [exact location] Needed by: [date/time and time zone] Requested priority: [routine / time-critical, with reason] Request owner: [person responsible for corrections and open lines] Approver: [authorized person or role] Approval decision: [pending / approved / revise / rejected] Approval evidence: [name, timestamp, record reference, conditions] Stores owner: [person responsible for issue records] Current request status: [derived using the rules below] Next action / owner / due at: [required while not closed] Closeout: [closed by, timestamp, evidence reference]
All header fields are required except closeout until closure. Treat IDs, codes and names as text; use date/time fields for timestamps and a controlled choice for decisions. “Time-critical” explains a deadline—it does not bypass approval. Set actual response targets locally rather than assuming the needed-by date is a promise from stores.
Copy the request line table
Add one row per item and stocking unit. Repeat the row for additional items. If your store issues boxes, record boxes throughout; do not subtract individual pieces from a box quantity without a documented conversion and approval.
| Field | Type and validation | Completed by |
|---|---|---|
| Line ID | Unique text within this request, such as 01 | Requester |
| Item code and exact specification | Text; existing stores code plus distinguishing size/grade. An unknown item goes back for clarification. | Requester; stores verifies |
| Unit of measure | Choice from the store’s item record; one unit per line | Stores verifies |
| Requested quantity | Number greater than zero; whole numbers for indivisible units | Requester |
| Approved quantity | Number from zero to requested quantity; blank until decision. Increase the request through a recorded revision before approving more. | Approver |
| Substitution permitted? | Yes/no; if yes, list the approved alternative specification and approving authority. No implied permission. | Approver |
| Issue, return and cancellation totals | Numbers derived from the movement log, not manually guessed | Stores owner |
| Open quantity and next action | Calculated remainder plus named owner/due time if positive | Request owner |
| Line closure evidence | Final reconciliation, receiver evidence and linked stock-record references | Stores owner |
An approval should identify the request version and each line’s approved quantity. A rejected line has zero approved quantity and a reason. Never interpret a blank approval as zero, or a signature without a version reference as approval of later additions.
Copy the movement log
Use a separate row for every issue, return or canceled remainder. This is the transaction history; do not overwrite the original requested or issued quantity when something changes.
Event ID | Requisition ID | Line ID | Event type | Quantity | Unit Event timestamp and zone | Issuing/receiving store | Job reference Handled by | Counterparty | Receipt/acknowledgment reference Authorization/reference | Condition or exception | Stock-posting reference
Event type is ISSUE, RETURN or CANCEL_REMAINDER. Every quantity is positive. An ISSUE needs an approved line, matching item/unit, storekeeper and receiver acknowledgment. A RETURN needs a linked earlier issue, receiving person and condition/disposition note. A cancellation needs the request owner’s reason and the authorized approver’s confirmation; use “not applicable” for a physical receiver or stock posting because no stock moved.
For multiple physical handovers, use multiple ISSUE rows. If stock records are maintained separately, link their transaction references. A signed request or planned pick does not prove stock left the store. An unresolved stock-posting or handover discrepancy remains an exception, not a closed request.
Calculate fulfillment without hiding shortages
Use these definitions for each approved line. They measure request fulfillment, not stock on hand, material consumption or accounting value.
- A = approved quantity.
- I = total quantity in valid ISSUE events.
- R = total quantity in valid RETURN events.
- C = total approved remainder canceled through CANCEL_REMAINDER events.
- Open quantity = A − I − C.
- Net issued quantity = I − R.
Require I + C ≤ A, R ≤ I and nonnegative results. Do not clamp a negative result to zero: flag and investigate it. Validate before recording every event so the next issue or cancellation cannot exceed the current open quantity.
A return does not reopen approval in this template. The original release was fulfilled. If replacement material is needed, record a new linked request and approval. Otherwise a return could quietly allow repeated releases under one unchanged authorization.
Use explicit statuses and closure gates
| Status | Entry condition | Owner and next step |
|---|---|---|
| Draft / needs correction | Required data missing or returned for revision; no issue allowed | Requester corrects before resubmission |
| Pending approval | Complete version submitted; decision outstanding | Approver records a line-level decision |
| Approved, unissued | Approved quantity positive; no issue and open quantity positive | Stores checks availability and confirms a fulfillment plan |
| Part issued | Some issue recorded; open quantity still positive | Request owner agrees the remainder’s issue date or cancellation |
| Ready to close | Every approved line has zero open quantity; rejected lines have reasons | Stores reconciles movements, acknowledgments and posting references |
| Closed | Reconciliation complete; no unresolved exception; closeout signed and timestamped | Request owner retains linked evidence |
Use a separate exception flag for shortages, disputed receipt or posting errors. At request level, unresolved approval/correction takes precedence; then open approved lines keep the request open. A fully rejected request closes with the decision evidence and no movements. If nothing was issued and all approved quantities were canceled, close as “canceled before issue,” not “fulfilled.”
Worked example: partial issue, cancellation and return
This fictional example uses ordinary cable ties, not controlled or safety-critical materials. Requisition MR-014 supports work order WO-204 at North Stores, with project code FAC-07. Requester Jo requests 12 bags of item CT-200, each bag containing 100 ties, needed by 09:00 on November 13. Manager Dana approves 10 bags against version MR-1 at 15:00 on November 12. The other two requested bags are not authorized.
| Event | Quantity | Evidence and result |
|---|---|---|
| E01 ISSUE, Nov 13 08:30 | 6 bags | Storekeeper Lee; Jo acknowledges receipt RC-01; stock issue SI-01. Open = 10 − 6 = 4. |
| E02 ISSUE, Nov 13 10:00 | 2 bags | Lee; Jo acknowledges RC-02; stock issue SI-02. Open = 10 − 8 = 2. |
| E03 CANCEL_REMAINDER, Nov 13 10:20 | 2 bags | Jo confirms reduced need; Dana authorizes CR-01. Open = 10 − 8 − 2 = 0. |
| E04 RETURN, Nov 13 14:00 | 1 bag | Linked to E02; Lee receives sealed bag under RT-01; stock return SR-01. |
All example times are America/Chicago. Final totals are approved 10, issued 8, canceled remainder 2 and returned 1. Net issued is 7 bags; open approval remains 0 bags. Seven bags are not proof that seven were consumed. The job’s usage record must establish that separately.
Stores can close after checking RC-01/02, CR-01, RT-01 and the three stock-posting references. Had the final two bags merely been unavailable, open quantity would have stayed at two until a later issue or authorized cancellation. Short stock is not a reason to reduce the original approval silently.
Run the form from submission to closeout
- Requester checks the need. Enter the job, store, exact items, units and quantities. Check for an existing open requisition for the same job before submitting.
- Approver decides against a fixed version. Approve, reject or return each line for correction. Record conditions and authorized substitutes explicitly.
- Stores confirms the plan. Check availability in the authoritative stock record. Record a pickup or delivery arrangement, or a shortage owner and next review time. Approval does not reserve stock.
- Storekeeper and receiver record the actual handover. Verify item, unit and quantity together; append the event and receipt evidence. Record partial issues separately.
- Request owner clears open quantities. Before the needed-by time, review any unissued balance with stores. If the deadline passes, mark it overdue and escalate to the operations manager with a revised plan.
- Stores reconciles and closes. Resolve outstanding quantities, acknowledgments and stock-posting exceptions. Record the closeout owner and timestamp.
Prologic First’s Issue Request documentation illustrates a department requesting materials from a store using item, unit and quantity details. It is one product’s process, not a universal approval requirement. Set your own authority and timing rules before using this template.
Handle exceptions without rewriting history
- Wrong item or substitute: stop the issue. Obtain a versioned revision or explicit alternative authorization; do not rename a line after handover.
- Damaged or opened returns: record receipt and disposition separately. A returned item is not automatically available stock; the responsible stores reviewer decides under local rules.
- Incorrect event: flag the record and link a documented correction approved by the stores owner. Recalculate from the corrected valid event set; do not erase the original entry or invent a physical return.
- Urgent or after-hours issue: use the locally designated authorized approver and record actual timestamps. If required authority is unavailable, escalate rather than backdating approval.
- Specialist stock: this general template does not replace controls for hazardous materials, regulated goods, expiry-sensitive stock or safety-critical parts.
Where Workhint fits
A shared document is enough to start. Workhint’s Workflow Engine describes role-based approval routing and required information before a step advances. Its workflow automation software page describes custom intake forms and tracking stages, owners and next actions.
Those capabilities are relevant to coordinating this request and its human decisions. They do not establish stock reservation, warehouse scanning, inventory costing or automatic stock-ledger posting. Keep the stock system authoritative and confirm any required integration separately. The quantities and closure rules above are the proposed template design, not a claim that Workhint supplies a prebuilt inventory module.
FAQ
Is a material requisition the same as a purchase requisition?
No. This form asks an internal store to release materials already held. A purchase requisition asks for permission to buy. Link them if a shortage requires buying, but keep the approvals separate.
Can one request have several issues?
Yes. Add a movement row for each handover, linked to its request line and receipt evidence. Stop when cumulative issues plus canceled remainder reach the approved quantity.
Should returns reduce the outstanding requested balance?
Not in this design. Returns reduce net issued quantity, not the approved quantity still awaiting fulfillment. Use a new linked authorization if replacement material is needed.
Can I use this as a stock balance spreadsheet?
No. It tracks fulfillment of a request. It does not include every receipt, transfer, adjustment or other movement needed to calculate stock on hand.
Start with one store and one job type
Choose the authorized approver, stores owner and exception review time. Copy all three parts of the record, then walk through a partial issue and a return before accepting live requests. Keep the first version narrow enough that people can reconcile every line without guessing.

Leave a Reply