NetSuite P2P Practice Scenarios for New Functional Consultants
A procure-to-pay process rarely fails because someone forgot that a purchase order comes before a vendor bill. The real friction appears in the exceptions: a receipt is partial, a bill exceeds the approved amount, a vendor needs a tax form, or an invoice arrives before the warehouse records delivery. These are the situations new functional consultants must learn to analyze and configure in NetSuite.
NetSuite P2P practice scenarios help new functional consultants connect business requirements to records, statuses, approvals, permissions, workflows, and accounting impact. A useful scenario should not stop at “create a purchase order.” It should ask what happens when the process deviates from the expected path, who owns the next action, and how NetSuite should prevent or record the exception.
NetSuite P2P is the complete procure-to-pay cycle from purchasing demand through supplier payment. In NetSuite, a typical flow starts with a purchase requisition or purchase order, continues through item receipt and vendor bill creation, and ends with bill approval, payment, and updates to accounts payable, inventory, expenses, and the general ledger. A functional consultant uses practice scenarios to validate roles, approval routing, three-way matching, transaction statuses, accounting behavior, reporting, and controls across that flow.
The goal is not to memorize screens. It is to understand the business process well enough to ask precise questions and recommend a design that works in daily operations.
What Does NetSuite P2P Include?
NetSuite P2P includes the connected activities used to request, authorize, order, receive, invoice, and pay for goods or services. The exact transaction flow depends on the company’s purchasing model, whether it buys inventory, services, fixed assets, or operating expenses.
A basic inventory purchasing process may include these records:
Purchase requisition, if the organization requires an internal request before purchasing
Purchase order, which communicates the approved order to the vendor
Item receipt, which records what the company physically received
Vendor bill, which records the supplier’s payable
Vendor payment, which settles the approved liability
A service procurement process may use an expense purchase order, receipt confirmation, and vendor bill without an item receipt. That distinction matters. A consultant should not design every P2P process as if the company receives stock into a warehouse.
The following table summarizes the main records and the questions a new consultant should ask.
| P2P stage | Common NetSuite record or action | Main accounting or operational effect | Questions to validate |
|---|---|---|---|
| Demand | Purchase requisition or internal request | Establishes purchasing need without creating an accounts payable liability | Who can request, and what information is mandatory? |
| Approval | Requisition or purchase order approval | Controls authorization before the company commits to spend | Are limits based on amount, department, subsidiary, class, or location? |
| Ordering | Purchase order | Communicates quantity, price, vendor, terms, and expected delivery | Can buyers edit approved orders, and which changes require reapproval? |
| Receiving | Item receipt or service confirmation | Updates inventory or confirms delivery of a service | Can the company receive partially, and who confirms service completion? |
| Invoicing | Vendor bill | Creates the accounts payable liability and expense or inventory impact | Does the bill require a purchase order and receipt match? |
| Settlement | Vendor payment | Reduces accounts payable and cash or the payment account | Who can approve, prepare, and release payment? |
| Review | Saved searches, reports, and dashboards | Shows open commitments, received-not-billed items, and overdue bills | Which exceptions require daily monitoring? |
NetSuite’s standard transaction relationships provide the foundation, but configuration determines how users move between them. A consultant needs to understand both.
How Should a New Consultant Analyze a P2P Scenario?
Start with the business event, not the NetSuite menu. Ask what happened, who acted, what information was known at that point, and what the organization needs to control.
For example, “a department needs laptops” is not yet a complete requirement. A useful analysis asks whether laptops are inventory, fixed assets, or ordinary expenses; whether the purchase requires one or more approvals; whether the vendor is already approved; whether delivery occurs at one location or several; and whether the invoice must match the purchase order and receipt.
A strong scenario analysis normally covers five dimensions:
Process: What is the expected sequence from request to payment?
Ownership: Which role performs each action?
Data: Which fields, classifications, attachments, and references are required?
Control: What prevents unauthorized purchasing, duplicate billing, or payment before approval?
Accounting: Which account, subsidiary, department, location, tax treatment, and period are affected?
This approach also separates configuration requirements from training questions. If a buyer cannot find a vendor, the problem might be permissions, vendor status, subsidiary access, or incomplete master data. It is not automatically a training issue.
New consultants should document assumptions explicitly. “All purchases require a purchase order” is a meaningful design assumption. “All receipts happen before bills” is not safe unless the business confirms it, because service vendors and recurring charges frequently follow a different pattern.
Scenario 1: A Department Submits a Purchase Request
A department manager needs new equipment but does not have authority to place an order directly with a vendor. The organization wants the request reviewed by a budget owner before procurement creates a purchase order.
The consultant should determine whether the business needs a formal purchase requisition or whether users create purchase orders directly. A requisition is useful when requesters and buyers are different people, when the company needs budget review before vendor contact, or when purchasing consolidates demand across departments.
Important design questions include:
Which employees can submit requests?
Which fields are mandatory, such as department, location, item, quantity, needed-by date, and justification?
Does approval depend on the total request amount or the individual line amount?
What happens when a requester changes the quantity or vendor after approval?
Can procurement reject a request, return it for correction, or split it into several purchase orders?
A common mistake is to build an approval workflow around the requester’s department and ignore the subsidiary or location on the transaction. In a multi-subsidiary account, the approval hierarchy must reflect the correct legal entity and purchasing authority.
The consultant should also consider duplicate requests. A saved search that displays open requisitions by item, requester, and needed-by date can help procurement identify consolidation opportunities before issuing separate orders.
Scenario 2: A Purchase Order Requires Tiered Approval
A buyer creates a purchase order for services above the department manager’s approval limit. The transaction must route to a senior approver, while lower-value orders should move through a simpler path.
Tiered approval is one of the most common NetSuite P2P requirements, but amount alone is rarely enough. Approval rules may also depend on subsidiary, department, location, vendor category, expense account, project, or whether the purchase is capital expenditure.
The consultant should define the approval state clearly. For example, the purchase order might move from Pending Approval to Approved, Rejected, or Closed. The design should state whether an approver can edit the transaction, whether edits restart approval, and whether buyers can print or send an unapproved order.
A practical test should include boundary values. If the approval threshold is $10,000, test $9,999, $10,000, and $10,001. Also test a change from $9,000 to $11,000 after approval. Many defects appear because the workflow handles initial creation but not later edits.
Role permissions matter here. A user who can create a purchase order should not automatically have authority to approve it. Separation of duties should prevent the same person from requesting, approving, receiving, entering the bill, and releasing payment without a documented exception.
If your team needs help translating approval requirements into a broader NetSuite design, our NetSuite consulting and implementation resource explains how discovery, solution design, configuration, testing, and training fit together.
Scenario 3: The Vendor Ships Only Part of the Order
A purchase order contains 100 units, but the vendor ships 60. The warehouse receives the shipment, and the remaining 40 units are expected later.
This scenario tests whether the consultant understands partial receiving and open commitments. The receiver should record the quantity actually received, not close the purchase order simply because one shipment arrived. NetSuite must preserve the outstanding quantity so purchasing can track the balance.
The consultant should test:
Whether the item receipt records 60 units without forcing receipt of all 100
Whether the purchase order remains open for the remaining quantity
Whether the vendor bill covers the received quantity, the ordered quantity, or a separately defined service amount
Whether the warehouse can receive another shipment against the same purchase order
Whether dashboards or saved searches identify overdue open quantities
For serialized or lot-numbered items, the scenario must also include inventory detail. The receiver may need to enter serial numbers, lot numbers, expiration dates, or bin information. A generic “quantity received” test is not sufficient for controlled inventory.
The consultant should ask how backorders are handled. Some businesses keep the original line open. Others cancel the remaining quantity and create a new purchase order if the vendor changes the delivery date or price. That is a process decision, not simply a system setting.
Scenario 4: The Vendor Bill Fails Three-Way Matching
The vendor sends a bill for 100 units even though only 60 units have been received. The purchase order shows the correct quantity and price, but the bill does not match the receipt.
Three-way matching compares the purchase order, the receipt, and the vendor bill. It is a core P2P control because it checks what the company ordered, what it received, and what the vendor charged. The exact tolerance rules must be defined by the business.
A consultant should test quantity and price variances separately. A bill might match the received quantity but exceed the approved unit price. It might also match the price but bill for more units than the receipt supports. These exceptions should not be treated as identical because different people may resolve them.
Useful questions include:
Should NetSuite block the bill, route it for exception approval, or allow posting with a warning?
What quantity variance is acceptable?
What dollar or percentage price variance is acceptable?
Who can override a mismatch?
Does an approved variance require a note or attachment?
How are recurring service bills handled when there is no item receipt?
The consultant should also examine duplicate invoice controls. A vendor invoice number should be captured consistently, and the business should decide whether duplicate numbers are blocked across a vendor, subsidiary, or the full account. Duplicate prevention is a practical control that generic process diagrams frequently omit.
Scenario 5: A Service Bill Arrives Without an Item Receipt
A vendor provides monthly legal, consulting, software, or maintenance services. The vendor submits a bill, but there is no physical inventory to receive.
This scenario separates goods procurement from services procurement. Requiring an item receipt for every vendor bill creates unnecessary work and can prevent legitimate invoices from moving through accounts payable.
The better design depends on the service control. The company might require a purchase order and approval from the service owner. It might also require a project manager to confirm hours, milestones, or deliverables before the bill is approved. For recurring services, the control may be a contract amount and a monthly approval rather than a warehouse receipt.
The consultant should identify the correct expense account and classifications. A service bill could affect professional fees, software subscriptions, rent, utilities, project costs, or prepaid expenses. It may also need a project, customer, department, or location for reporting.
Testing should include a bill that exceeds the monthly expected amount, a bill for a canceled service, and a bill that covers multiple departments. These cases reveal whether the approval design supports real operational complexity.
NetSuite accounting configuration becomes especially important when P2P includes prepaid expenses, allocations, or period-specific recognition. Functional consultants should trace the bill from entry through posting, not stop after confirming that the transaction saved successfully.
Scenario 6: A Purchase Order Is Changed After Approval
A buyer changes the vendor, quantity, price, or delivery location after a purchase order has been approved. The business wants material changes to return the order to approval, while minor updates should not create unnecessary delays.
This scenario tests change control. The consultant must define which fields are approval-sensitive. Changing a memo should not necessarily restart the workflow. Changing the total amount, vendor, subsidiary, expense account, or item may require a new approval.
A useful test matrix looks like this:
| Change after approval | Likely control question | Test result to confirm |
|---|---|---|
| Quantity increases | Does the total exceed the current approval limit? | Approval restarts when the change increases risk |
| Unit price changes | Is the new price within tolerance? | Price variance is identified and routed correctly |
| Vendor changes | Is the new vendor approved and authorized? | Vendor and approval controls are reevaluated |
| Department changes | Does the new owner have budget authority? | Approval follows the responsible department |
| Delivery location changes | Does inventory or tax treatment change? | Location remains valid for the subsidiary |
| Memo changes | Is the change informational only? | Workflow does not restart unnecessarily |
The process should also define whether the original approval history remains visible. Auditability matters. A reviewer should be able to see who approved the first version and who approved the later material change.
Scenario 7: The Bill Is Approved but Payment Must Wait
Accounts payable approves a vendor bill, but the payment date depends on payment terms, cash planning, a hold, or a separate release approval.
This scenario shows that bill approval and payment approval are different controls. A bill can be valid and payable while still being held from payment because the vendor account is under review, the due date has not arrived, or the business requires a payment batch approval.
The consultant should map the full payment lifecycle. Identify who enters or imports the bill, who approves it, who prepares payments, who releases payments, and who reconciles the resulting bank activity. The same user should not control every step without a documented business reason.
Test cases should include an invoice on hold, a bill with early-payment terms, a partial payment, and a payment covering several bills. Confirm how credits, discounts, and unapplied amounts are handled. If electronic payments or bank files are involved, include file generation, approval, transmission, and return handling in the test plan.
A P2P process is not complete when a payment record exists. The consultant must confirm the accounts payable balance, vendor balance, payment account, payment date, and reporting period.
Common P2P Issues New Consultants Miss
New functional consultants tend to focus on the happy path. Production problems usually come from the exceptions around master data, permissions, and timing.
Several issues deserve deliberate testing:
Inactive or restricted vendors: A vendor can exist in the system but still be unavailable to a user, subsidiary, or transaction type.
Accounting periods: A receipt or bill entered in a closed period may require a controlled process for correction.
Tax and withholding: US sales tax, use tax, and vendor reporting requirements should be evaluated with the organization’s tax advisors. Other countries may add VAT or goods and services tax requirements, so the same P2P design should not be copied across jurisdictions without review.
Currency and exchange rates: Foreign-currency purchase orders and bills require clear rules for rate sources, revaluation, and realized or unrealized gains and losses.
Units of measure: Ordering by case and receiving by each creates quantity and conversion questions that should be tested before go-live.
Attachments and audit evidence: Vendor quotes, approvals, receipts, and correspondence may need to remain attached to the transaction for review.
Saved searches are particularly useful for exception management. Examples include purchase orders pending approval, bills without purchase orders, received-not-billed items, orders past the expected receipt date, and bills with quantity or price variances.
How Do You Turn a Scenario Into a NetSuite Test Case?
A scenario becomes a reliable test case when it has defined data, a user role, a sequence of actions, and an expected result. “Test vendor bill approval” is too vague to produce useful evidence.
A practical test case should identify the subsidiary, vendor, item or expense, amount, department, location, approval limit, and transaction date. It should state the role used for each action and specify what must happen after each step.
For example, a partial-receipt test might define a purchase order for 100 units, an item receipt for 60, and a vendor bill for 100. The expected result could be that the bill is held or routed for exception review, the purchase order remains open for 40 units, and no payment is released until the mismatch is resolved.
Use positive, negative, and boundary tests. Positive tests confirm that valid transactions move through the intended workflow. Negative tests confirm that unauthorized or incomplete transactions are stopped. Boundary tests confirm what happens exactly at approval limits, tolerance thresholds, period boundaries, and quantity limits.
Testing should also cover data visibility. A transaction can be correctly configured yet unusable if the buyer cannot see the vendor, the approver lacks subsidiary access, or accounts payable cannot view the receipt required for matching.
Versich’s NetSuite consultant services are relevant when an internal team needs support turning process requirements into roles, workflows, reports, and testable configurations. The important consulting discipline is the same: define the business rule first, then validate how NetSuite enforces it.
A Practical Learning Path for New Functional Consultants
New consultants build confidence faster by learning P2P in layers rather than trying to master every feature at once.
Begin with the standard transaction flow and accounting impact. Then add approvals, receiving exceptions, matching, permissions, reporting, and cross-subsidiary considerations. Use a sandbox to test realistic transactions, but keep test data clearly separated from production data and document any required refresh or cleanup work.
A useful practice routine includes:
Draw the process from purchase request through payment.
Map each step to a NetSuite record, status, role, and accounting effect.
Write one happy-path scenario and at least three exception scenarios.
Test quantity, price, approval, vendor, currency, and period changes.
Record the expected result before executing the test.
Convert unresolved questions into business decisions, not configuration guesses.
Reviewing NetSuite’s connected procure-to-pay workflow alongside broader ERP processes can also help new consultants see how purchasing affects inventory, financial reporting, and operational dashboards. Our guide to how NetSuite works across business processes provides useful context for that wider view.
Make Each Scenario Prove the Design
The strongest P2P practice scenario does more than demonstrate that a transaction can be entered. It proves that the right person can enter it, the right approver reviews it, the accounting impact is correct, and an exception receives a clear next action.
New functional consultants should use scenarios as decision tools. Start with the business event, identify the control, map the NetSuite records, test the normal and abnormal paths, and document the result. That method creates better requirements and reduces the risk of confusing a technically successful transaction with a workable procure-to-pay process.
If you are building a training plan, reviewing an existing workflow, or preparing a broader NetSuite project, contact our team to discuss the process and the next practical step.
