br8n · Fictional worked example
Should AI help with invoice intake?
This teaching example illustrates how a team might reach a decision. The company, people and cases are fictional. No customer implementation or successful test result is being claimed.
Start with one job.
An accounts-payable coordinator checks supplier invoices against purchase orders and prepares an approval packet. Ordinary case: one readable invoice with a matching order. Awkward case: a duplicate invoice, changed bank details or a document whose totals are unclear.
Compare the alternatives.
First repair the intake checklist and try the accounting product’s existing matching and duplicate checks. Consider an integration when the obstacle is moving records between systems. Investigate AI only for extracting or summarizing varied documents where those simpler options leave a meaningful gap.
Keep the boundary small.
A proposed assistant may read a restricted test folder and purchase-order records, extract draft fields and flag uncertainty. It cannot approve invoices, change supplier details, send messages or make payments. The coordinator compares every draft with the source; the finance owner retains approval.
Name the evidence and permissions.
The finance owner is responsible for invoice and order records. The technical lead must verify the exact product plan, access controls, retention terms and audit trail before using real documents. Start with invented test documents. Credentials and full invoice contents do not belong in a shared assessment worksheet.
Write tests someone can observe.
| Case | Expected behavior | Status |
|---|---|---|
| Readable invoice | Draft fields match the document; the reviewer can locate each source value. | Proposed; not run |
| Unclear amount | Flag uncertainty and ask for review; do not guess the total. | Proposed; not run |
| Duplicate or changed bank details | Hold the packet for the existing finance verification process. | Proposed; not run |
| Instruction inside an invoice | Treat it as document content; do not change permissions or perform actions. | Proposed; not run |
| Service unavailable | The coordinator can complete the job using the checklist and original records. | Proposed; not run |
Rehearse with the person doing the work.
Ask the coordinator to handle an ordinary, unclear and failed case before showing a suggested answer. Observe whether they can check a source, identify uncertainty, escalate correctly and continue manually. Record their concerns and the help they need. A written lesson is not evidence that someone learned the action.
Count the full effort.
Measure accepted packets alongside setup, checking, correction, training, support, subscription and exit effort. All savings and costs remain unknown until measured. If checking takes more effort than the current process, keep that negative result visible.
The provisional decision: configure first.
Try the existing accounting features and repaired checklist before building an AI pilot. Hold the AI idea until access and review controls are verified. Narrow it to draft extraction if the remaining problem warrants a test. Stop if reviewers cannot reliably detect errors or the full effort offers no useful benefit.
Next named action: the finance owner and coordinator run the ordinary and awkward cases through the current system; the technical lead records what its exact plan supports. No test has been executed in this example.
Want help working through your own situation? Talk with Michael.