Where financial process automation breaks

What financial process automation covers

Financial process automation means software does the repetitive steps in finance work, such as reading invoices, matching them to orders, posting entries and chasing approvals, while people keep the decisions that carry risk.

It breaks at the edges. The routine middle of a finance process automates easily, and the cost hides in the remainder.

In practice it shows up as accounts payable automation, order-to-cash, bank reconciliation and automated financial reporting. Vendors use finance process automation and finance workflow automation interchangeably, and the pages that rank for those terms mostly list benefits. That works as a definition.

What those pages skip is the other half. A finance process that is mostly automatable usually hides its cost in the part that is not, and the pattern in finance work is consistent. The rest of this post is about those edges.

Where financial process automation breaks

It breaks at the edges: documents with no readable text, exceptions nobody has sorted, changed bank details, and reports built on figures that disagree between systems. Each one fails quietly, which is what makes it expensive.

A loud failure gets fixed the same day. A quiet one shows up weeks later as a duplicate payment, a missed discount or a close that runs late.

When we look at a finance workflow, the first question is what happens to the item the automation cannot handle. If the answer is that it lands in a queue nobody owns, the dashboard will look healthy while the backlog grows underneath it.

The sections below cover the failures we see most often. The numbers come from our published accounts payable reference build, covered in full in the case study with the arithmetic shown.

Scanned documents with no text

In our accounts payable reference build, 41% of invoice volume arrived as scanned images with no text layer. Text extraction returns nothing on those, and a pipeline that reads an empty result as "no data found" lets the invoice through with blank fields.

Vision-capable models can read the page directly, and Anthropic's PDF support documentation describes how each page is handled as both text and image. Use that only where you need it. If a text layer exists, read it, because paying a model to look at a picture of text you already have is waste.

Document AI work is largely this decision, made per document, plus checking extraction accuracy against invoices someone has already labelled by hand. Make the extractor report a failure whenever a required field comes back empty.

Sort exceptions before people work them

In that same build, 31% of 2,400 monthly invoices hit an exception, which is 744 a month. The team worked them in whatever order the inbox showed. The diagnostic found that 68% were the same nine types, each resolved the same way every time.

That is the case for automating them, and also the trap. Resolving the routine types is easy. The failure appears when the system clears what it can and drops the rest into one pile with no context.

A reviewer opening an invoice cold takes 22 minutes on a genuine exception, against 7.5 for a routine one. Hand the judgment cases over with the invoice, the purchase order, the supplier history and the specific conflict already assembled, so the person starts at the decision.

Payment fraud from changed bank details

Payment fraud often enters through supplier master data. The FBI's Internet Crime Complaint Center recorded business email compromise losses of more than $2.9 billion in 2023, and a polite request to update bank details is a standard version of it.

An automated flow that accepts the new account because the email looked right will pay the wrong party faster than a person would. Speed raises the stakes of every bad input.

In our build this is the one rule no confidence score can override: payment is blocked, and a person phones the supplier on a number already on file. Put that check before the money moves, and do not let anyone tune it away to hit a throughput target. A rule like this costs a few minutes per flagged invoice and prevents the one error you cannot recover from.

Agree which system owns each figure in financial reporting

Automated financial reporting inherits every upstream problem. If the ledger holds a duplicate payment, or two systems disagree on what was shipped, the report is generated faster and is still wrong.

Reporting automation tends to fail in the join between systems, where a customer has two IDs or a currency is converted on different dates. Before you automate the report, write down which system owns each figure and what happens when two sources differ.

That is data engineering work, and it is dull. It is also the reason a month-end pack can be trusted by the people who sign it, rather than re-checked by hand every close. Expect this step to take longer than the automation itself, and budget the time for it.

What broke in our accounts payable build

The build is a reference build we publish, described in full in our accounts payable automation case study, with the arithmetic shown. It is modelled on a professional services company with 310 employees, a four-person AP team, QuickBooks and Bill.com. The figures below come from that case study, not from a named client engagement.

Before the build, the process looked like this:

• Month-end close took eleven working days, because 180 to 240 unresolved exceptions were carried into it every month.
• Early-payment discounts were captured on 34% of eligible invoices. Nobody had chosen to skip them: the invoices cleared approval after the window shut.
• Two duplicate payments totalling $19k had gone out in twelve months and were recovered five months later.
• 90 recurring vendors invoiced with no purchase order at all, a procurement problem that AP had been absorbing quietly.

The team was busy and competent, and the process still lost money every month. If your own numbers look like these, a workflow audit is the fastest way to find where yours leak.

What we changed in that build

The build used five stages, and only two involve a model: a vision call on image-only documents and one classification call. The three-way match, the duplicate check and the discount arithmetic are plain code.

Accounting should not be probabilistic. A five-day diagnostic inside the AP function came first, followed by a seven-week build.

Approved invoices are ranked by discount deadline rather than inbox order. Matching runs against the purchase order and goods receipt in QuickBooks, and the duplicate check looks back 24 months before any payment is released.

Close fell to six days and discount capture rose to 81%. We did not automate the no-PO invoices. The system produced a report naming the 90 vendors, and procurement closed 61 of them at source, which fixed the cause where automating the symptom would only have hidden it.

How the failure points compare

Most finance automation failures share one shape: an input the system should have refused arrives, and nothing flags it. Each failure point below is followed by what it looks like in a live process and what to do about it.

• Scanned or image-only documents. Looks like blank fields with no error. Fail loudly on empty required fields, and use vision only where there is no text layer.
• Unsorted exceptions. Looks like a backlog carried into close. Auto-resolve the recurring types and route the rest with context attached.
• Changed bank details. Looks like a payment to the wrong account. Apply a hard stop and a call-back on a number already on file.
• Late approvals. Looks like missed discount windows. Rank payments by deadline, not arrival order.
• Unreconciled source systems. Looks like reports that look right and are wrong. Name an owner for each figure before automating the report.

How to test before you trust it

Build a labelled set of real cases before go-live and measure the system against it every week. Label the reason for each answer as well as the answer, so you can tell a lucky pass from a sound one.

For the AP build, the AP lead labelled 300 invoices, 120 of them exceptions. The results, shown in the case study:

• Exception classification moved from 84.0% in week one to 96.8% in week five.
• The share of exceptions sent to a human fell from 38% to 11%.
• The confidence floor for auto-resolution was set at 0.92.

That floor is higher than we would set for a lower-stakes workflow, because a wrong decision here is money that has already left the bank.

Constrain what the model can return. OpenAI's structured outputs guide shows how to force a fixed schema, which stops free-text answers reaching your ledger. The NIST AI Risk Management Framework is a useful checklist for what to measure and who owns it.

Should you build financial process automation in-house or bring in a partner?

Build in-house if you have engineers who know your ledger and time to maintain the pipeline. Bring in a partner when the workflow crosses several systems, or nobody on your side has done document extraction on messy invoices.

Our engineering is out of Mohali, with a Canadian office in Markham, Ontario, and we serve clients across the US, UK and Canada.

For finance work we usually begin with a diagnostic rather than a build. In the reference build, the nine recurring exception types and the 90 vendors without purchase orders turned up while we watched the process run, before any code existed. Our AI workflow automation service starts the same way.

If you have a finance process that mostly works and occasionally pays the wrong person, book a workflow audit and we will map where it breaks. If you would rather describe it first, use the contact form.

Whatever you decide, ask the question we ask first: what happens to the invoice the automation cannot read?