Lesson 2 of 5
Safe payment testing
10 min
The automatic payment program is the most dangerous transaction to test in finance. It is designed to produce files that move money. Contoso's test client 100 in QAS was copied from production data, which means supplier bank details are real, and the house bank configuration may point at real accounts. A test run that reaches the bank is not a test defect; it is an incident.
How a payment run works
In SAP GUI the program is F110; in the launchpad the Manage Automatic Payments app covers the same steps, and Revise Payment Proposals lets an accountant review and change a proposal. Either way the run goes through the same stages.
- ParametersRun date and identification, posting date, documents entered up to, company code 1710, payment methods, next payment date, supplier range
- ProposalThe program selects due items, applies discounts, groups payments and lists exceptions; nothing is posted yet
- Edit proposalAn accountant blocks, unblocks or changes items; the proposal can be deleted and recreated
- Payment runPayment documents post: suppliers debited, bank clearing credited, open items cleared
- Payment mediumChecks are printed or a file is generated (for example through the Payment Medium Workbench) and sent to the bank
The proposal is where most of the testing value lives. It shows which items were selected, which discount was applied, which payment method and house bank were chosen, and, in the exception list, which due items were not paid and why: a payment block, missing bank details, an amount below the minimum, a missing payment method. You can run the proposal as often as you like, with no postings and no file.
Safeguards, in layers
No single setting makes payment testing safe. Contoso uses several layers, so that one mistake does not become an outgoing payment.
What to test in a payment run
| Check | Where you see it | Contoso expectation |
|---|---|---|
| Items selected | Proposal list | All Lakeside invoices due by the next payment date, except blocked ones |
| Discount | Proposal list, then payment document | 2% taken on invoices inside the discount period; posted to the cash discount account |
| Exceptions | Exception list | Price-variance-blocked invoice listed with its block reason |
| Payment method and bank | Proposal | Payment method and house bank chosen per the bank determination rules |
| Postings | Payment document and its journal entry | Supplier debited, bank clearing credited, invoice cleared |
| Payment medium content | The generated file, compared with the bank's format specification | Amounts, payee names, value date and file totals agree with the payment list |
A payment run test checks the proposal, the postings and the file.
The last row needs real care. A payment file can be valid to SAP and still be rejected by the bank: a missing field, a wrong batch header, a character set problem. Many banks offer a test service where you can submit a file and get a technical acknowledgement without moving money. Treasury arranges this, and the file is sent through the agreed test channel only. That is the right way to prove the format, not a small "real" payment.
- Has the post-refresh checklist been signed for this system?Yes → next question · No → stop; run proposals only
- Are bank details in the payment proposal masked test values?Yes → next question · No → stop and raise a data incident
- Is every outbound bank channel disabled or pointed at the bank's test service?Yes → next question · No → stop; ask Basis and treasury
- Has the test lead approved this run and named an owner?Yes → create the medium to the controlled directory · No → wait
What would you do?
During testing, a Contoso tester notices that a supplier bank account in the QAS payment proposal matches the real account on Lakeside Components' remittance advice. The payment run is scheduled to create a file in an hour. What should happen?
- F110 or Manage Automatic Payments: parameters, proposal, edit, payment run, payment medium.
- Most AP testing value is in the proposal and exception list, which post nothing.
- Layer the safeguards: masked data, test house bank, no live connection, controlled file location, printer control, procedure.
- Re-check safeguards after every system refresh.
- Prove file formats with the bank's test service, never with a small live payment.
Check your understanding · not graded
Lesson check
1. Which stage of the automatic payment program posts nothing and creates no file?
2. Where do you find due items that the payment program did not pay, and why?
3. QAS was refreshed from production last night. What must happen before any payment medium is created there?
4. How should Contoso prove that its payment file format is acceptable to the bank?