Case study 02 Budgeting workflow
A monthly budget request that builds itself from live balances
Every month, over-budget projects need funding requested from the right owners. I turned a manual, error-prone assembly job into a guided workflow that refuses to produce an incomplete request.
- My role
- Defined the rules, designed the workflow and output, tested and approved release
- Released
- September 28, 2026
- First real use
- The following month's request, completed and printed
- Built by
- AI implementation under my direction, with automated tests
The problem
A monthly funding request pulls together every project that has spent past its available balance, adds a safety margin, and shows each paying entity what it owes. Done by hand, three things go wrong:
- Stale numbers. Balances copied from somewhere else are out of date by the time the request is read.
- Compounding margins. A percentage contingency calculated on a total that already includes it quietly grows.
- Incomplete requests. A line without a paying entity or a truncated line on the printout leads to follow-up calls and delays.
The rules I defined
- Start from current balances. Every active project below $0 is suggested for the amount that brings it back to $0, with the time the balances were read.
- Contingency is of the lines only. It never counts itself, and it follows the chosen percentage.
- Allocate it fairly — to the cent. Split in proportion to each paying entity's lines, with any rounding cent going to the largest, so the parts always add up exactly — or have one entity pay it all.
- Refuse incomplete output. The one-page request can only be produced when every line has a purpose, an amount and a paying entity — and it never truncates text.
- A request, not a transaction. Producing it funds nothing and changes no balance.
- Its own permission. It can be granted to one person without giving them any other financial access.
Try it Interactive demo
Build a request
A recreation with a fictional company, projects and entities. Try producing the request before choosing paying entities, change the contingency, or switch to a single payer.
Monthly Budget Request
SYNTHETIC DATALines
Contingency
Current project balances
| Project | Available | Status |
|---|
Totals
What I did, and what AI did
I wrote the rules above from how the request is actually used — including the edge cases: a project with a positive balance, a contingency paid by one entity, the rounding cent, a paying entity name long enough to wrap. AI implemented and tested it; the release was then checked on the live system — including that a request with blank paying entities is refused — before the first real request was built.
Result
Released September 28 after its database change was applied and read back. The next month's request was completed and printed from it. Time saved per request hasn't been measured.
Lesson
The valuable part wasn't the arithmetic — it was deciding what the tool must refuse to do. Blocking an incomplete or misleading request is worth more than any amount of polish.
Evidence and attribution
Where each claim on this page comes from. "Record" means dated release records; "My report" is my own account, not independently measured; "Plan" is not done yet. Private records stay private — they're available to discuss in an interview.
| Claim | Source | Type |
|---|---|---|
| The six rules | Written design decisions for the feature | Record |
| Released September 28; checked live, including refusal of blank paying entities | Dated release records | Record |
| Next month's request completed and printed | My account | My report |
| Time saved per request | Not measured | Plan |