The workflow this pilot is for
Most operations teams have at least one job that is really a reconciliation. Orders in the commerce platform have to agree with what the warehouse shipped. Supplier confirmations have to agree with purchase orders. Carrier invoices have to agree with the rates and the deliveries that actually happened. Somebody exports two reports, lines them up in a spreadsheet, and spends the afternoon chasing the rows that do not match.
The matching is tedious. The exceptions are where the value is: a short shipment, a duplicated order, a supplier who changed a part number. Experienced staff know how to handle each one, but that knowledge is rarely written down. That is why “just automate it” tends to fail. The automated version handles the easy rows and silently mishandles the hard ones.
This pilot changes one reconciliation workflow so that AI does the sorting and the first pass at matching, and people keep control of every exception.
What the work involves
The process walk. I sit with the people who do the work and follow real records through it. The output is a one-page process map showing each source system, each export or re-keying step, each decision and each hand-off. Most teams find at least one step that exists only because two systems use different identifiers.
The exception catalogue. From a sample of recent cycles, we list every kind of exception and how it was resolved. This becomes the backbone of the runbook.
The reviewed matching step. Using the tools you already approve, I build a step that proposes matches between the two sources, flags the rows it cannot match, and assigns each flagged row to an exception category with the evidence it used. A member of staff reviews every proposal. Nothing is written back to a system of record during the pilot.
Weekly adjustment. Reviewer corrections are the training signal. Each week we look at what reviewers changed and tighten the rules, the prompts or the reference data.
I have built AI agents for supply-chain operations, so I know where these workflows usually break: identifiers that drift, partial deliveries, and timing differences that look like errors.
The signature deliverable
You end with a process map, a reviewed reconciliation pilot and an exception-handling runbook. Illustrative example of a runbook extract:
| Exception category | Typical evidence | Owner | Closes when |
|---|---|---|---|
| Quantity short-shipped | Dispatch note quantity below order line | Fulfilment lead | Back-order raised or customer credited |
| Duplicate order | Same customer, items and value within 24 hours | Customer operations | Duplicate cancelled and logged |
| Unknown supplier part number | No match in item master | Purchasing | Cross-reference added to master data |
| Low-confidence match | Proposed match with conflicting dates or values | Reviewer on shift | Accepted, corrected or escalated |
Illustrative example. The categories show the format, not results from a client.
How acceptance is judged
Before the pilot starts, we baseline the workflow using the same measures we will use at the end:
- elapsed time for one reconciliation cycle
- number of exceptions and median time to resolve them
- wrong-match rate: proposed or manual matches later found to be wrong
- reviewer acceptance rate: how often staff accept the AI proposal unchanged
The internal owner signs off the pilot against those measures. The adoption measure is plain: is the team running the new workflow for real cycles without being prompted? A pilot can conclude that the workflow should be expanded, revised or stopped. Each of those is a legitimate result.
Ownership and handover
The workflow, the runbook and the review queue belong to your operations owner from day one. Staff who ran the pilot are coached to adjust the matching rules themselves. Before I step back, the team runs at least one complete cycle without me, and the runbook is updated from what they find.
When this is the wrong page
If the workflow is financial close, management reporting or ledger reconciliation, the review and sign-off requirements are different. Use AI enablement for finance teams. If the work is about CRM data and account research, see AI enablement for revenue operations. If you already know the integration you want built and maintained, go to AI workflow automation and systems integration. To measure adoption across several teams rather than change one workflow, start with the AI adoption measurement worksheet.