An internal purchase order template is a form employees use to request and document a planned purchase before it is made. It helps an organization capture what is needed, who will pay for it, and which approvals are required; it is usually an internal record, not the purchase order sent to a supplier.
What an Internal Purchase Order Is
The term internal purchase order can mean different things in different organizations. Most commonly, it refers to an internal request or authorization record used to coordinate a purchase. A requester fills it out, an appropriate manager or budget owner reviews it, and purchasing staff may use the approved details to place the order. The organization determines what the document authorizes and when it becomes valid.
This differs from a supplier-facing purchase order. A supplier-facing PO is a document an organization issues to a vendor to identify items or services, quantities, prices, delivery terms, and other agreed details. An internal form may provide the information needed to create that PO, but it does not automatically replace it. Some organizations use the phrase “internal PO” for a record created in their purchasing system, so always follow the terminology and process used at your workplace.
The form is useful because a purchase often involves more than one decision: what is being bought, whether the need is genuine, which budget should cover it, who can approve it, and who will arrange the order. Keeping those details together makes it easier to review a request and later understand why a purchase was made.
Printable Internal Purchase Order Template
| Internal Purchase Request | |||
|---|---|---|---|
| Request number | Date submitted | ||
| Requester name | Department or team | ||
| Delivery location | Needed by date | ||
| Supplier or suggested source | Budget or cost code | ||
| Business purpose and description of need | |||
| Item or service description | Quantity | Estimated unit cost | Estimated line total |
| Estimated subtotal | |||
| Estimated shipping, tax, or other charges | |||
| Estimated total | |||
| Attachments or supporting information | |||
| Requester sign-off and date | Manager or budget owner approval and date | ||
| Purchasing review and date | Internal reference or order number | ||
How the Internal Request Process Works
A template is most useful when it fits a defined workflow. A typical process moves from a clear request to review, approval, ordering, and recordkeeping. The exact steps depend on the organization, the type of purchase, and its internal policies; this sequence is a practical starting point rather than a universal rule.
- Describe the need. The requester explains what is required, why it is needed, and when it is needed. They identify the relevant team, location, and budget information where known.
- Estimate and support the request. The requester adds quantities and estimated costs, and attaches useful details such as a quote, specification, or scope of work if the process calls for one.
- Route it for review. The manager, budget owner, or purchasing team checks the request against the organization’s approval rules. They may return it for clarification or ask for a different source or specification.
- Place and track the order. Once approved, the authorized employee or purchasing team uses the approved information to arrange the purchase and records the resulting order reference.
- Confirm receipt and close the record. The receiving employee checks that the goods or services arrived as expected, notes discrepancies, and keeps relevant records with the request.
Separating these steps helps prevent a common mix-up: treating a request as permission to buy. A form should make its status clear, for example, “Submitted,” “Approved,” or “Returned for changes.” If approval is required before ordering, the requester should wait for that approval rather than assuming that submitting the template is enough.
Fields to Include and Why They Matter
A useful form asks for enough information to make a decision and track the purchase without demanding details the requester cannot reasonably know. Keep labels plain and provide instructions for fields that are often misunderstood. These fields are commonly useful:
- Request identity: A request number, submission date, requester, and department make the record easier to find and distinguish from other requests.
- Purpose: A short business reason explains the need. “Replacement monitor for the reception desk” is more informative than “equipment.”
- Item or service details: Describe the item, required features, quantity, and unit of measure. For a service, note the work requested, location, and relevant timing or scope.
- Cost estimate: Include a reasonable estimate, currency if relevant, and separate charges where useful. Estimates are not final prices; later documents can record the confirmed amount.
- Supplier information: A suggested supplier or quote reference can help, but it should not imply that the requester has authority to commit the organization to a purchase.
- Budget and delivery details: A budget code or cost center, delivery location, and needed-by date help reviewers understand where the cost belongs and how the request will be fulfilled.
- Approval and tracking: Approval names or roles, dates, status, and the eventual order reference create a basic record of the decision and subsequent action.
Some purchases need extra fields, such as project identifiers, asset tags, contract references, or confirmation that a specification is attached. Add these only when they serve a real review or tracking need. If a field is not applicable to every request, label it optional or provide a clear “not applicable” choice rather than encouraging users to enter misleading information.
Fictional Filled-In Sample
The following example shows the level of detail a requester might provide. The names, organization, costs, and request reference are invented solely to illustrate the form; they are not a quote or a recommended price.
- Request number and date: IR-104, 2 November 2026
- Requester and team: Maya Chen, Facilities
- Purpose: Replace two damaged desk lamps in the shared meeting room.
- Item, quantity, and estimate: Desk lamp, quantity 2, estimated unit cost 28.00, estimated line total 56.00.
- Delivery and timing: Main office reception, requested by 20 November 2026.
- Budget and support: Facilities supplies; product specification attached.
- Approval status: Submitted for manager review; no approval or supplier order is implied by this sample.
Notice that the sample states a practical reason and a requested date, but does not claim that the purchase is approved. It also identifies the estimate as an estimate. This distinction matters when someone later compares the request with a confirmed supplier price or a delivered quantity.
Approval, Roles, and Recordkeeping
Before distributing a template, decide who completes each part. The requester is usually responsible for describing the need accurately. A manager or budget owner may assess priority and budget availability. A purchasing employee may check supplier or ordering details, while a receiving employee may confirm delivery. One person can perform more than one role in a small organization, but the form should still show who made each decision.
Approval rules should come from the organization’s own policy, not from assumptions built into a generic template. For example, do not invent spending limits or state that a particular role can approve every request. If approval depends on amount, category, funding source, or other conditions, point users to the current policy or provide an approved routing guide alongside the form.
Keep the completed request and relevant supporting documents in the organization’s designated recordkeeping location. Useful attachments may include a quote, specifications, an explanation of urgency, or an approval note. Limit access to people who need the information, and avoid collecting personal or sensitive details that are not required to evaluate the purchase. Local recordkeeping and privacy requirements can vary.
Common Problems and How to Avoid Them
- Vague descriptions: A request such as “office supplies” may be too broad to assess. Identify the items, quantities, and purpose at a useful level of detail.
- Missing cost context: A total without quantities or a basis for the estimate is hard to review. Show line items and identify whether the figure is approximate.
- Unclear approval status: A signature line alone may not reveal whether a request is submitted, approved, or completed. Add a status field and date each review.
- Ordering before approval: A requester may mistake the form for an authorization. State plainly that submission does not authorize an order if that matches the organization’s process.
- Outdated fields or routing: A form that points to former roles, old budget codes, or obsolete steps causes delays. Assign someone to review the template when the process changes.
- Duplicate requests: A unique request number and a simple way to search existing requests can help identify repeat submissions before an order is placed.
- Confusing estimated and final amounts: Preserve the initial estimate while recording confirmed order details separately, so a change in cost is visible rather than silently overwriting the original request.
A template cannot by itself prevent every mistake. It works best alongside clear instructions, a known approval route, and a reliable way to tell whether a request is still pending or has moved to ordering.
Choosing a Format and Adapting the Template
A printable table is a good fit when requests are occasional, several people need a paper record, or a signed copy is part of an established process. A digital form can make it easier to route requests, search records, or require certain fields, provided the organization has a suitable process for access and record retention. A spreadsheet may suit a small team that needs a simple request log, but it can become difficult to manage if multiple people edit copies or approvals are recorded inconsistently.
Choose based on how people actually submit, approve, and retrieve requests. Consider who needs to use the form, whether attachments are important, how status changes will be recorded, and where the final record will live. The most elaborate format is not automatically the best: a simpler form that employees complete consistently can be more useful than a complicated one with fields nobody understands.
Before adopting the template, test it against several ordinary scenarios: a single low-cost item, a multi-line order, a service request, and a request that needs clarification. Check whether each case can be described without cramming details into an unrelated field. Then explain what users should attach, who reviews the form, and what happens after approval. If a purchase raises legal, tax, or financial-planning questions specific to your situation, ask a qualified professional.
Frequently Asked Questions
Is an internal purchase order the same as a purchase requisition?
A requisition is generally an internal request to buy something. Some organizations call that record an internal purchase order, while others reserve “purchase order” for the document issued to a supplier. Follow your organization’s definitions and workflow.
Does submitting an internal purchase order authorize a purchase?
Not necessarily. Submission may only start a review. The form should state whether approval is required before anyone contacts a supplier or commits to an order.
Who should approve an internal purchase request?
The organization’s policy determines the approver. Common reviewers include a manager, budget owner, or purchasing team, but roles and approval conditions vary.
Should the template include tax and shipping?
Include fields for estimated additional charges when they help reviewers understand the likely total. If the requester does not know those amounts, label them as estimates or leave them blank rather than presenting guesses as confirmed costs.
Can I use this template for services as well as goods?
Yes, as a starting point. Describe the service, its scope, location, timing, and estimated cost; add any organization-specific fields needed to review or track the work.