Lesson 3 of 6
Manual, stochastic and duplicate checks
9 min
Variance blocks are automatic and driven by data. SAP S/4HANA has three more controls that AP teams use every day: blocking an invoice by hand, blocking a random sample for review, and refusing or warning on invoices that look like duplicates. Each one needs to be designed and tested, because each one fails silently if it is set up wrong.
Manual blocks
A clerk can block an invoice on purpose. At header level, set a payment block key on the invoice's payment tab; key R (invoice verification) is the usual one, and companies can define their own. At item level, set the manual blocking reason on the line. Either way SAP puts the payment block on the supplier line of the journal entry, so the payment run will not pick it up. Contoso uses a manual block when Lakeside's invoice is missing a certificate of conformity that quality requires before payment.
Stochastic (random) blocks
Stochastic blocking picks invoices at random for a second look, a deterrent against careless or fraudulent entry. It is activated per company code and configured with a threshold value and a percentage. Invoices at or above the threshold are blocked with that percentage probability; smaller invoices have a proportionally lower probability. It only applies to invoices that have no other blocking reason. Contoso uses a $10,000 threshold and 5%.
Item amount check
The item amount check blocks invoice items with large amounts so that a second person reviews them. It is activated per company code, limited to certain item categories and goods receipt settings, and uses tolerance keys AN (items without PO reference) and AP (items with PO reference). An item above the limit gets an amount blocking reason, and the whole invoice is blocked for payment.
| Control | Triggered by | Level | Released by |
|---|---|---|---|
| Variance block | Price, quantity, date or quality variance beyond tolerance | Item, blocks whole invoice | Automatic release when the cause is gone, or manually |
| Manual block | Clerk sets payment block key or item blocking reason | Header or item | Manually |
| Stochastic block | Random sample above a threshold | Whole invoice | Manually |
| Item amount check | Item amount above AN/AP limit | Item, blocks whole invoice | Manually |
| Quality block | Inspection lot not yet released at invoice entry | Item | Automatically after a positive usage decision, or manually |
Duplicate invoice check
The most expensive invoice error is paying the same invoice twice. SAP's duplicate check compares a new invoice with invoices already entered and warns (or, if configured, stops) when they match. Two settings must both be in place: the check double invoice indicator in the supplier's company code data, and the company code's duplicate-check criteria in Customizing (Set Check for Duplicate Invoices), where you choose whether company code, reference and invoice date are part of the comparison. Supplier and currency are always compared; whether the amount is compared depends on the release and setup, so verify it in your system. The check only works if the clerk enters the supplier's reference.
- Is "check double invoice" set for Lakeside in company code 1710?No → no duplicate check at all · Yes → next question
- Did the clerk enter the reference LC-88412?No → the check has nothing to compare · Yes → next question
- Do supplier, currency and the active criteria match an existing invoice?Yes → message M8 462 style warning or error, depending on message settings · No → posts normally
- Is the message configured as an error?Yes → posting is refused · No → the clerk can still post after the warning
The more criteria you activate, the more exact the match must be, and the fewer duplicates are caught. If invoice date is a criterion and Lakeside re-sends LC-88412 with a different date, SAP will not see a duplicate. Many companies keep reference and company code as criteria and leave invoice date out, accepting more warnings in exchange for fewer misses. Invoices posted outside invoice verification (for example directly in finance) may not be compared with MIRO invoices, so test across entry channels.
What would you do?
During testing, Priya's team enters Lakeside's invoice LC-88412 twice in client 100 and SAP posts both without any message. What is the first thing to check?
- Manual blocks use a payment block key (such as R) at header level or a blocking reason at item level.
- Stochastic blocks sample invoices at random above a threshold; the item amount check uses AN and AP.
- The duplicate check needs the supplier indicator, the company code criteria and an entered reference.
- Every block ends up as a payment block on the supplier line, which keeps the invoice out of the payment run.
Check your understanding · not graded
Lesson check
1. Which payment block key is commonly used for a manual block in invoice verification?
2. What is required in the supplier master for the duplicate invoice check to run?
3. Stochastic blocking applies to which invoices?
4. Which tolerance keys does the item amount check use?