Case study
Accounts payable automation case study: invoice processing across two ERPs for a wholesale distributor
ResultOne shared queue gives the AP team the invoice, purchase order and warehouse receipt together, with clear reasons for anything that needs review.
- Client
- A US wholesale distributor (anonymised)
- Industry
- Wholesale distribution
- Service
- Accounts payable automation: capture, reading, matching, approvals and posting
- Type
- Invoice processing across two ERPs and a warehouse system
- Status
- Delivered
We built an accounts payable automation workflow for a wholesale distributor operating across separate ERP systems. The system reads supplier invoices, checks them against purchase orders and warehouse receipts, and posts invoices that meet the agreed rules. The AP team handles exceptions and retains control of payment runs.
The starting point
The distributor had separate ERPs for its businesses and a warehouse management system holding the goods receipts. The AP team entered invoices, compared receipts outside the ERP and tracked exceptions in spreadsheets, leaving less time for the cases that needed their judgement. Freight allocation and suppliers serving both entities made matching more complicated.
What we delivered
We connected the shared mailbox, supplier submissions and warehouse scans to one processing queue. A document model extracts invoice headers and lines with field-level confidence scores. Code checks for duplicates, validates the supplier against the correct vendor master and performs a three-way match after allocating freight. Non-PO invoices receive proposed coding and go to the budget holder for approval.
Rollout and handover
We started with the invoice types and suppliers the AP team could validate most readily. During parallel processing, AP team members reviewed the proposed matches and recorded where their decisions differed. The rollout then extended to additional layouts, non-PO invoices and the other entity, with each posting path checked before it was enabled.
Where people remain in control
| Step or hold | Done by |
|---|---|
| Reading the invoice | A model, scoring its confidence in each field |
| Matching it to the order and the receipt | Rules, within the AP team's tolerances |
| A possible duplicate | An AP team member, who sees the earlier invoice beside it; the possible duplicate never posts automatically |
| Bank details that differ from the vendor master | Someone outside AP, who checks the change with the supplier by calling a number the distributor already had |
| A supplier with no vendor record | The distributor's own vendor set-up team |
| No purchase order, or one the ERP doesn't know | The requester, found from the order history |
| Price or quantity over tolerance | The buyer, who sees the invoice line next to the order line and the receipt |
| Goods not received yet | Parked and rechecked daily, then sent to the buyer after a wait the AP lead sets |
| A field read with low confidence | An AP team member, who confirms that field only |
| Spend over an approval limit | The approver named by the limits, with a separate person reviewing each requester's spend |
| The ERP rejecting a posting | Retried, then held with the error message, and the AP lead alerted |
| Paying suppliers | The AP team, in each ERP |
Project outcome
The project brought capture, matching, approvals and posting into a shared workflow across the two businesses. Each held invoice carries its reason and supporting evidence, so the AP team can review the specific issue instead of reconstructing the match. Payment decisions remain in the existing ERP process.
How performance is evaluated
| Measure | How it is measured | Comparison point |
|---|---|---|
| Straight-through rate on PO-backed invoices | Invoices posted without a person needing to open, edit or approve them, over all PO-backed invoices | Not recorded before the project, since every invoice is keyed |
| Touches per invoice | Every open, edit and approval, logged | The same measure before automation |
| Days from arrival to posting | Time stamps at capture and at posting | The same measure before automation |
| Cost per invoice | AP hours from the count plus the monthly run cost, over invoices posted | The same measure before automation |
| Invoices held, by rule | Each hold logged with its reason | Not recorded before the project |
| Disagreements in the parallel run | Each invoice a clerk decided differently, with the reason | The parallel run |
Technologies and tools
- A document-reading model
- Matching and hold rules in code
- Both ERPs' APIs
- The warehouse system's API
- A review queue for the AP team
- Email and Slack approvals
More case studies
All case studies- Case studyTicket triage, reply drafts and call summaries for a broadband providerTriage, call summaries, reply drafts and quality-review support were integrated into the help desk, with agents sending every customer reply.
- Case studyPreparing motor and property claim files for a regional insurerClaim information, policy details and supporting documents were assembled for adjusters, who retain authority over coverage, reserves and settlement.
Bring us the invoice workflow taking up your team's time
Tell us how invoices arrive, which ERP they post to and where your team needs the most support. An engineer replies within two business days with which steps can run automatically and which decisions should stay with your AP team.