NetSuite Purchase Request vs Requisition: Intake Design

Executive Summary

NetSuite offers three ways to start a purchase: the Purchase Request, the Requisition, and a direct Purchase Order (PO). Oracle's Help Center states the core distinction plainly. A requisition can be entered "even with limited information" and without a known vendor or price ^[1], while a purchase request needs a vendor on the form and maps one request to one PO. A single requisition can produce one or more POs across vendors, and a buyer can consolidate demand from several requisitions onto one PO ^{[2] [1]}.

The licensing question decides whether the choice exists at all. Oracle's SuiteProcurement and approval-preference pages state that Advanced Procurement must be provisioned to use the Requisitions feature ^[3], and the Requisition Approval Workflow ships in the Advanced Procurement SuiteApp (bundle ID 57060) ^[4]. Oracle's Enable Features and Requisitions Setup pages do not mention that dependency, and partner articles diverge on how to describe it (Source: www.anchorgroup.tech). The practical rule for an implementation lead is to verify entitlement in the account before promising a requisition design.

The recommended intake policy follows four tests. First, does the requester know one vendor and a price? If yes, a purchase request or a direct PO fits. Second, can one request span vendors? If yes, only a requisition works. Third, does a buyer need to consolidate demand across employees? If yes, requisitions are the only documented path. Fourth, is the account OneWorld? A requisition carries exactly one subsidiary, so multi-subsidiary demand needs one requisition per subsidiary.

Controls matter as much as the transaction choice. Standards guidance separates authority, custody and accounting duties ^[5], and NetSuite gates direct ordering from a requisition behind a separate Requisition Approval permission. The reconciliation design in this report links every requisition line to its PO line, PO line to item receipt, and item receipt to bill, the same three-way logic that university payment policies require ^[6]. Header memos and attachments do not carry over to a PO built from several requisitions ^[7], so the policy treats line-level references as the audit trail. Thresholds and cycle-time targets are left for each company's controller to set, because no vetted public benchmark supports a universal number.

Introduction and Background

This report examines one design decision: which NetSuite transaction should open a purchase, and what must be true downstream so that the choice survives audit. The audience is a procurement manager, a controller, and the NetSuite implementation lead at a growing multi-department company. The report does not repeat product glossaries or the PO-approval tutorial. It builds a decision tree, a transaction-choice matrix, a RACI (responsible, accountable, consulted, informed) assignment, a record-to-record reconciliation, and an acceptance-test list that together form a signed intake policy.

Disclosure: the publisher, Houseblend, is a Montréal NetSuite consultancy that implements and administers the platform. The analysis below relies mainly on Oracle documentation and independent control guidance; the publisher's own pages are not used as evidence, and the design is platform-neutral across implementation partners.

Why the terms collide

In everyday procurement language a requisition is an internal document that tells purchasing what is needed, and the PO is the document sent to the supplier. Government and university manuals use this vocabulary consistently. Ohio's state procurement glossary defines a requisition as an internal document by which a using agency communicates needs ^[8], and a PO as the purchaser's written document to a vendor ^[8]. Arkansas describes the requisition as generally the first step in procurement ^[9], and Montclair State University names the PO, not the requisition, as the official authorization for the supplier ^[10].

NetSuite adds a third record, the purchase request, which behaves differently from the textbook requisition. Oracle defines it as a transaction that records a purchase that needs to be made ^[11], and it states that purchase requests are similar to requisitions but serve a different purpose. A practitioner warns that the two are easy to mix up in the Employee Center ^[12]. That confusion is the reason a written intake policy is worth the effort.

Scope and method

All NetSuite behavior in this report is taken from Oracle's Help Center pages as retrieved in November 2026, and Oracle pages do not carry revision dates, so readers should confirm behavior in their own release. Partner articles are used only to show how practitioners describe the choice, and they are labeled as such. Control principles come from the U.S. Government Accountability Office (GAO), state auditors and university procurement manuals. Where sources disagree, the disagreement is stated rather than resolved.

Purchase Request: Known Vendor, One Request, One PO

Capabilities

