Lesson 6 of 6
Testing service-to-cash
10 min
Listen to this lesson
Service-to-cash crosses more boundaries than most order-to-cash flows: customer service, technicians, warehouse, asset management, billing and finance. A CS-to-Service move changes every document on the way. The test strategy must prove that each variant works end to end, that the money is right, that history and contracts survived the move, and that people can work with the new apps on day one.
The scenario map
| Scenario | Variants | Exceptions to include |
|---|---|---|
| Field repair | Time and material; fixed price; warranty (not billable) | Unplanned part added in confirmation; cancelled confirmation |
| Service request to order | Request copied to quotation, then order; request copied to order directly | Rejected quotation |
| Contract coverage | Order under contract; order without contract | Expired contract; object not covered |
| Contract billing | Quarterly fee; mid-period change; termination | Renewal with new prices |
| In-house service | Repair and return; scrap and return | Warranty repair |
| Advanced execution | Itemized and summarized DIP billing; fixed price | Distributed execution across two maintenance orders |
Contoso's service-to-cash scenario map.
Checkpoints along the chain
| Checkpoint | Expected result (field repair example) | Where to check |
|---|---|---|
| Order pricing | Contract labor rate 95.00 USD per hour, parts at contract prices | Service order item pricing |
| Confirmation | 3.5 h labor, one rotor kit, travel 60.00 USD | Service confirmation items |
| Goods movement | Rotor kit issued from the right plant and storage location | Material document |
| Billing request | Three billable lines matching the confirmation | BDR in the billing due list |
| Invoice | Totals match contract terms; tax as configured | Billing document and accounting document |
| Cost and margin | Actual costs and revenue on the service items | Item cost report; margin analysis |
Checkpoints for a time-and-material field repair (illustrative values).
Data and history
Before any process test, the master data and migrated objects must be right: business partners with the depot ship-tos, equipment with serial numbers and installation locations, service products and prices, and the migrated contracts. Then answer the history question with the business: when a technician repairs a unit, can they see its CS service orders from the last five years? Options include read access to the old documents while use rights allow, reports or an archive, or a data extract into a reporting layer. Whatever the choice, test that technicians and warranty staff can find history the way they will need it.
Negative and role-based cases
| Case | Expected result |
|---|---|
| Confirm an item that is not released | Refused with a clear message |
| Bill a confirmation twice | Second BDR not created; no duplicate invoice |
| Technician tries to change contract prices | No authorization; prices unchanged |
| Order for a customer with a billing block | BDR blocked until the block is released |
| Cancel a completed confirmation | Behavior as designed: reversal of postings or refusal |
| Service request for an object without equipment record | Handled as designed; no silent loss of history |
Negative and authorization cases that belong in the service-to-cash regression set.
Keep the final set small enough to run in Contoso's release regression window in CMR. About 40 cases cover the scenario map, the checkpoints and the negatives above; the rest belongs to project testing. Each case needs its expected financial result written down before it runs, because "the invoice looks plausible" is not a test result.
Coexistence during the move
For a period, CS and SAP S/4HANA Service may run side by side: open CS orders finish in CS while new work starts in Service. Decide the rule (for example, "every order created after the cutover date is a service order; open CS orders finish in CS within 60 days") and test both paths in the same cycle, including billing and reporting that must combine CS and Service revenue for the same customer. Regression tests for the rest of order-to-cash must run too, because billing and accounting are shared.
What goes wrong in testing
- Only the happy field repair tested. Contracts, warranty and advanced execution carry most of the money and most of the defects.
- Finance checked at the end. Item-based accounting changes margin reports; Dan must see them in cycle 1, not in acceptance.
- Technicians not involved. Confirmation screens and mobile use decide adoption; include technicians in acceptance.
- Billing handover not rehearsed. Double or missed contract billing at go-live is visible to every customer.
What would you do?
Two weeks before go-live, all scenarios pass except contract billing for terminated contracts, which still creates one extra BDR after the end date. The service manager wants to go live and "fix it later." What should Priya recommend?
- Map scenarios by variant and exception: field repair, request, contract, billing, in-house, advanced execution.
- Check each step of the chain: order, confirmation, goods movement, BDR or debit memo request, invoice, margin.
- Test data and history access before process tests; reconcile migrated contracts.
- Rehearse coexistence and the billing handover; run order-to-cash regression in parallel.
Check your understanding · not graded
Lesson check
1. Why must Dan review margin results in the first integration cycle?
2. Which checkpoint proves that a service part left stock correctly?
3. What must coexistence testing include?
4. A known billing defect remains before go-live. What makes accepting it defensible?