Lesson 5 of 5
Testing allocations and reversals
10 min
Listen to this lesson
Allocation tests are some of the most satisfying tests in SAP because the expected result can be calculated exactly. The evidence a controller accepts is simple to state: each sender is credited and each receiver is debited by the expected amount, on the expected account, in the expected period, and the totals balance. This lesson turns that statement into test cases, adds overhead and sequencing tests, and covers reversals, which are where many surprises hide.
Building the test set
| Test | Setup | Expected result |
|---|---|---|
| Facilities assessment CMCFAC01 | $120,000 on Facilities; square feet 30k/20k/10k | Facilities credit $120,000; Assembly $60,000, Machining $40,000, Warehouse $20,000 on the assessment account |
| IT Services distribution | $18,000 licences; headcount 60/30/30 | Assembly $9,000, Machining $4,500, Warehouse $4,500 on the licence account |
| Activity allocation | 120 ASSYHR hours to an alternator order | Assembly credit $6,240; order debit $6,240 on the category 43 account |
| Overhead CMC001 | $40,000 material base on an order | Order debit $4,000; Warehouse credit $4,000 |
| Missing tracing factor (negative) | No square feet for a new receiver | Receiver gets nothing; run log flags it; no silent misallocation |
| Reversal | Reverse CMCFAC01 live run | All $120,000 back on Facilities; receivers at prior balances |
Allocation test cases for Contoso Detroit. Each expected result is calculated before execution.
Notice the negative test. A good allocation test set always includes cases that should not allocate: a receiver without a tracing factor, a cost center outside the validity period, a sender account that is not in the segment. Allocation bugs are usually silent: a wrong key or a missing receiver still posts a balanced document. Only an expected result catches it.
- Write expected resultsPer sender and receiver, by account, from the test data
- Test runRun Allocations in test mode; compare; fix cycle or data
- Live runPost; capture Allocation Results and journal entries
- ReconcileSum of sender credits = sum of receiver debits; sender balance as designed
- Reverse and rerunReverse the live run; confirm balances return; run again; confirm same result
Reversals
Reversal is how you correct a live allocation run: you reverse the run in Run Allocations, fix the cycle or the data, and run again. Test the reversal itself. Confirm that every journal entry of the run was reversed, that sender and receiver balances return to their values before the run, and that a rerun after reversal gives the same result as the original when nothing changed. SAP notes that reporting on reversal runs is more limited than on normal runs, so capture the before and after balances yourself. Also test the controlling period lock: a reversal or rerun in a locked period should be blocked, and the close team needs to know who can unlock.
| Evidence | Weak | Strong |
|---|---|---|
| Cycle result | "Cycle ran, status green" | Sender and receiver amounts equal to the expected table |
| Accounts | Total moved looks right | Each amount on the expected account (original, category 42 or 43) |
| Overhead | Some orders show overhead | Base × rate verified on sampled orders; credit object verified |
| Sequence | Steps ran on the right day | Dependencies checked: no settlement before overhead, no assessment before cut-off |
| Reversal | Reversal ran | Balances back to pre-run values; rerun gives the same result |
Testing the sequence
Test the close sequence as a whole at least once before go-live, using a realistic month: Priya's team copies May data into CMQ and runs the full controlling close in order, recording start and end times and every issue. Then run a deliberate out-of-order case in a sandbox (settlement before overhead, for example) to show the team what the symptoms look like. Learning to recognize a wrong-order result in test is cheaper than discovering it in the first real close.
Keep the allocation tests as a regression pack. After go-live, every change to a cycle, a costing sheet, an activity rate or the cost center hierarchy can change allocation results. Store the test data, the expected-results sheet and the captured results with the test cases in SAP Cloud ALM, so the next change is tested against the same baseline. Most allocation tests can be rerun in under an hour once the expected results exist; building them is the expensive part, and it only has to be done once.
What would you do?
In UAT, the facilities assessment test passes: the $120,000 split matches. A week later, someone adds a new receiver cost center to the segment for a new paint shop with 5,000 square feet. Should the test be repeated?
- Evidence: each sender credited and each receiver debited by the expected amount on the expected account, totals balanced.
- Include negative tests: missing tracing factors and out-of-scope receivers must not allocate silently.
- Test reversal: balances return, rerun gives the same result, locked periods block changes.
- Rehearse the whole controlling close in order in test, and retest cycles whenever senders, receivers or keys change.
Check your understanding · not graded
Lesson check
1. What is the core expected result of an assessment test?
2. Why include a receiver with no tracing factor in the tests?
3. After reversing a live run, what confirms the reversal worked?
4. IT Services distributes $18,000 of licences by headcount 60/30/30. What does Detroit Assembly receive, and on which account?