The retroactive approval problem is universal in construction: the PM makes a purchase, submits the receipt at end of week, and the manager approves it after the fact. The money is already spent. The approval is a formality.
This workflow works fine for small, predictable purchases. It breaks down for larger ones, off-plan purchases, or purchases that affect a budget category that's already running tight. By the time the manager sees it in the weekly review, it's too late to redirect.
The Request-First Sequence
BLT's preferred purchase flow is request-first, buy-second:
- PM identifies what's needed and creates a Purchase Request from the mobile app: what, what it's for, which project and phase, estimated cost, preferred vendor, urgency level
- Manager receives a notification — push notification for urgent requests, in-app badge for normal ones
- Manager reviews the request with full budget context: the specific line item, its current balance, and any other pending expenses against it
- Manager approves (with or without modifications), or denies with a note
- PM gets the approval notification, makes the purchase
- PM photographs the receipt — OCR auto-matches it to the approved request by vendor name and amount
What the Manager Sees When Approving
The Purchase Requests queue shows each request with its full context: what the PM needs, which project and phase, the estimated cost, and — critically — the remaining balance in the targeted budget category. The manager isn't approving in a vacuum. They can see that the Framing Materials line has $2,400 remaining before approving a $2,100 lumber run, and either approve it, reduce the approved ceiling, or redirect to a different vendor with better pricing.
The Direct-Spend Fallback
Pre-approval isn't always practical. For urgent purchases under $500, BLT supports a direct-spend path: buy first, submit receipt, and the expense auto-approves if under the configurable threshold. For larger direct-spend purchases, the expense goes into the standard review queue.
All direct-spend expenses are tagged separately from pre-approved ones. The manager can track spending discipline over time — how often the PM is using the preferred workflow vs. the fallback — without it being a performance management exercise.
Request-to-Receipt Matching
When the PM uploads a receipt after an approved purchase request, BLT matches them automatically: vendor name from OCR vs. vendor on the request, amount proximity (within a configurable threshold, default 15%), and time window (within 7 days of approval). If the match is confident, the expense links and auto-approves. If ambiguous, the PM confirms manually.
Approved requests that haven't been matched to a receipt within 14 days appear as a "stale requests" alert on the manager dashboard. Either the purchase didn't happen (and the approved amount should be released back to the budget) or the receipt was never uploaded. Either way, it's a loose end that needs resolving.