CASE STUDY · INTELLIGENT DOCUMENT PROCESSING (IDP)
Processing 50,000 invoices a month with minimal manual entry.
- 78%78% of invoices processed straight through
- 70%Keying time down about 70%
01 · PROJECT OVERVIEW
The client and the brief.
An anonymised mid-market B2B services company. Name withheld under confidentiality.
Invoice capture, extraction, matching and ERP posting. The system handles around 50,000 invoices a month. Clean invoices flow through to the ERP without a person touching them. The rest go to a review queue with the reason for each flag.
- 1About 16 hours a week of keying, with frequent errors.
- 2Invoices came from many suppliers in different layouts, and each had to be matched to a purchase order before payment.
- 3Mistakes in amounts and references caused payment queries, and the finance team spent more time chasing than checking.
- 4Volume was high enough that the problem would only grow.
02 · WHAT WENT WRONG
What went wrong, and how we fixed it.
Every engagement hits problems. These were the ones that mattered here, and what we changed so they did not come back.
- PROBLEM 01In shadow mode, matching flagged a large share of invoices as mismatches because suppliers quoted purchase order references in several informal ways, with prefixes, spaces and typos
The model read them correctly. The matching logic was too strict. We added normalisation for references and a fuzzy lookup that proposes the likely purchase order for a reviewer to confirm.
- PROBLEM 02Exceptions dropped, and reviewers got a faster screen to work in
03 · THE PROCESS
How we ran it.
- 01Weeks 1 to 2
We analysed a sample of invoices by supplier and layout, and mapped how the ERP expected data, including tax and coding fields.
- 02Weeks 3 to 6
Capture, extraction and matching were built and measured against the sample, supplier group by supplier group.
- 03Weeks 7 to 9
Shadow mode. The system produced postings without writing them, and finance compared them with manual entries each day.
- 04Go-live
Phased by supplier group, with a daily check in the first weeks and then a weekly review of exceptions.
04 · RESULTS
What changed.
Measured against the way the work ran before the engagement began.
- NOW 01
Finance reviews exceptions and approves, instead of keying.
- NOW 02
Straight-through rate is a number the team watches, with reasons for each miss.
- NOW 03
Supplier onboarding includes a check that new layouts will read cleanly.
- NOW 04
Payment queries caused by keying errors are a small part of the week.
- 78%
78% of invoices processed straight through
Exceptions routed to a review queue
- 70%
Keying time down about 70%
05 · WHAT WE BUILT
How it works.
- Email and portal capture feed a queue.Each invoice is classified, and non-invoice documents such as statements and credit notes are set aside or routed separately.
- Header fields and line items are extracted separately, because tables fail in different ways from single fields.
- Matching compares supplier, purchase order, amounts and quantities, with tolerances agreed with finance.
- Duplicate invoice checks use supplier, number, date and amount together.
- The ERP posting step is idempotent and writes an audit trail linking the posting to the original file.
- A dashboard tracks straight-through rate, exception reasons and reviewer time.
- Monitoring and controls
- Three controls mattered most in production. First, a hard stop on posting if the ERP connection is degraded, so documents queue safely instead of failing halfway. Second, a daily reconciliation between invoices received, invoices posted and invoices waiting in review, so nothing goes missing without someone noticing. Third, a weekly sample check where a finance lead re-keys a handful of straight-through invoices by hand and compares them with what was posted. That check is deliberately low-tech. It tells the team whether the numbers on the dashboard can be trusted.
06 · QUICK ANSWERS
The short version.
- What problem did the client have?
- About 16 hours a week of keying, with frequent errors. Invoices came from many suppliers in different layouts, and each had to be matched to a purchase order before payment. Mistakes in amounts and references caused payment queries, and the finance team spent more time chasing than checking. Volume was high enough that the problem would only grow.
- What did Brandsmashers build?
- Invoice capture, extraction, matching and ERP posting. The system handles around 50,000 invoices a month. Clean invoices flow through to the ERP without a person touching them. The rest go to a review queue with the reason for each flag.
- What were the results?
- 78% of invoices processed straight through; exceptions routed to a review queue; keying time down about 70%.
YOUR TURN
Have a similar requirement?
Tell us what is stuck. We will come back with a plan and matched, pre-vetted engineers.
