Purchase order approver
A small system that takes purchase requests from wherever your team already sends them, checks each one against the budget and the spend limits you wrote down, approves the small routine ones, and puts everything else in front of a person with the numbers already gathered. It never spends money on its own, and it never approves anything above the line you set. Seven posts on the same system — one diagram at a time — with a cost breakdown and an engineering reference at the end.
- 01
A purchase order approver on AWS for a few dollars a month
The whole system on one page — an intake, a checker and a router, plus the rule that keeps it safe: it can approve small routine spend, and everything else waits for a person.
- 02
How a purchase request arrives
Three lanes feed one queue. Every request becomes the same five fields, the reader leaves blank what it cannot read confidently, and a fingerprint stops a resend becoming a second order.
- 03
How a purchase request gets checked
Four questions in a fixed order: does the budget line exist, is there room in it, is the vendor approved, and is this a repeat of something already committed. Every answer carries the number that produced it.
- 04
How an approval reaches the right person
The approver comes from the budget line, not an org chart. The message leads with the consequence — what is left after saying yes — and an unanswered request escalates on a schedule rather than dying quietly.
- 05
How the money gets committed
Reserve the money, then send the order. The ledger write is a conditional update that fails rather than overspends, and the purchase order is sent from a queue so a mail failure never leaves money reserved for nothing.
- 06
What the purchase order approver costs
A few dollars a month. One Bedrock read per request is the only line that grows; the queue, the table, the mail and the storage are rounding errors. Plus the three ways the bill could surprise you.
- 07
Engineering reference: the purchase order approver architecture
Same system, drawn purely for engineers. Service names, region, Lambda inventory, IAM scopes, the SES inbound rule set, the two DynamoDB schemas and the exact model id.
Frequently asked questions
- What is a purchase order approver?
- A small serverless system that receives purchase requests, reads them into a consistent shape, checks each one against the budget line it belongs to and the spend limits you wrote down, and either approves the routine ones or routes the rest to a person with the budget position already attached. It never spends money by itself.
- Does it approve spending on its own?
- Only below a line you set, and only when every check passes: the budget line exists, there is room in it, the vendor is known, and the request is not a duplicate. Anything over the line, anything with a missing field, and anything unusual goes to a human. If a check cannot be made, the answer is always to ask a person, never to guess.
- Where does the budget come from?
- A sheet you already keep. The system reads it, so changing a limit or adding a budget line is an edit in a spreadsheet, not a deploy. The sheet is the source of truth; the system never invents a line that is not in it.
- What stops the same request being approved twice?
- Every request gets a fingerprint built from the requester, the vendor, the amount and the day. The first write of that fingerprint wins; a second one is rejected by the database itself rather than by a check that can race. A resent email or a double-tapped form button lands on the same request, not a second one.
- What does it cost to run?
- A few dollars a month at small-business volume. There is nothing always-on: the cost is one model read per request plus fractions of a cent for the queue, the table and the mail. See part six for the breakdown and how it scales.