Lesson 2 of 5
Defining expected results across procurement and finance
12 min
"Invoice posted successfully" is not an expected result. It tells the tester nothing about whether the invoice should have been blocked, which accounts it should hit, or when it should be paid. An expected result is a set of specific, checkable facts written before execution: statuses, quantities, values, postings and documents. In P2P those facts span two worlds, procurement and finance, and a test that checks only one of them is half a test.
Expected results for every step
Take P2P-02: Contoso orders 1,000 rotors CMC-RTR-200 from Lakeside Components at $42 for plant 1710, storage location 171A. The standard price is $40, the PO is above the $25,000 approval threshold, and Lakeside's invoice arrives at the PO price. Before anyone runs the test, Priya's team writes the expected results:
| Step | Status expected | Quantity and value | Postings expected | Evidence |
|---|---|---|---|---|
| Purchase requisition | Created, released (it is over $10,000), then converted to PO | 1,000, valuation price $42 | None | Requisition number and its follow-on PO |
| Purchase order | In approval, then approved; output sent only after approval | 1,000 × $42 = $42,000 | None | Approval history; output log |
| Goods receipt (101) | PO item delivered | Stock in 171A +1,000 | Inventory $40,000 Dr, price difference $2,000 Dr, GR/IR $42,000 Cr | Material document, journal entry, stock before/after |
| Supplier invoice | Posted, not blocked | Invoice 1,000 × $42 = $42,000 | GR/IR $42,000 Dr, Lakeside $42,000 Cr | Invoice document, journal entry, due date from payment terms |
| Payment | Item cleared | $42,000 paid on or after the due date | Lakeside $42,000 Dr, bank clearing $42,000 Cr | Payment document, payment proposal list |
Expected results for P2P-02, written before execution.
- PO approvedNo posting; approval history and supplier output are the evidence
- Goods receiptInventory and price difference debit, GR/IR credit
- InvoiceGR/IR debit, supplier credit; GR/IR for the item is zero
- PaymentSupplier debit, bank clearing credit; supplier item cleared
- ReconciliationGR/IR zero for the item, supplier balance zero, stock value +$40,000
Approvals
Approval behavior must be expected explicitly. With flexible workflow for purchase orders, set up in the Manage Workflows for Purchase Orders app, the start conditions decide whether a PO needs approval and who approves: conditions such as total net amount, purchasing group, document type or material group, with one or more approval steps. The expected result names the approver, says the PO cannot be output before approval, and says what happens on rejection. Many on-premise and Private Edition systems still use classic release strategies; then the expected result names the release code and release indicator instead.
Invoice blocks
Invoice verification compares the invoice with the PO and goods receipt using tolerance limits per company code. When a variance exceeds tolerance, the invoice can still be posted but is blocked for payment. The expected result for a blocking test states which tolerance is exceeded (price variance, quantity variance), that the invoice posts with a payment block, that the payment run does not pay it, and that it can be released in Release Blocked Invoices (MRBR) after the variance is resolved.
| Situation | Expected invoice status | Expected payment run behavior | Expected follow-up |
|---|---|---|---|
| Price and quantity within tolerance | Posted, free for payment | Paid when due | None |
| Price above tolerance (for example $43 against $42 with a tight price tolerance) | Posted, blocked for payment | Not paid; listed as blocked | Purchasing confirms price; AP releases |
| Invoiced quantity above received quantity | Posted, blocked for payment | Not paid | Wait for receipt or request credit memo; then release |
| Invoice amount below PO | Posted, usually free (small differences may be accepted) | Paid when due | Depends on tolerance settings; confirm with Dan |
Cross-functional expected results
- Procurement: document statuses, PO history, approval history, output sent, open quantities.
- Inventory: stock change by storage location and stock type.
- Finance: journal entry accounts and amounts, GR/IR balance per PO item, supplier open items, due dates and payment blocks.
- Supplier-facing: what Lakeside receives: PO output, return delivery note, payment advice.
What would you do?
A test case for P2P-04 says: "Expected: invoice is posted." The invoice is $43 per rotor against a PO price of $42 and Contoso's price tolerance would be exceeded. How should the expected result be written?
Variants need their own expected results
Each variant changes at least one expected fact, so do not copy the stock PO expectations blindly. For P2P-06, an account-assigned PO for 10 test-bench rotors charged to the engineering cost center, the valuated receipt debits the consumption account on the cost center instead of inventory, and stock does not change. For P2P-07, a service PO, there is no goods receipt in the material sense: the approved service entry sheet takes its place, and the invoice is matched against it. For P2P-08, the return, the expected results include a stock decrease, a credit memo that reduces the amount owed to Lakeside and a GR/IR item that is consistent again after the credit memo. Writing these differences down is where testers often discover that nobody had agreed what the right outcome is, which is a design question to settle before execution, not during it.
Public Edition note: in SAP S/4HANA Cloud Public Edition the scope item test scripts and the flexible workflow approach are the default, and tolerance settings are maintained through the configuration options SAP exposes. The way you write expected results is the same.
- Write expected results before execution: statuses, quantities, values, postings, evidence.
- Name the approver and rejection behavior for approval tests.
- For variance tests, expect the block, the payment run exclusion and the release.
- Every P2P test checks procurement and finance outcomes together.
Check your understanding · not graded
Lesson check
1. Which expected result is strongest for a goods receipt test?
2. An invoice exceeds the price tolerance. What should the expected result say?
3. Where are flexible workflow conditions for PO approval maintained?
4. Why compute expected amounts before execution?