The purchase request is the lighter record. Oracle states that the request details the item needed and the anticipated price, and the entry form asks the requester to select the vendor who will provide the good or service. Employees with the Employee Center role enter the request, and an administrator enables the Purchase Requests feature on the Employees subtab of Enable Features.

Approval is built into the base mechanism. Without Approval Routing, a request becomes a PO as soon as the immediate supervisor approves it ^[13]. With Approval Routing, the approver needs a purchase approval limit at or above the request amount, and a request above that limit moves to the next level of management. Oracle also directs organizations using Approval Routing to enter purchase requests through the Employee Center to preserve the hierarchy.

Adoption

Partner guidance places the purchase request in the base product. Sikich, writing in 2018, says purchase requests are included in base NetSuite while requisitions belong to Advanced Procurement ^[14], and it recommends requests when the person asking knows whom they are buying from ^[14]. Anchor Group gives the same one-line rule (Source: www.anchorgroup.tech). A Concentrus article adds a licensing observation: users given the Employee Center role do not consume a full license ^[12].

Strengths and limitations

The strength is speed with accountability. The requester has already done the sourcing, so the buyer does not need to rework vendor or price, and the one-request-to-one-PO rule gives a clean, easy reconciliation. The limitations are structural. Oracle's comparison states that a request cannot hold more than one vendor, cannot be consolidated with other employees' demand, and cannot be processed in bulk. A OneWorld requester on a standard Employee Center role also sees all customers as Ship To values, unrestricted by subsidiary or sales team, which is a data-exposure point for the controller to review. Approval queues likewise ignore role-level subsidiary restrictions.

Requisition: Partial Information, Buyer-Led Sourcing

Capabilities

The requisition is designed for incomplete information. Oracle says a requestor can start one without knowing the exact price or vendor name, and that this information can be added later ^[1]. Each line still needs an estimated rate or amount for approval, and a vendor must be chosen before the requisition can be processed for purchasing. Requestors can be employees, supervisors entering for subordinates, or users in an Administrator role, and files from the File Cabinet can be attached to support technical requirements.

Downstream, one requisition can be parceled to several vendors' POs, and many requisitions can be consolidated onto one PO to capture a volume discount ^[15]. Numbering is separate from PO numbering, which keeps request and commitment records distinct. A practitioner summarizes the entry burden as item and quantity only ^[2], and another notes that lines can be free-text descriptions for non-catalog purchases ^[16].

Adoption and entitlement

Adoption depends on entitlement. Oracle's SuiteProcurement page says to ensure that Advanced Procurement is provisioned to use the Requisitions feature, and the Requisition Approval Workflow page ties that workflow to the Advanced Procurement Module. Oracle's Procurement Dashboard page adds that the Advanced Procurement Module is purchased through a NetSuite sales representative. Epiq describes Advanced Procurement as a separately licensed add-on, not part of every base license ^[15].

Sources are not fully consistent. Oracle's Requisitions Setup and Enable Features pages describe turning the feature on without naming Advanced Procurement, and two articles from the same partner differ on whether requisitions exist in standard NetSuite: one marks them "Limited or feature-dependent" (Source: www.anchorgroup.tech), while the other marks them "Not available" for standard procurement (Source: www.anchorgroup.tech). The prudent reading is that the Enable Features checkbox is evidence of entitlement but not proof of an approval workflow, and the account should be checked for the managed Advanced Procurement SuiteApp (bundle ID 57060).

Strengths and limitations

The requisition supports a procurement function that wants to decide vendor, price and quantity after demand is visible. Sikich recommends requisitions when a company has a buyer or procurement department ^[14]. The limitations are process overhead and a longer path to a commitment. Approval for requisitions requires a SuiteFlow workflow ^[17], purchase contracts do not apply to requisitions in the SuiteProcurement flow, and a requisition is limited to one subsidiary in OneWorld. The feature also cannot be switched off while any requisition remains open, since Oracle allows disabling only when every requisition is Closed ^[18]. That makes the decision hard to reverse.

Direct Purchase Order: Buyer-Originated Commitments

