Sign-off package

Sign-off is a decision, and the sign-off package is what the decision rests on. It should let the controller, and later an auditor, see in one place what was tested, what the results were, what is still open, and what conditions apply. If someone asks a year from now why R2R was accepted, the package answers without anyone having to remember.

The coverage summary

Start with the coverage matrix from lesson 1, now filled with results. Show the percentage of accounts with a balance that were touched by at least one passed scenario, the close tasks that ran with evidence, and the scope items covered with their company variants. List the accepted gaps explicitly with Dan's reason. A short, honest gap list builds more trust than a claim of 100%.

Results and reconciliations

Include the integrated close comparison: expected versus actual by statement line, per company code (1710 and 1810) and per ledger (0L and 2L), with every difference explained. Add the subledger-to-G/L reconciliations, the ledger-to-ledger comparison against the difference register, the segment trial balances, and the intercompany reconciliation status for the 1710/1810 pair.

Risk acceptances and conditions

Each open defect that is not fixed needs a written risk acceptance: the defect, its misstatement risk, the compensating control, the owner, and the date by which it will be fixed. The controller can sign with conditions, for example "conditional on the default profit center reclassification control being executed at each month-end until defect 214 is fixed," or "conditional on a successful rerun of the IFRS valuation in the final cutover rehearsal." Conditions must be specific, owned and checkable.

Where the package fits in the program

In SAP Activate terms, R2R sign-off belongs at the end of the Realize phase, as input to the go-live decision in the Deploy phase. SAP Cloud ALM (or SAP Solution Manager on older landscapes) can hold the test plans, results and defects, which makes the evidence index a set of links rather than a folder of files. The first real month-end close after go-live is the final test, so keep the conditions alive until it is complete and reconciled.

Write the package for a reader who was not in the project. Use plain statements: "All 410 accounts with balances were touched by at least one passed scenario, except the 21 listed in appendix A, accepted by Dan on September 3." Avoid internal shorthand and test tool status codes. Keep the decision page to one page. An auditor reviewing the implementation, or a new controller a year later, should understand what was proven, what was accepted, and why, without asking anyone. That is also the best test of whether the package is complete: if a reasonable question cannot be answered from it, something is missing.