Lesson 2 of 6
Acceptance criteria
10 min
An acceptance criterion is a statement of what must be true for the business to accept a process. Good criteria are written in business terms, so the process owner can own them, and are measurable, so anyone can judge them. In SAP the most useful criteria describe outcomes: documents created, statuses reached, amounts posted to the right place.
From vague to measurable
| Vague | Measurable |
|---|---|
| Orders can be entered. | A standard order for Great Lakes Fleet Services in sales area 1710 / 10 / 00 for CMC-ALT-100 saves with the price from the condition records and passes the credit check. |
| Billing works. | Every billing document from the 25 order-to-cash scenarios creates a journal entry: receivable on the customer, revenue on the agreed G/L account, profit center for alternators. |
| Deliveries are processed. | Each delivery reaches goods movement status complete; stock in plant 1710 is reduced by the delivered quantity. |
| Credit control is in place. | An order that exceeds the customer's credit limit is blocked and cannot be delivered until released by the credit team. |
| Reports are correct. | Open receivables in the analytical app equal the receivables balance on the G/L account at period end. |
Rewriting vague criteria as measurable outcomes.
Notice what the measurable versions have in common. Each names the data (customer, product, org unit), the action, and a result you can display in SAP. Each can be judged by someone who was not in the design workshops. And each ties back to a design decision: the agreed G/L account, the profit center for alternators, the credit rules. If a criterion cannot name its expected result, the design is probably not finished.
A simple pattern
Most good SAP acceptance criteria fit the pattern given (data and starting state), when (the business action), then (the observable result in the system). For example: given a customer with a $50,000 credit limit and $45,000 open, when Maria enters an order for $8,000, then the order is saved with a credit block and no delivery can be created.
- GivenCustomer with a $50,000 credit limit and $45,000 open; sales area 1710 / 10 / 00
- WhenMaria enters an order for 40 CMC-ALT-100 worth $8,000
- Then (document)The order is saved with a credit block status
- Then (consequence)No outbound delivery can be created until the credit team releases the order
The "then" is where most criteria are weak. Insist on results a reviewer can see in the system: a document, a status, a posting, a block, an output. "The user is satisfied" is not a system result.
What to cover
- Happy path: the standard flow works end to end, including the journal entries.
- Variants that matter: partial delivery, returns, a second plant (1720 Chicago), a different currency if relevant.
- Negative cases: the system refuses what it should refuse: credit blocks, missing data, unauthorized users, closed periods.
- Controls: approvals, tolerances and segregation of duties behave as designed.
- Integration: data reaches and returns from connected systems correctly.
- Performance or volume where it matters, such as the billing run finishing within the overnight window.
How many criteria are enough? For a process like order-to-cash, expect a handful of process-level criteria supported by scenario-level expected results. Too few and important behavior is left untested; too many and the list becomes a second test script that nobody reads. A useful check is to ask, for each design decision in the decision log, which criterion proves it.
Who writes and who approves
The process owner owns the criteria. Key users usually draft them, the test lead checks they are testable, and the solution architect checks they reflect the design decisions. Agree them before test execution starts, record them with the test plan, and change them only through the same approval route. In SAP Cloud ALM, criteria can sit in the requirement or the test case description, so they travel with the test.
What would you do?
Maria drafts this criterion: "Returns are handled correctly." Priya says it is not testable. Which rewrite is best?
- Write acceptance criteria as business outcomes that can be observed in SAP.
- Use given / when / then and make the "then" a document, status, posting, block or output.
- Cover the happy path, important variants, negative cases, controls, integration and performance.
- The process owner owns the criteria; agree them before execution and change them only by approval.
Check your understanding · not graded
Lesson check
1. What makes an acceptance criterion measurable?
2. In given / when / then, which part is most often too weak?
3. Which is a negative acceptance criterion?
4. Who owns the acceptance criteria for a process?