The third path skips the intake record. A buyer or authorized user creates the PO and routes it for approval, and nothing precedes it. A PO commits the company to the supplier. Montclair State University names it as the instrument that authorizes the supplier to deliver ^[10], and Lehigh University encumbers budget at PO creation rather than at requisition ^[19]. Zone and Co frames the pair as the requisition controlling approval and the PO committing the spend ^[20]. The University of Maryland glossary likewise says purchase requisitions authorize approval to expend funds ^[21], and Lehigh notes that once fully approved the requisition becomes a purchase order ^[19].

A direct PO suits repeat purchases from established vendors where the buyer already owns the relationship, standing blanket arrangements, and urgent replenishment. It should not be the default for employee-originated demand, because there is no earlier record to carry the requester's identity, budget owner and justification. Oracle documents that an approved PO must be recalled before it can be edited, so changes after approval re-enter the approval path.

Policy writers sometimes allow a threshold below which no requisition is needed. Arkansas does this explicitly, exempting small orders from requisitions ^[9]. A NetSuite policy can mirror the idea, but the dollar level is a controller decision and is not suggested here.

Feature Comparison

Table 1 below combines the Oracle-documented differences with the control attributes an implementation lead needs when deciding which record opens a purchase. It compares the transactions on seven attributes: input completeness, vendor count, approver, buyer action, output, license, and traceability.

The matrix shows that the three records are not interchangeable. The requisition column is the only one that can absorb incomplete information, multiple vendors and cross-employee demand, and it is also the only one with a documented licensing precondition. The purchase request wins on simplicity and the direct PO wins on speed, but each pushes a different responsibility onto the buyer. Where a company needs both a lightweight path and a consolidating path, Oracle states that the two features can be enabled together ^[1]. A reasonable default for a first release is one intake method, with the second added after the first is stable.

Decision Tree and Prerequisites

The one-page tree

The decision tree below turns operational facts about the purchase into ordered questions. Steps 2-4 assume the Requisitions feature is available; step 5 confirms that entitlement, so check it first if you are unsure. Evaluate the questions from the top and stop at the first definitive answer.

1. Is the commitment already negotiated, repeat, or under a standing arrangement owned by purchasing? If yes, a direct PO is appropriate and no intake record is needed.
2. Does the requester know one vendor and a price? If no, use a requisition. If yes, continue.
3. Could the same item be requested by several employees or departments in the same buying window? If yes, use a requisition so a buyer can consolidate. If no, continue.
4. Does the request span more than one vendor? If yes, use a requisition. A purchase request holds one vendor only.
5. Is Advanced Procurement provisioned and the Requisitions feature enabled? If no, a purchase request or direct PO is the only choice until entitlement is resolved.
6. Is this a OneWorld account? If yes, require one subsidiary per requisition and one requisition per subsidiary.
7. Do line-level class, department and location need to survive into the PO? If yes, use a requisition and test the copy behavior, since Oracle documents that these values copy from requisition lines to the PO lines ^[7].

Prerequisites checklist

Before publishing the tree to employees, an implementation lead should confirm the following, each of which Oracle documents:

• Features: Purchase Orders and Requisitions enabled, with the Employee Center or Consultant role assigned to the appropriate users.
• Approval routing: approval routing for requisitions requires additional features beyond the Requisitions checkbox.
• Employee records: the Purchase Limit and Purchase Approver fields are required for the requisitions workflow, and an employee with no limit needs an explicit 0.
• Role assignment: the Employee Center role must be given to every employee who needs requisition access.
• Consolidation preference: the Maximum Purchase Lines to Consolidate preference defaults to 10 and accepts up to 250 ^[22].

Signed intake policy elements

The policy that the procurement manager, controller and implementation lead sign should contain the following elements, each with a named owner and a version date:

• Scope: which spend categories use a purchase request, a requisition, or a direct PO, with the decision tree attached.
• Entitlement statement: confirmation that Advanced Procurement is provisioned, or that requisitions are out of scope for this release.
• Approval bands: dollar bands and approvers, set by the controller and entered as employee purchase limits, not copied from this report.
• Duty separation: the RACI table, plus a named compensating review wherever one person holds two roles.
• Vendor and price rule: who supplies vendor and price on each path, and the maximum age of an estimate before re-approval.
• Reference rule: every PO line must carry its requisition or request reference, and consolidated POs must carry re-attached supporting documents.
• Exception rule: retrofit POs, rejected items and variance beyond tolerance are logged and reported to the controller.
• Review cadence: a periodic reconciliation of open requisitions, partially ordered lines and unmatched receipts, with the results signed by the controller.

