Implementation worksheet · 5 min read
A Purchase Approval App Specification with Spending Thresholds
Specify four components before building: the routing matrix (amount bands × categories → approver chains, e.g. <$500 auto-approve with log; $500-5k department head; $5k-25k +finance; >$25k +CEO; IT always +security), request states (draft → pending → approved/rejected → ordered → received), delegation rules (time-boxed, self-service, logged), and the audit row every action writes (actor, timestamp, state change, comment). The matrix is the business logic — get it signed off by finance before any build, because the app merely enforces what this table says.
Purchase approvals are the internal tool with the clearest spec-first payoff: the rules already exist in someone's head or a dusty policy PDF. Writing them as a matrix surfaces the contradictions (two owners for marketing spend, no rule for recurring subscriptions) while they're still cheap to resolve.
Put it into practice
1. Write the routing matrix with finance
Rows are amount bands, columns are purchase categories, cells are approver chains. Force the awkward cells: who approves the CEO's own requests? What about recurring renewals — re-approve annually or auto-renew under a cap?
2. Define states and who moves them
Requesters create and can cancel; approvers approve/reject with required comment on rejection; purchasing marks ordered/received. Nobody edits an approved request — changes create a new revision through the chain again.
3. Spec delegation before someone leaves
Approvers set their own delegate and window in advance; delegated approvals log both names. The alternative — admins reassigning ad hoc during vacations — is where audit trails go to die.
4. Make the audit row automatic
Every state change writes actor, timestamp, from→to, comment. The row is written by the system, not the user, and nothing moves state except through the workflow — no status dropdown an admin can flip.
5. Describe it to the builder in matrix order
The spec IS the prompt: entities (request, approval, delegation), the matrix as rules, states as transitions, roles as visibility. A generated app enforces exactly what you wrote — which is why the writing is the work.
Routing matrix template
Copy this structure into your review document and record your observed result for each row.
| Amount band | Default chain | IT category | Recurring |
|---|---|---|---|
| < $500 | auto + log | + security review | annual re-approve |
| $500–5k | dept head | + security review | annual re-approve |
| $5k–25k | dept head → finance | + security review | finance annually |
| > $25k | dept head → finance → CEO | + security review | board-level policy |
| CEO's own | finance → board delegate | same | same |
A failure worth checking
The edit-around failure: the app has a beautiful workflow AND an admin panel where status is an editable field. Within a quarter, urgent purchases get 'fixed' directly, the audit trail has holes exactly where scrutiny would land, and the workflow is decoration. State moves through transitions or not at all — build that constraint in, don't police it after.
Common questions
Should small purchases really auto-approve?
Yes, with a log and a monthly roll-up — the approval system's scarce resource is approver attention, and spending it on $40 requests teaches everyone to rubber-stamp. The log preserves auditability; the threshold preserves attention.
What about purchases that span categories?
The matrix needs a precedence rule (highest-scrutiny category wins) written down. It's a one-line decision now or a recurring argument later.
Basis and scope
This is a proposed implementation method using illustrative examples, not a measured benchmark or a customer case study. Prepared with AI assistance. Validate product-specific behavior against current documentation and your own test environment.