Why the live run is not the demo
A demo works because someone picks the cases and sits with it, and a live system fails on whatever arrives with nobody watching. The gap is exceptions, meaning cases a person must still finish. The other gaps are blocked access and no named owner.
You can test that on your own desk this week. If the demo uses last month's clean files, it is still a demo. If the live queue still needs a clerk after four, you already know the gap.
The same payable week, twice
This scene is illustrative. It is how the work runs today, not evidence that anyone delivered this.
Monday, accounts payable opens the invoice inbox. A clerk matches each bill to a purchase order and a goods receipt. Short pays wait for the buyer. Duplicate vendor numbers wait for master data. The leasing manager's rider sits in a side folder. It is not a standard invoice. The transporter's evening spreadsheet arrives after four. It has extra lines and no purchase order. Friday, the holds still sit with the controller. IT does not own the aging.
This scene is illustrative. It is the same desk with a system in the path.
The system reads invoices as they land. Clean bills match to the purchase order and the goods receipt. Then the rider arrives. Then the spreadsheet arrives. A vendor sends a credit with no original invoice number. Those cases join the exception queue. The queue grows. The clerk still watches it. No other owner is named. The connection to your ERP can read a bill. It cannot post a hold. The buyer never sees the short pay. Aging still sits with the controller.
That is why the demo looks done. The demo never includes the rider, the spreadsheet, or the credit.
Chosen inputs, a person steering
In a demo, someone chooses which files to show. They skip the rider. They skip the evening spreadsheet. They skip the credit with no number. A person sits next to the screen. When the match fails, that person clicks. When the screen asks a question, that person answers. The room is quiet. The cases are known. The work looks finished because the hard cases are never in the room.
A live system does not get that courtesy. Mail arrives as it arrives. The front desk at nine in the evening still forwards a scan. The clerk is on another hold. Nobody is steering. Whatever the system cannot finish becomes an exception and waits. If the wait has no owner, it waits until a customer or a vendor calls.
Access the demo never needed
A demo often runs on a copy of last month's files. A person already pulled them. The live system needs a live connection to your records. Read is not write. Match is not post. A hold that never posts is still an open bill on the aging. A match that cannot reach the buyer is still a clerk's job.
Security and IT will ask what the system can see and what it can change. You do not control that sign-off. You do control which fields the desk actually uses. If the system cannot touch those fields, the clerk is still in the loop. The demo hides that because a person is the connection.
For how a proof, a pilot, and a live run test different things, see the engineering behind this.
An owner, or the queue is yours forever
Someone has to take the cases the system cannot finish. Name the role, not a shared inbox. The leasing manager owns riders. The buyer owns short pays. The controller owns anything still open on Friday. If you cannot name those three, the clerk remains the owner by default. That is not a live system. That is a demo with extra steps.
An owner also decides what "done" means. Posted. On hold with a reason. Sent back to the vendor. Those are acts in your records. A screen that only suggests a match is still the clerk's job.
What this does not solve
This does not get you IT, security, or purchasing sign-off. It does not fix a vendor file that is already wrong. It does not remove judgement from a lease rider that needs a person. If fixed rules can do the job reliably, compare ordinary automation with AI before choosing the approach. Use the full cost of implementation, review and maintenance.
It will demand time from the people who run the desk. You will sit through a week of real mail, not a chosen pack. You will say which holds may post and which must wait. You will name who owns the leftovers. You will keep the clerk on the exceptions until that list is short enough to staff.
A meeting you can run without an engineer
Use this list in a half hour with the desk lead. Write answers on paper. Do not wait for a workshop.
- Which three documents landed last week that a new clerk would have to ask about?
- Who, by role, owns each of those today when they stall?
- Can the live system read the purchase order, the goods receipt, and the vendor file, or only a copy?
- Can it post a hold, or only suggest one?
- After four, who watches the queue if the clerk is gone?
- What does "done" mean in your records for a match, a short pay, and a reject?
- If the system is wrong, who catches it before the vendor is paid?
Resolve gaps in permissions, exception ownership, approval and recovery before live use. A total question count cannot compensate for a missing control.