Approval Design and Separation of Duties

Approval mechanics

Requisition approval has more moving parts than request approval. Oracle describes the Requisition Approval Workflow as matching the standard purchase request approval feature, and the workflow auto-approves a request when no supervisor or approver is designated. If the amount exceeds the highest approval limit, the workflow shows that no approver can approve it. While a record is pending approval it is locked for editing from all roles except the administrator. A rejected requisition may be editable and resubmittable through approval again, but the requisition approval pages reviewed do not state this, so confirm it in your account.

Because auto-approval can occur when approver fields are blank, the controller should treat employee-record completeness as a control. Approval can also be done in bulk, which speeds throughput and also concentrates risk. SuiteFlow-based approvals support non-sequential or conditional routing, and Employee Center is the primary approval workspace, where approvers need only the View permission.

The approval status is separate from the purchasing status. Oracle states that the requisition status is distinct from the approval status, and an approved requisition with no POs sits at Pending Order. Reports and queues should therefore use both fields. Epiq describes a common tiered pattern of auto-approval under a set amount, manager approval in a mid band, and executive approval above a ceiling ^[15], and the exact amounts remain a policy decision.

Who does what

Standards guidance gives the logic for assigning duties. GAO's Green Book defines segregation of duties as dividing key duties so that no one individual controls all key aspects of a transaction ^[5], and it says management considers the separation of authority, custody and accounting ^[5]. The Idaho State Controller's checklist lists authorization to execute transactions as one of the functions to keep apart ^[23], and a purchasing-specific example says people who acknowledge receipt should not also perform purchasing ^[23]. The Minnesota Office of the State Auditor states the ideal that no single person should authorize, record and hold custody (Source: www.osa.state.mn.us).

Segregation is not always achievable at a growing company. GAO's Green Book says management considers segregation of duties when designing control activities ^[5], and the University of Arizona's COSO-based page says that where segregation is not practical, management selects alternative control activities ^[24], such as a post-hoc review by the controller. ISACA adds that effective segregation requires a clear understanding of actors, roles and potential conflicts ^[25].

Table 2 below proposes a RACI assignment for the intake process, derived from the duties above. R means responsible, A means accountable, C means consulted, and I means informed.

The RACI keeps the requester out of vendor selection on the requisition path, keeps the buyer from approving what the buyer orders, and keeps the receiver apart from purchasing, consistent with the Idaho receipt example ^[23]. In small companies one person may hold two roles, and the policy should then name a compensating review. Oracle documents a permission distinction that supports this design: ordering directly from a requisition needs the Requisition Approval permission at Edit, Create or Full ^[7]. A role matrix should therefore be tested against the standard roles before custom roles are cloned.

Buyer Handoff and Record-to-Record Reconciliation

From approved requisition to PO

Once a requisition is approved it appears for ordering. Oracle's bulk ordering page says the Order Requisitions list includes requisitions in Pending Order or Partially Ordered status, with items needing a vendor and rate and expenses needing a vendor and amount. The buyer can filter by requisition, subsidiary, vendor, item, department and class. Lines from several requisitions can share a PO, limited only by the consolidation preference, and setting that preference to 0 consolidates all of a vendor's lines into a single PO.

Automatic purchasing is possible using preferred vendors and pricing, but Anchor Group notes it relies on item-level vendor and pricing configuration and describes manual conversion as keeping the buyer in control (Source: www.anchorgroup.tech). A buyer-controlled conversion is the safer default for a first deployment.

What survives into the PO

Line-level references are the reconciliation backbone. Oracle shows requisition numbers on PO lines and PO numbers on requisition lines ^[1], and the requisition displays the total, linked PO number and linked PO status. Class, department, location and memo values copy from requisition lines to the PO lines. The header memo and any attached file copy only when all ordered lines come from a single requisition ^[7], so supporting documents attached to a consolidated requisition must be preserved elsewhere or re-attached to the PO.

