.png)
But when we sit down with a finance team, the interesting questions are rarely about whether the technology can perform these tasks. They are about the exceptions, the financial controls, and governance, the people who remain responsible and whether the numbers justify the investment.
Here is what we have learned from deploying and operating Intelligent Digital Workers (IDWs) for our clients.
1. What happens to the invoices that do not match?
An unmatched invoice is not necessarily an AI error. What matters is whether the IDW identifies the mismatch and follows the agreed rules.
For one of our retail clients, three-way matching is very specific. The purchase order, invoice and goods receiving note must match for each pair of shoes, including quantity, brand, style, colour and size.
We give the Intelligent Digital Worker (IDW) precise matching rules. If something does not match, it cannot simply assume the documents are correct.
Depending on the client's instructions, the IDW escalates the exception to a designated person in purchasing or accounts payable. In some cases, it can contact the vendor directly. When a corrected invoice, PO or goods receiving note arrives, it can perform the matching again.
This is also why we agree on Key Performance Indicators (KPIs) before go-live. An invoice successfully matched and posted is not the same as an invoice correctly identified and escalated. Both may be handled correctly, but they must be reported separately. We also distinguish an error in the IDW's logic from a new business requirement it was never instructed to handle.
One retail client took this discussion further.
The client examined a year's historical invoice discrepancies, including differences in the $100 to $200 range. They looked at the number of exceptions, the time employees spent following up with vendors and the financial exposure involved.
The question was simple: Are we spending more money chasing a small discrepancy than the amount we are trying to recover?
The client has evaluated using a defined dollar tolerance, with an upper limit on financial exposure, for certain mismatches. This has not yet been implemented. But the exercise itself was valuable. It showed how historical data can help determine which exceptions really need human intervention.
The objective is not to ignore discrepancies. It is to establish sensible, approved rules for handling them.
For a related example of invoice validation and exception escalation, see HachiAI's accounts payable automation case study.
Explore Procure-to-Pay.
2. What does the first year after going live look like?
Operate, govern, optimize and expand.
In our experience, the first year is much like any other enterprise technology implementation. The client and HachiAI are learning how the new operation works in practice.
Initially, clients often want a person to review every transaction before the IDW posts it. As confidence builds, they move towards sample reviews and focus more on exceptions.
We also monitor performance using built-in checks, exception reports and sample testing. When something goes wrong, we investigate the cause. Was the original rule incorrect? Did the IDW apply it incorrectly? Has the vendor changed its invoice format? Or has the business introduced a new requirement?
We then make the necessary changes under agreed controls.
Over time, we onboard additional vendors, particularly those with high invoice volumes. The client also starts identifying other activities the IDW could handle.
We agree on dashboards and share them weekly or monthly. They show the volume processed, accuracy, exceptions, trends and available capacity. Both teams can see what is working and where improvements are needed.
The important point is that the work does not stop at deployment. It becomes an ongoing operation, with responsibilities on both sides.
We discussed this broader issue in AI Isn't Software You Deploy. It's an Operation You Run
3. Should an AI worker ever release a payment?
Yes, provided the client has authorized it and all the required controls are in place. But it is not where our clients have chosen to start.
So far, our clients have preferred the IDW to prepare payments and leave the final release to an authorized person.
I think that is a reasonable starting point. The IDW can check the supporting documents, validate amounts, identify duplicates and prepare the transaction. A person then approves its release.
Could the IDW release payments itself? Yes, where the client is comfortable delegating that authority.
However, the rules must be clear and deterministic. Payment limits, vendor details, bank account changes, approval authority and other required checks must be defined in advance. The IDW should not use open-ended AI judgment to decide whether money can leave the company.
If a condition is not satisfied, the payment should be stopped and escalated. The transaction also needs an audit trail.
This is particularly important when a payment is difficult or impossible to reverse.
The decision is ultimately the client's. AI can perform the work, but the organization must decide what authority it is prepared to delegate.
Related reading: Your AI policy isn't governing anything.
4. Which decisions stay with people in order-to-cash (O2C)?
Routine processing can be automated. Commercial judgment is a different matter.
For a leading digital freight forwarder in Latin America, our IDW retrieves overdue invoices from NetSuite, sends payment reminders, categorizes customer responses and processes payment slips.
It extracts the invoice number, customer name, amount and currency, validates the information against cashflow records and updates NetSuite when the required checks are satisfied. Payment reminders stop once payment is posted.
But consider a strategic customer who is temporarily short of cash and asks for more time. Should the company extend the payment deadline?
That is a commercial decision.
The same applies to pricing disputes, short payments, negotiated rebates, discretionary allowances, payment plans and bad-debt write-offs. These situations require investigation, judgment and appropriate approval.
The IDW can gather the facts, prepare the information and escalate the matter. People decide what the company is prepared to accept.
This distinction matters. We are not trying to automate every judgment. We are trying to remove the routine work so people have more time for the decisions that need them.
Our LATAM freight forwarder case study shows how this works in an actual accounts receivable operation.
Explore Order-to-Cash.
5. How do you measure the return on an AI worker in accounts payable?
Start with the baseline and let the data speak for itself.
Before deployment, we agree on the number of vendors, expected annual invoice volume and the time people currently spend processing invoices.
After go-live, our dashboards show the actual number of invoices processed, including month-to-date, year-to-date and cumulative volumes. We also report accuracy, exceptions, processing trends, peak volumes and available IDW capacity.
For estimating time saved, we multiply the number of invoices processed by the estimated manual processing time per invoice. We then make an allowance for the human oversight that remains, which can be 10% or more depending on the client and the stage of implementation.
We compare the actual results against the KPIs agreed before deployment and provide clients with the data to validate the performance. They can use our ROI tool to assess the financial return and decide how best to use the capacity released, based on their own priorities.
We let the data speak for itself.
For a broader discussion, see You Can Finally Calculate AI's ROI, Because You're Comparing It to a Role, Not a Feature.
What have these deployments taught us?
The real work in finance automation is not just reading an invoice or posting a transaction. It is agreeing on the business rules, deciding what happens when those rules are not met and measuring whether the operation is delivering the expected results.
Some decisions belong with the IDW. Others should remain with people. That boundary should be agreed before deployment and reviewed as the business changes.
At HachiAI, we have learned that the best results come when the client and our operations team work together, agree on the KPIs and keep improving the IDW after go-live.
The goal is not to achieve automation at any cost. It is to reduce unnecessary manual work, maintain financial controls and make the operation more efficient.
About the author
