Lesson 6 of 6
Testing project period-end
9 min
Listen to this lesson
Project period-end is where conversions hurt. Projects carry history: settlement rules written years ago, results analysis keys tied to old cost elements, budgets loaded in another era, statuses that nobody revisited. After a system conversion, the first month-end often finds them all at once. This lesson gives Priya's test team the tests that catch them in the mocks, not in production.
Why project period-end fails after conversion
| Area | What changes in SAP S/4HANA | Typical failure |
|---|---|---|
| Cost elements | Cost elements are G/L accounts; secondary ones have cost element categories such as 21 for settlement | Settlement or RA line IDs reference cost elements not created correctly as accounts |
| Settlement | Postings land in ACDOCA with full G/L detail | Settlement to receivers with missing profit center or segment fails or splits wrongly |
| Results analysis | Results flow into margin analysis rather than costing-based CO-PA (see sap-co-305) | Values settle to the wrong account or attribute |
| AVC | AVC data must be rebuilt for open projects | No messages, or wrong assigned values |
| Statuses | Old user status profiles carried over | TECO or CLSD blocked by user statuses nobody uses |
Common reasons project period-end breaks after a conversion.
The test set
- Select projectsA sample of real converted projects of every type, plus new test projects
- Post the periodInvoices, confirmations, goods issues, commitments
- Overhead and RACJ45 overhead, KKAJ results analysis on customer projects
- SettleCJ8G periodic settlement, test run first, then live
- ReconcileWBS balances, receivers, G/L accounts and margin analysis
- ExceptionsEvery error in the settlement log classified and resolved
Use real converted projects, not only clean new ones. The defects live in the old data. Contoso's test set took every active capital project, every customer project with open results analysis, and a random sample of 30 overhead projects, and ran period-end on them in CMQ after Mock 2. A settlement test run first shows what would happen without posting, which is the safest first look.
Reconciliation checks
| Check | Expected result | Evidence |
|---|---|---|
| Balance on settled WBS elements | Zero, except by design | Project balance report after settlement |
| AuC values | Equal to settled amounts per element | AuC asset values versus settlement documents |
| Cost center 18101101 | Received exactly the 10% training share | Cost center line items with settlement reference |
| Customer project results | Earned revenue and accrual match the hand calculation | RA values and settlement document |
| G/L | Settlement accounts net correctly; nothing on suspense | Trial balance by account for the settlement documents |
What a project period-end reconciliation proves.
What would you do?
In Mock 2, settlement of 40 old overhead projects fails with "cost element not valid for settlement". New projects settle fine. What is the most likely cause, and fix?
What goes wrong in testing
- Running settlement live first and creating hundreds of documents to reverse.
- Testing only new projects, so converted settlement rules and RA keys are never exercised.
- Checking that settlement "ran" instead of checking the receivers received the right amounts.
- Forgetting the year-end steps: budget carryforward of annual values and commitments, and final settlement of completed projects.
Year-end deserves its own test. Annual budgets and commitments may need to be carried forward into the new fiscal year, completed capital projects need final settlement from AuC to fixed assets, and projects technically completed during the year should be closed once their last settlement is done. Plan a year-end test in the mock cycle that covers the go-live year, or in the first months of hypercare.
A worked defect from Mock 2
In Contoso's Mock 2 period-end test, the Great Lakes program showed earned revenue of USD 600,000 after period 6, the full contract price. The cause was a converted results analysis version whose planned costs were not carried over: with no plan, cost-based progress could not be calculated, and the valuation method treated the project as complete. The fix was to load the planned costs into the version RA reads and rerun results analysis before settlement. The lesson for the test set: for every customer project, check the plan data RA uses before running RA, and compare RA output with the hand calculation every time.
| Defect area | Mock 1 count | Mock 2 count | Comment (illustrative) |
|---|---|---|---|
| Settlement rule missing or wrong | 64 | 9 | Rules repaired by mass change before Mock 2 |
| Settlement cost element invalid | 40 | 0 | Allocation structure corrected |
| Results analysis inputs missing | 3 | 1 | Plan version for RA, as above |
| AVC not active after conversion | All projects | 0 | CJBV and CJBN added to the conversion runbook |
Project period-end defects across mocks, used to decide readiness.
- Project period-end fails after conversion because of old data: rules, keys, profiles, statuses.
- Test with real converted projects of every type, not only new ones.
- Run settlement as a test run first, then live, then reconcile receivers.
- Plan a year-end test: carryforward, final settlement and closing.
Check your understanding · not graded
Lesson check
1. Why test period-end with real converted projects?
2. What is the safest first step when testing settlement?
3. What proves settlement worked?
4. Which item belongs in a project year-end test?