Business logic flaws are made of valid requests that the application should not have accepted together. Scanners cannot find them, because every individual request looks correct.
The questions that find them
What does the system assume about order? Can a step be skipped, repeated, or performed after the fact — confirming an order after cancellation, applying a discount after payment, uploading evidence after approval?
What does it assume about quantity? Negative amounts, zero, enormous values, fractional currency, and the same voucher used in two sessions at once.
What does it assume about state it does not own? Prices, totals and entitlements calculated on the client and trusted by the server are the oldest version of this problem and still common in checkout flows.
What happens concurrently? Race conditions turn one-use into many-use: two simultaneous withdrawals against the same balance, two redemptions of one code. Testing this needs parallel requests, not a sequence.
How to prepare
You cannot test logic you do not understand. Read the documentation, talk to whoever specified the feature, and write down the rules in plain sentences: "a refund cannot exceed the amount paid", "a free account may create three projects". Each sentence is a test.
Why it matters
These are the findings that cost money directly, and the ones most likely to be already in use by somebody who found them by accident.