Architecture, sizing and the first prototype · Shapes and sizing

Pick the shape

Choose the deployment shape for an accounts-payable workflow from who is waiting, what the output changes and what a wrong payment costs to reverse.

designeasyExercise · 4 min · 24 of 64

On this page

A finance team wants "an AI that handles supplier invoices", and the shape you pick decides whether the pilot pays the wrong supplier once in week 2.

The situation

A distributor's accounts-payable team receives about 4,000 supplier invoices a working day as PDF attachments to a shared mailbox, between 08:00 and 18:00. Sixty clerks code each invoice to a ledger account and a cost centre, match it to a purchase order, and queue it for payment. Payment runs happen once a day at 16:00. Coding takes a median of 3 minutes an invoice; matching takes another 2 when the purchase order exists and 15 when it does not, which is 1 invoice in 8. Invoices over 25,000 in local currency need a manager's approval before payment; those are about 3% of volume. A payment to the wrong account takes an average of 11 working days to recover and about a quarter are never recovered. Nobody outside the team waits on an individual invoice; suppliers chase by email when payment is late, which is after 30 days. The CFO has asked for "coding and matching automated, and payment released without a clerk touching it where it is safe".

The question

Choose the deployment shape (or shapes) for coding, matching and payment release, say where the person sits in each, and name what the pilot measures before any payment leaves without a clerk.

A strong answer · Rubric · Where answers go wrong

Write your answer first, then open

A strong answer

Three questions, applied to each step. Nobody is waiting on an invoice, so latency is free everywhere: the shape is never the retrieval-backed assistant. Coding and matching do not act; they produce a record a clerk reads at 16:00, and a wrong code is corrected in seconds by the clerk who sees it. That is batch classification: a run every hour over the mailbox, writing account, cost centre and matched PO to a results table. Volume is 4,000 a day, about 0.1 a second over the ten-hour day; at an assumed 8 s a call, under one in flight.

Payment release acts, and a wrong payment costs 11 days and a 25% chance of never coming back, so it is not reversible by any useful definition. That step is a human-in-the-loop queue: the model's draft (coded, matched, amount within the PO) sits in a queue and a clerk signs it before the 16:00 run. Signing 4,000 a day at perhaps 20 seconds each is about 22 clerk-hours, a ninth of the 200 hours the sixty clerks spend today on coding alone. The manager approval above 25,000 stays exactly as it is; the queue just routes those 120 invoices to a second signer.

"Released without a clerk" is a shape change to be earned per segment: after four weeks, if clerks sign the draft unchanged 99% of the time for invoices with a matched PO under 2,000, that segment moves to batch with a 1-in-20 clerk sample. The pilot measures the unchanged-signature rate per segment and the wrong-account rate, which must be zero. No agent with tools anywhere in this workflow, because a pay tool has no undo.

Rubric

applies the three questions (waiting, acts, reversible) to each step separately rather than to the workflow as a whole
puts coding and matching in batch and payment behind a human signature, with the reason stated in days-to-recover
shows the volume arithmetic for 4,000 a day and the clerk-hours the queue costs
keeps the existing manager approval for invoices over 25,000 rather than redesigning it
names the measured condition under which a segment moves from the queue to batch
says explicitly why an agent that can release payment is out

Where answers go wrong

"An agent with tools: it reads the invoice, matches it, and calls the payment API when confident." Loses because the action has no undo and the confidence score is not calibrated against this customer's invoices; the first wrong payment costs 11 days and the CFO's trust, and the pilot has no signature record to show what went wrong.

"A retrieval-backed assistant so clerks can ask about any invoice." Loses because nobody is waiting on an invoice; the assistant adds a latency budget the workflow does not need and leaves the clerks doing the same 3 minutes of coding, so the pilot has no number to report.

"Batch everything, including payment, with a daily exception report." Loses because the exception report arrives after the 16:00 run, when the wrong payment has already left; the person has to sit before the action, not after it.