Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 3 of 5

Running order to cash end to end

12 min

End-to-end execution means one scenario runs from the first step to the last with the same data and the same document chain: customer and product master data, order, delivery, goods issue, invoice, output, and the customer's payment. Breaking the chain into separate unit tests, each with fresh data, proves each step but not the hand-offs between them, which is where most order-to-cash defects live.

  1. Master data checkBusiness partner with customer roles for sales area 1710 / 10 / 00; product extended to plant 1710
  2. Sales orderPrice, availability and credit check; record the order number
  3. Delivery and goods issuePicking from 171A and goods issue; record the delivery and material document
  4. Billing and outputInvoice posted to accounting; output sent; record the billing and journal entry numbers
  5. Incoming paymentPayment posted and the invoice cleared; record the clearing document
  6. Evidence packDocument flow, journal entries and customer line items attached to the test run
A single end-to-end order-to-cash run with evidence at every step.
The Sign-Off Table · thesignofftable.com/academy/sap-sd-303

Including the credit check

Credit management is where sales meets finance risk. A complete O2C test set includes at least one order that exceeds the customer's credit limit, is blocked, and is then released by an authorized credit controller, and one that is rejected. In SAP GUI, blocked documents appear in VKM1; in Fiori, in the credit management and fulfillment issue apps. The expected result for the blocked order is that no delivery can be created until release.

Including returns and outputs

Returns run end to end too: original invoice, return order, returns delivery, goods receipt, credit, and the credit applied against the customer's account (SD 208 covers the details). Outputs need the same discipline: for each output in the coverage matrix, check that it was sent, to the right recipient, through the right channel, with the right content. A correct invoice sent to the wrong customer contact is a customer-facing defect and a data protection issue.

Closing the loop: cash application

The process ends when the customer pays. Post the incoming payment the way Contoso will in production: through the bank statement or lockbox process if that is how payments arrive, or manually (for example with F-28 in SAP GUI or the incoming payment apps in Fiori) if that is the real process. Then check the customer's line items (FBL5N or Manage Customer Line Items): the invoice should be cleared, and any difference (short payment, discount taken) handled as the process says.

  1. Day 1Order and creditO2C-01 and O2C-04 (credit block) entered; O2C-04 blocked as expected
  2. Day 1Credit releaseCredit controller releases O2C-04; the order can now be delivered
  3. Day 2ShippingDeliveries and goods issue for all orders; material documents checked
  4. Day 3Billing and outputInvoices posted; email outputs checked in the output status
  5. Day 5CashBank statement with test payments imported; invoices cleared
  6. Day 6Evidence reviewMaria and Dan review flows, journal entries and line items
A one-week end-to-end execution window for Contoso's O2C cycle.
The Sign-Off Table · thesignofftable.com/academy/sap-sd-303
Run onceFew hand-offs, low revenue: a single execution per cycle
Integration focusMany hand-offs, low revenue: run to prove the seams even if volume is small
Core regressionFew hand-offs, high revenue: run every cycle and every release
Full evidenceMany hand-offs, high revenue: run end to end with complete evidence and both owners reviewing
Deciding how much execution effort a scenario deserves.
The Sign-Off Table · thesignofftable.com/academy/sap-sd-303

When a step fails mid-chain

If billing fails on day 3, do not restart the scenario with fresh data. Log the defect against the last good document, keep the chain intact, and resume from the failed step once the fix is transported. That way the retest proves the fix works on a document that took the real path, and the evidence pack still shows one unbroken chain. Use the monitoring apps from SD 302 every morning to catch scenarios that stopped without anyone noticing.

What would you do?

Contoso's O2C regression shows all invoices posted correctly. Cash application has been "tested by the finance team separately" with invoices they created themselves. Luis asks whether order to cash can be called end to end. What is the best answer?

Key points
  • Run O2C end to end on the same data: master data, order, delivery, goods issue, invoice, output, payment.
  • Include a credit block with release and a rejection, returns, and output checks.
  • Close the loop with cash application the way production will receive payments.
  • Record every document number and attach the document flow, journal entries and line items.
  • Keep test data separate per scenario so one test cannot make another pass.

Check your understanding · not graded

Lesson check

  1. 1. Why run O2C end to end rather than as separate step tests?

  2. 2. What is the expected result for an order blocked by credit management?

  3. 3. Where do you confirm the invoice was paid?

  4. 4. Why keep test data separate between scenarios?