Lesson 6 of 6
Testing invoice verification controls
8 min
Invoice verification is where testing pays for itself. A missed tolerance, a duplicate check that never fires or a release authorization that is too wide costs real money after go-live, and it is the kind of defect auditors find before you do. Contoso's AP tests are designed around one question: does every control stop what it should stop and let through what it should let through?
Designing boundary tests
Tolerances are numbers, so test them at the edges. For each active tolerance key, post one invoice just inside the limit and one just outside it. For PP at $250 and 2% on Lakeside's $21,000 PO value, an invoice $240 above is within both limits; an invoice $260 above breaks the absolute limit; and for a smaller PO, check which of the two limits bites first.
- Is the variance below the lower limit?Yes → expect a message, no block · No → next question
- Is the variance within the upper limit?Yes → expect no message, no block, difference to price difference · No → next question
- Is it above the upper limit?Yes → expect a message, posting allowed, payment block on supplier line
- Does the payment run skip it?Yes → pass · No → defect: block not effective
Contoso's invoice verification test set
| Test | Setup | Expected result and evidence |
|---|---|---|
| IV-01 exact match | Invoice = PO price × received quantity | Posted, no block; journal entry GR/IR debit / supplier credit |
| IV-02 price inside tolerance | $240 above | No block; $240 to price difference |
| IV-03 price above tolerance | $260 above | Price block; payment block on supplier line; skipped by payment proposal |
| IV-04 quantity above receipt | Invoice 510 for 500 received | Quantity block (DQ) |
| IV-05 invoice before receipt | No GR yet, GR-based IV off | Blocked per DW setting |
| IV-06 duplicate | Same supplier, reference, date and amount as IV-01 | Duplicate message as warning or error per design |
| IV-07 manual block | Header payment block R | Not in payment proposal until released |
| IV-08 automatic release | IV-03 plus subsequent credit | RM08RELEASE releases; paid in next run |
| IV-09 unauthorized release | Clerk without release authorization | Release refused |
| IV-10 credit memo and subsequent credit | After return of 30; price correction | Invoiced quantity 470; GR/IR balanced |
| IV-11 reversal | Cancel IV-01 with MR8M | Reversal document; PO open for invoicing again |
A compact set that covers every invoice verification control.
Evidence that proves a control
"Posted" is not evidence. For each test, capture the invoice document number, the journal entry with its lines, the blocking reason on the item, and the payment block on the supplier line (visible in the supplier line items report or Manage Supplier Line Items app). For blocked invoices, the most convincing evidence is the payment proposal log showing the invoice was excluded. For the duplicate test, record the exact message number and whether it was a warning or an error.
Run the tests with the real roles. The AP clerk creates invoices; the AP supervisor releases; the buyer changes PO prices. A super user who can do everything will release an invoice that a clerk should not be able to touch, and the test will pass for the wrong reason. Include the stochastic block too: you cannot predict which invoice it will pick, so check that the configuration (threshold and percentage) matches the design and that a block, when it appears, behaves like the others.
What would you do?
IV-03 posts with a price block, but the invoice still appears in the test payment proposal. What should Priya do?
Finally, reconcile. At the end of the cycle, list every test PO and check its GR/IR balance. Exact-match and fully credited POs should be at zero. Anything else should be explained by an open receipt or an open invoice, document by document. This reconciliation is the bridge to the period-end work in sap-mm-302.
- Test each tolerance key just inside and just outside its limits.
- Prove blocks by showing the invoice excluded from a payment proposal, not just by the blocking reason.
- Test duplicates, manual blocks, automatic release, reversals and release authorizations.
- Use real roles and reconcile GR/IR for every test PO before sign-off.
Check your understanding · not graded
Lesson check
1. What is the best evidence that a price block works?
2. How should a tolerance limit be tested?
3. Why should releases be tested with the AP clerk role rather than a super user?
4. What should GR/IR show for an exact-match test PO after invoicing?