Oracle's reviewed pages do not state whether the requisition's estimated rate copies to the PO line or is overridden by the buyer's rate, and they do not describe a budget check on requisitions. Both behaviors should be tested rather than assumed, as the acceptance tests below require. Editing also has rules. To delete a requisition line that has been ordered, the linked order line must first be deleted, and deleting a PO line removes the link and returns the requisition line to Order Requisitions.

Receipts and bills

Reconciliation is a separate duty from purchasing. The Idaho State Controller lists periodic review and reconciliation of assets to recorded amounts as its own function ^[23], and GAO lists control over complete, accurate and timely recording of valid transactions as a category of control activity ^[5].

Downstream records complete the chain. An item receipt carries a Created From reference to the PO number ^[26], and Oracle's PO History report compares authorized, received and billed amounts, flagging an unbalanced Receipt Minus Bill Amount. Match Bill to Receipt can be set per PO line. The 3 Way Match workflow validates a bill against the corresponding PO and item receipt, but it documents that partially received item receipts are not supported, and tolerance limits are absolute difference or percentage values. University policy models the same idea: Rockefeller University states that agreement among PO, receiving report and invoice is a prerequisite to payment ^[6], and the University of Georgia uses a two-way match only below a stated dollar value ^[27] with Accounts Payable performing the match ^[27].

Table 3 below shows a reconciliation record for the multi-department scenario described in the next section. All identifiers and quantities are illustrative (Hypothetical Example).

In this illustration the buyer ordered 20 units on one PO, three lines each referencing a requisition, and the vendor delivered 18 across two receipts. The reconciliation test is arithmetic: requested quantity equals ordered quantity, received equals billed on matched lines, and open quantity ties to the PO's Partially Received state, which Oracle associates with a partial receipt. Because the line carries the requisition number and the department, each department's receipt can be traced without relying on the PO header, which does not carry the memo in consolidated cases.

Worked Scenarios (Hypothetical Examples)

Both scenarios below are hypothetical and labeled accordingly. They use no real company data.

Several departments request the same item (Hypothetical Example)

Three departments, Sales, Support and Finance, each need the same monitor model within the same quarter. None of the requesters knows the negotiated price. Under the policy, each enters a requisition with item, quantity, department and an estimated amount, because the estimated rate or amount is required for approval. Each requisition routes to its own department approver, and each moves to Pending Order after approval.

The buyer opens Order Requisitions, filters by item, and sees three lines. After confirming the vendor and rate for each line, the buyer consolidates them onto one PO so the vendor's volume pricing can apply, which is the use case Oracle describes. The PO lines retain the three requisition numbers. If a PO line is deleted in error, the requisition line reappears on Order Requisitions, which makes accidental deletions visible to the buyer.

Known-vendor one-off purchase (Hypothetical Example)

A department head needs a one-year subscription from a vendor already used by the company, at a quoted price, and nobody else is buying it. The head enters a purchase request in the Employee Center, naming the vendor. The request routes to the supervisor, or up the chain if the amount exceeds the supervisor's limit, and becomes a PO on approval. There is no consolidation, no vendor choice and no buyer sourcing step. The reconciliation is one request to one PO to one receipt or bill.

The contrast is deliberate. The same company uses a requisition for common goods and a purchase request for single-vendor items, and Oracle confirms that both features can run together. The risk is user confusion in the Employee Center, where Sikich says a Purchase portlet links to both Requests and Requisitions ^[14] and Concentrus notes that the two are easy to mix up ^[12].

Exceptions, Audit Trail and Acceptance Tests

Exception handling

Exceptions are where the design is tested. Each rule below is written so that it can be placed directly in the policy.

