One business process. Six places quality can disappear.

The question

Take a process nobody needs explained. Purchase requisition, approval, purchase order, goods receipt, invoice, accounting. It appears on every SAP programme and it is usually one of the first things marked as covered.

What does “covered” mean here? Almost always: somebody raised a requisition, it was approved, a purchase order was created, goods were received, an invoice was posted, and the test passed. That is one path. The process has many.

This is a field note rather than research. The pattern below is what we see repeatedly, in anonymised form, and it is offered as a checklist rather than as a finding.

What we see in programmes

Six specific places where coverage goes missing on a process like this. They recur with enough consistency to be worth checking deliberately.

1. The variant. The approval that crosses a second threshold. The one that routes to a substitute because the approver is away. The one for a different purchasing organisation, document type or material category. Each of these is a different behaviour of the same process, and each can be configured differently. The main path passing tells you very little about them.

2. The integration. The point where the process leaves SAP or crosses a module boundary. The invoice that goes to a scanning solution. The vendor master fed from a third-party system. The payment file to the bank. These are frequently owned by a different team and tested, when they are tested, in isolation from the process they belong to.

3. The data condition. The vendor with a blocked flag. The material with a special procurement type. The contract that has expired. The tax condition that only applies in one country. Test environments tend to hold clean, recently created data, which is precisely the data least likely to reveal these.

4. The authorisation. The tester has broad access. The buyer, the approver and the accounts payable clerk each have narrow access. A process that works end to end for one person with all three sets of rights has not been tested as it will be used. This is a reliable first-week-after-go-live defect.

5. The exception path. Rejection. Partial receipt. Over-delivery inside tolerance and outside it. Invoice blocked on price or quantity variance. Cancellation and reversal. These are not edge cases in a purchasing process — they are a substantial share of real volume, and they are where the business feels a defect fastest.

6. The hand-off. The moment the process moves between people or teams. Buyer to approver. Warehouse to accounts payable. Each hand-off carries an assumption about what the previous person did, and assumptions are where processes break when the system changes underneath them.

Nobody decides to skip the variant. It falls out somewhere between the workshop and the test plan, and it is invisible unless you look for it on purpose.

A better way to think about it

The useful move is to stop treating “covered” as a binary property of a process and start treating it as a small grid: the process down one axis, the six loss points across the other.

Filled in honestly, the grid usually shows a familiar shape. The main path is solid. Variants are patchy. Integrations are covered somewhere else by somebody else. Data conditions are thin. Authorisations are untested. Exception paths are partly covered. Hand-offs are not represented at all.

That is not a criticism of the team. It is what a test scope built from functional specifications naturally produces, because specifications describe intended behaviour and the loss points are mostly about circumstance.

What good looks like

Variants enumerated before scenarios are written. Ask the process owner, not the specification: what are the materially different ways this runs? The answer is usually four to eight, and usually surprises the test team.

Integration points listed on the process, not in a separate interface inventory. The same interface appears differently depending on which process it serves.

At least one deliberately awkward data set. Old records, blocked vendors, expired contracts, unusual tax conditions. Clean data is where coverage goes to hide.

A handful of scenarios run under real role assignments. Not all of them. Enough to find out whether the roles work.

Exception paths given the same status as happy paths. If the invoice-blocked scenario is optional and the invoice-posted scenario is mandatory, the plan has already decided which defects will reach production.

Questions leadership should ask

For our top ten processes, how many variants have we tested each one across?

Which exception paths are in scope, and which were dropped?

Has anything been run under a real business role rather than a test role?

Where does each critical process leave SAP, and who tested that hand-off?