In this note
Someone asks you to build an agent for accounts payable. The team spends too much time chasing missing information, checking invoices, and sending exceptions back for approval. Everyone agrees the process is painful.
I’d want to see a few cases before promising a build. Where does the time go? Which invoices could the proposed system handle? Who would check its work? A process can annoy people all week and still offer very little that a model can usefully change.
Let’s work through a hypothetical invoice forecast to see how I’d assess the investment. Every number below is an assumption for teaching, not a customer result.
Follow a case from request to result
Sit with the person doing the work and trace recent cases through the systems they use. Include an ordinary case, a difficult one, and something that came back for correction. Ask to see the spreadsheet or mailbox where the process continues after the official diagram ends.
Separate hands-on work from waiting and rework. If an invoice sits for three days awaiting approval, drafting a response ten seconds faster may barely change when it gets paid. If the team repeatedly asks for the same missing field, changing the submission form might remove the chase altogether.
Start with 10–15 recent cases you have permission to inspect. Talk to someone who submits the work and someone who receives it. Use that small sample to find questions, rather than estimate an error rate for the whole queue. Keep what you saw separate from what people told you.
Count work the system could finish correctly
A request to “automate invoices” is too broad to price. Start with exceptions covered by a known policy, where the team can find the invoice and approval evidence. Leave disputed invoices and missing records in the existing queue. Count only the cases the proposed system would be allowed and able to handle.
Agree what finished means. In this forecast, a reviewer must approve the recommendation and a ledger check must confirm the recorded result. A drafted recommendation gets us only partway there. The forecast assumes that full path; anyone later building it would still need permission and release approval to change the ledger.
The team may also keep using email instead of the new workflow. In the forecast below, only 300 of 500 eligible cases reach it, and some fail review. Price the work people will actually use, not the whole queue.
Work through a small forecast
| Planning input | Assumption |
|---|---|
| Eligible exceptions each month | 500 |
| Eligible cases that reach the workflow | 60% |
| Reached cases independently accepted | 80% |
| Reviewer time released per accepted case (assumed net) | 6 minutes |
| Loaded reviewer cost | $55 an hour |
| Allocated delivery, assurance, support, and operation | $850 a month |
| Variable model, tool, and compute cost | $0.50 per reached case |
Of 500 eligible cases, 300 reach the workflow. At an 80% acceptance rate, 240 produce an independently accepted result. Six minutes released on each of those cases gives 24 hours a month.
- Accepted results
- 500 × 60% × 80%240
- Potential time value
- 240 × 6/60 × $55$1,320
- Modeled service cost
- $850 + 300 × $0.50$1,000
- Conditional balance
- $1,320 − $1,000$320
That is about $4.17 per accepted result: $1,000 divided by 240. The bill includes all 300 cases the system handled, including the ones that failed review. Counting only successful model calls would make the service look cheaper than it is.
Check the two assumptions most likely to hide work. Does the six-minute gain already subtract the new review and correction time? Does the $850 allocation cover delivery, integration, training, support, maintenance, and failures? Include costs paid by other teams, but count each cost only once.
Try to erase the margin
A $320 monthly balance leaves little room for error. Before building, change one assumption at a time. Keep the other inputs fixed so you can see which uncertainty deserves attention.
| Change one assumption | Conditional monthly balance |
|---|---|
| Time released falls from 6 to 4 minutes | −$120 |
| Only 40% of eligible cases reach the workflow | −$70 |
| Fixed monthly cost rises from $850 to $1,200 | −$30 |
None of those changes requires a spectacular model failure. Review can take longer than expected. People can keep using email. Support can cost more. The next useful test might be a timed review session with operators, rather than another prompt experiment.
Price a smaller repair too. Fixing a submission field or removing duplicate entry may save enough time without a model. Keep required approvals unless the person responsible for them approves a change.
Find out where the released time goes
Even if all 24 hours are released, the company may spend the same amount on payroll next month. Multiplying hours by a loaded salary rate gives a planning value for capacity. It does not establish a reduction in expenditure.
Ask the owner where the 24 hours would go. Is there a backlog customers are waiting on? Could overtime or contractor spending fall? Is there more work the team could take on? If nobody has a use yet, report the hours and what they cost to free up. Don’t call them savings.
Do not count the same hour as both salary savings and extra output. When testing the change, compare similar work over a declared period and record other changes in demand, staffing, or policy. A better month can have more than one cause. A short pilot also does not establish a year of realized benefit.
Choose the next test before committing to a build
I’d time a review session before funding this build. I’d also check why people might keep using email and whether fixing the input form would be cheaper. With only $320 of room in the forecast, those questions can change the decision.
The owner also needs to confirm that the team may use the data, can reject incorrect results, and can support the service. If any of those is missing, make it a condition for continuing. A positive spreadsheet total cannot settle it.
Bring the forecast and its weakest assumption to the next meeting. Write down which cases you counted, what finished means, and who will test the time gain. Use the worksheet to keep the costs and unknowns together, with a date for deciding whether to continue.