• Missing vendor: a requisition without a vendor cannot be ordered, since a vendor must be indicated to order a line. The buyer assigns the vendor, or returns the requisition to the requester for clarification.
• Changed amount: if the final price differs from the estimate, the policy should require re-approval when the variance exceeds a controller-set tolerance. Lehigh University applies a per-line price tolerance on estimated-price POs, and beyond it the buyer completes an additional task ^[19]. The percentage is institution-specific and is not a recommendation.
• Split PO: a single requisition may produce several POs, so the audit test sums PO lines by requisition and compares to requested quantity.
• Rejected request: a rejected requisition may be editable and resubmittable through approval again; confirm in your account whether it can be resubmitted and whether rejection notes are captured, because the reviewed sources do not settle either point.
• Duplicate demand: two employees requesting the same item is not an error in the requisition model, because consolidation is the point ^[16]. On the purchase request path it is a duplicate, so the buyer's weekly review should check open requests by vendor.
• After-the-fact purchases: Montclair State University prohibits confirming orders placed before a PO exists ^[10], and Lehigh defines a retrofit PO as one created after the invoice has arrived ^[19]. The policy should state that retrofit POs are exceptions reported to the controller.

Acceptance tests

Run each test in sandbox before go-live, and record the result against the policy version.

1. Multi-vendor: enter one requisition with three items for three vendors, order it, and verify three POs, each line carrying the requisition number.
2. Consolidation: enter three requisitions for one item from different departments, consolidate onto one PO, and verify each PO line retains its requisition number and department.
3. Budget rejection: because the reviewed Oracle pages do not describe requisition budget checks, test that a rejection by the budget owner sets the approval status to rejected and blocks ordering.
4. Multi-subsidiary: enter requisitions in two subsidiaries and verify that each carries one subsidiary and that the Order Requisitions list can be filtered by subsidiary.
5. Header attachment: consolidate two requisitions with attachments and verify the policy's manual re-attachment step, since attachments do not copy.
6. Auto-approval gap: create an employee with a blank approver and verify the control that blocks it, because the workflow can auto-approve.
7. Partial receipt: receive part of a consolidated PO and verify the item receipt references the PO.
8. Edit after order: attempt to delete an ordered requisition line and verify that the linked PO line must be deleted first.

Data Analysis and Evidence

Public quantitative evidence on requisition design is thin, and the figures below should be read as context, not as targets. No vetted public benchmark for cycle time or cost per PO was found from an originating body, so none is reported.

Configuration facts that carry numbers

Oracle's documentation supplies the hard numbers that shape the design. The consolidation setting defaults to 10 lines and can be raised to 250. The Advanced Procurement SuiteApp is bundle ID 57060. Only one subsidiary may be tied to a requisition. The 2015 Oracle datasheet for Advanced Procurement already positioned the employee requisition form as a way to submit requests without knowing vendor names ^[28], so the capability is long established even if the licensing description evolves.

Process benchmarks from independent bodies

Published figures help calibrate expectations, each with its stated origin. IOFM, an accounts payable research and training body, reports a two-year study of 388 AP functions ^[29], and it found that 40% of those functions start the on-time clock only when AP receives the final invoice ^[29], which hides approval and routing delays that happen before AP sees the document. That finding supports measuring from the requisition date, not the invoice date.

Ardent Partners reports, on its CPO Rising publication site, that on average only 65.1% of spend and 76% of transactions are compliant with contracts ^[30], that each non-compliant dollar of spend costs an extra 12% to 18% ^[30], and that its best-in-class group placed on average 89.8% of spend under procurement management ^[30]. The page does not state a sample size and the study dates from 2021, so the figures are directional. They illustrate why intake discipline matters, but they are not evidence that any NetSuite transaction choice produces a given saving. This report does not claim one.

Practitioner positions

Partner guidance converges on several points and diverges on others. Sikich, Anchor Group and BrokenRubik agree that same-vendor requisitions can be consolidated ^[16], and Epiq says demand consolidation aggregates lines onto fewer, larger POs ^[15]. Anchor Group says traceability from requisition to PO line is maintained after consolidation (Source: www.anchorgroup.tech), consistent with Oracle's cross-reference. Divergence appears in the licensing description, covered earlier, and in automation: Six Lakes describes a custom build in which approved purchase requests convert to POs automatically ^[31], and Zone and Co says approval customization is limited out of the box ^[20]. Both are vendor-authored and should be tested against the account.

Implications and Future Directions

