Invoice review behavior experiment
The request
Prepare clean invoices for approval
An accounts-payable product reads an incoming invoice, matches the supplier and purchase order, extracts line items, and prepares coding for a reviewer.
The product question is larger than extraction accuracy. It must separate exact rules from interpretation, respect company policy, preserve provenance, and stop before approval, posting, or payment.
Failed first version
A plausible row is presented as a clean invoice
The first version fills every field and routes the invoice as ready. It fails when two records repeat one stale error, when supplier identity conflicts with the purchase order, or when changed bank details cross a company policy boundary. Plausibility is not provenance. Confidence is not authorization.
Interactive decision
Same queue. Different system posture.
Change the invoice condition. The interface stays familiar; the behavior changes because evidence, policy, authority, and consequence are different.
The supplier, legal entity, purchase order, totals, and receipt agree. The user is allowed to review this entity.
Prepare for review
Prepare the coding as a draft, link every value to its source, and leave approval and posting to the authorized reviewer.
Revised design
The behavior spec separates five decisions
- Exact rules: totals, currency, duplicate detection, legal-entity permission, and workflow state stay deterministic and independently testable.
- Interpretation: coding and likely policy exceptions remain proposals tied to source evidence.
- Authorization: the system may prepare a review. It may not approve, post, schedule payment, or alter supplier details.
- Visibility: facts, inferences, rule matches, missing evidence, and policy conflicts have distinct labels.
- Recovery: preserve the original, allow field-level correction, and distinguish cancellation from compensation after an external action.
Product judgment made inspectable
The interface is deliberately modest. The evidence is the system model: one feature request reframed as explicit choices about rules, evidence, permission, action, visibility, and recovery.
Professional conversation
Bring a behavior problem, not a polished brief
If this is the level at which your product needs design attention, write to Joost with the workflow or decision you are trying to make legible.