Purchase order test cases, where the approval stops meaning anything

The amendment that keeps its approval is the defect worth building this set around. An order approved at 9,900 sits below a 10,000 threshold. If the quantity is then raised so the total becomes 14,000 and the original approval stands, the authority limit has been defeated without anything unusual happening. Any workflow that treats approval as a status on the record rather than as an assertion about a specific value is exposed to it. The same reasoning applies at approval time: the limit must be checked against the order value at the moment of approval, because the value may have moved since it was routed.

The three-way match is where the money actually leaves, and it fails in two directions. Invoicing ahead of receipt is the common one: an invoice for a hundred units against sixty received should clear only sixty, and a system that matches invoice to order without consulting the receipt will pay the full amount. Price variance is the other, and it is usually a units problem: a percentage tolerance applied to the invoice total rather than to the unit price will pass an overpriced line as long as the quantity is small enough to keep the total inside the band.

Budget commitment is a concurrency case that sequential testing cannot reach. Two approvers acting at the same instant on two orders that each fit inside the remaining balance but together exceed it will both succeed if the balance is read and then written. The same shape appears when two approvers act on the same order, one approving and one rejecting: a silent last write wins can turn a rejection into an approval, and the audit trail will show both actions with no indication of which one took effect.

Finally, the boring controls are the ones auditors test. Self approval must be refused on the server rather than by hiding a button. Delegated authority must expire. Postings into a closed accounting period must be refused, because they silently change figures that have already been signed off. Vendor status must be rechecked at approval time and not only at creation, since a vendor can be blocked in between. And duplicate invoice detection has to match on more than the invoice number, because the resubmission that matters arrives with a modified reference and an identical amount and date.