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

Lesson 5 of 5

Sign-off

10 min

When Dan signs the AP and AR stream, he is saying that Contoso can pay its suppliers and collect from its customers correctly from day one, and that what is not yet perfect is known and accepted. His signature needs evidence he can read without re-running the tests, and a written record of every risk he is accepting.

The evidence pack

An AP and AR evidence pack is organized by scenario, not by transaction. For each scenario, it shows the expected result written beforehand, the actual result and the documents that prove it.

Scenario resultsEach scenario with expected result, actual result, pass or fail, tester, date, system and client
DocumentsInvoice, payment and clearing document numbers so anyone can display them again
Open item proofSupplier and customer line item lists before and after: open, cleared, partial or residual as expected
Run outputsPayment proposal, exception list, payment list and the payment medium; dunning proposal and sample notices
Ledger proofJournal entries for discounts, tax and exchange differences checked against expected lines; GR/IR and bank clearing balances explained
Layers of evidence for an AP and AR sign-off, from scenario detail up to the ledger.
The Sign-Off Table · thesignofftable.com/academy/sap-fin-306

The open item proof deserves its own step. In FBL1N and FBL5N, or the Manage Supplier Line Items and Manage Customer Line Items apps, show the test supplier and customer accounts with cleared items included. A reviewer can see in one screen which items cleared, by which clearing document and on which date. That is stronger evidence than a series of success messages.

Evidence itemAP (Lakeside Components)AR (Great Lakes Fleet Services)
Scenario listDiscount taken and missed, partial, blocked, credit memo, CAD invoiceDiscount, short payment, residual item, credit memo, dunning levels
Run outputsProposal, exception list, payment list, payment file and bank test acknowledgementDunning proposal, sample notices, dunning history
Line itemsSupplier account with cleared items shownCustomer account with cleared, residual and disputed items shown
Journal entriesDiscount, tax, exchange gain or loss linesDiscount, tax, short payment, exchange difference lines
ControlsBank detail change approval tested; payment run release by a second personDunning block and dispute handling per policy

What Dan expects to see before signing.

Controls are part of the scope

AP is a classic fraud target. The two controls auditors ask about first are changes to supplier bank details and release of payment runs. If Contoso has activated dual control for sensitive fields on the business partner, a change to Lakeside's bank account should wait for a second person's confirmation before the supplier can be paid. If the project uses SAP Bank Communication Management, payment batches go through an approval step before they are sent. Test both: try to pay a supplier immediately after changing its bank details, and try to release a batch with the same user who created it. Both attempts should be stopped.

Accepted risks

Few releases go live with zero open defects. The difference between a professional sign-off and a hopeful one is that every open item is written down with its impact, a workaround, an owner and a date. Dan accepts each one by name.

FieldExample
Defect or gapPayment advice email shows supplier invoice reference truncated to 16 characters
ImpactLakeside's AP clerk needs a phone call to match two invoices per month
WorkaroundAP team sends a manual remittance list for affected suppliers
Owner and due dateFinance IT lead; fix in the first post-go-live release
Accepted byDan, finance process owner, with date

An accepted-risk entry. Sev 1 and sev 2 defects should not appear here.

  1. Have all high-impact scenarios passed with evidence?Yes → next question · No → no-go until they pass or are formally de-scoped
  2. Has the payment file been accepted by the bank's test service?Yes → next question · No → no-go for electronic payments
  3. Do bank detail and payment release controls work?Yes → next question · No → no-go; this is an audit finding
  4. Is every open defect low severity, with workaround, owner and date, and accepted by Dan?Yes → sign · No → resolve or escalate to Grace's steering meeting
Go or no-go for the AP and AR stream.
The Sign-Off Table · thesignofftable.com/academy/sap-fin-306
  1. Week −6Scenario sets completeAll AP and AR scenarios executed in QAS client 100 with evidence
  2. Week −5Bank file testPayment file submitted to the bank's test service; acknowledgement filed
  3. Week −4Defect triageOpen defects ranked; workarounds written; accepted-risk entries drafted
  4. Week −3Stream sign-offDan signs AP and AR with the evidence pack and accepted risks
  5. CutoverOpen items migratedLuis's cutover reconciles migrated open items to the legacy balances
Where AP and AR sign-off sits in Contoso's final weeks.
The Sign-Off Table · thesignofftable.com/academy/sap-fin-306

What would you do?

Two days before the stream sign-off, the bank's test service rejects Contoso's payment file because of a header field. Everything else has passed. Grace asks whether Dan can sign anyway. What is the most responsible answer?

Key points
  • Organize the evidence pack by scenario: expected result, actual result, document numbers.
  • Show open item lists with cleared items, run outputs and journal entries for discounts, tax and exchange differences.
  • Test controls: bank detail changes and payment release by a second person.
  • Write every accepted risk with impact, workaround, owner, date and the owner's acceptance.
  • Sign-off can be partial; say exactly what is and is not signed.

Check your understanding · not graded

Lesson check

  1. 1. Which evidence best shows a reviewer that test items were cleared correctly?

  2. 2. Which two AP controls do auditors usually ask about first?

  3. 3. What must every accepted-risk entry include?

  4. 4. What should Dan do if a random sample from the pack does not match its documented result?