For finance leaders, the central implication is that the transaction choice is a control design, not a data-entry preference. A requisition creates an approval checkpoint before any commitment, and Hyperbots notes that such a record does not create accounting entries by itself ^[32] while serving as an early control point in the procure-to-pay cycle ^[32]. The PO is where commitment accounting begins. The policy should say so in plain language so that employees do not treat an approved requisition as permission to buy from a vendor.

For implementation leads, three practices reduce rework. Start with the minimum effective approval structure, as Anchor Group advises (Source: www.anchorgroup.tech), because approval dimensions multiply quickly (Source: www.anchorgroup.tech). Treat Advanced Procurement as a licensing decision first, noting Anchor Group's view that a small centralized buying team with direct PO authority may find standard procurement sufficient (Source: www.anchorgroup.tech). And use the dashboard reminder for approved requisitions without a PO as the buyer's work queue.

Integration teams should note that requisitions are accessible by API. Integration teams should confirm in the SuiteTalk documentation for their account version whether the SOAP initialize operation can transform a requisition record into a PO record; if it can, any scripted conversion should preserve line references. Control frameworks are also stable: COSO's Integrated Framework was issued in 1992 and refreshed in 2013 ^[33], so the underlying duties do not change when NetSuite releases do. Because documentation and releases change, re-running the acceptance tests against each release is advisable. The checklist in this report is designed to be used by any implementation partner or an internal team.

Frequently Asked Questions (FAQs)

What is the difference between a NetSuite purchase request and a purchase requisition?

A purchase request names one vendor and becomes one PO, while a requisition may omit vendor and price and can be split or consolidated.

Does NetSuite require Advanced Procurement for requisitions?

Oracle's SuiteProcurement and approval pages say Advanced Procurement must be provisioned to use the Requisitions feature. Other Oracle pages do not mention it, so verify in your account.

What is the difference between a purchase requisition and a purchase order in NetSuite?

The requisition is the internal ask and approval record, while the PO is the document that commits spend with the vendor ^[20].

How does a requisition approval workflow work?

Approval commonly follows a tiered pattern, with the amounts set by policy: Epiq describes auto-approval under a set amount, manager approval in a mid band, and executive approval above a ceiling ^[15]. Requisition approval in NetSuite needs a SuiteFlow workflow, and employee purchase limits and approvers drive the routing.

How does a requisition become a purchase order?

After approval, a buyer orders from the Order Requisitions page, confirming vendor and rate per line. A purchase request becomes a PO after approval.

Can several requisitions become one PO?

Yes. Oracle documents consolidation of requests for the same item onto one PO, and partners confirm that same-vendor requisitions can be combined ^[16].

Can one requisition create several POs?

Yes. A single requisition can create one or more POs from one or more vendors.

How should an employee purchase request form be set up?

Give employees the Employee Center role, enable Purchase Requests, and set purchase limits and approvers on employee records.

What changes in OneWorld?

A requisition has one subsidiary, and role-based item and location restrictions apply after the subsidiary is chosen.

Does a requisition create a financial commitment?

Generally no, in standard accounting terms; verify in your own account, because Oracle's reviewed pages do not describe requisition budget checks. Treat the PO as the commitment document, because Lehigh encumbers budget at PO creation rather than at requisition ^[19], and Hyperbots notes that requisitions do not create accounting entries by themselves ^[32].

Conclusion

The choice between a NetSuite purchase request and a requisition is a choice about who supplies vendor and price, who consolidates demand, and when a buyer takes over. Purchase requests suit a requester who knows one vendor and a price, and they map one request to one PO. Requisitions suit incomplete information, multi-vendor needs and cross-employee consolidation, and they depend on an Advanced Procurement entitlement that the account must be checked for. A direct PO belongs with buyer-originated commitments.

The signed intake policy should record the decision tree, the matrix, the RACI, the line-level reconciliation, and the acceptance tests, with the procurement manager, controller and implementation lead signing the same document. Thresholds, tolerances and approval bands stay with the controller, and they should be written into the policy only after being tested in the company's own account. Reverification at each NetSuite release keeps the design aligned with Oracle's current behavior.