Accounts payable exceptions and cross-entity duplicate invoices
Brightwater Foods runs accounts payable for four US legal entities from a shared service center in Manila. Twenty-two clerks key about 9,200 vendor invoices a month into invoice journals. Stocked items are three-way matched; everything else is entered as a non-PO invoice. Thirty-four percent of invoices fail matching on the first pass. The AP manager sampled 300 failures and found three causes: the purchase unit of measure differs from the invoice unit (cases versus eaches), carriers add freight lines that are not on the purchase order, and the price tolerance is set to zero. Internal audit also found $210,000 of duplicate payments last year, each with the same vendor and invoice number, some of them in different legal entities. The vendor master holds 4,800 records, including about 60 apparent duplicates created by the Manila team. The CFO has funded invoice capture (OCR) and wants the exception rate below 10% within two quarters, with no duplicate payments.
1. Should the team implement OCR first or fix matching configuration first? Justify the order with reference to the symptoms.
Read the worked answer
Fix matching first. OCR only accelerates invoice entry; pointed at a matching setup that rejects a third of invoices, it produces exceptions faster and pushes clerks into the same manual workarounds, now with an extra tool to learn. The sampled causes are configuration problems, not data-capture problems:
- Unit of measure: the item must carry the purchasing unit properly, and the PO line and invoice line must convert through the item's unit conversion. If invoices arrive in cases and the PO is in eaches, either negotiate PO units to match the supplier's invoice unit or maintain the conversion so matching compares equal quantities, not equal numbers.
- Freight: carrier freight that never appears on the PO will always break line-level matching. Use charges codes on the purchase order or on the invoice, configured as a charge that is not required to match a PO line, rather than keying a free-text miscellaneous line.
- Tolerance of zero: a zero price tolerance rejects cent-level rounding. Set a percentage and amount tolerance at the vendor or vendor group level, with tighter tolerances on high-value vendors.
Then apply OCR to the clean population. Target measurement: exceptions by reason code, so you can prove the fix, not just the overall rate.
2. Duplicates were posted in different legal entities, so the in-entity duplicate check did not catch them. What control design would you propose?
Read the worked answer
The built-in duplicate invoice check compares vendor account and invoice number within the invoices in that legal entity, so a copy posted in another entity is invisible to it. The control has to be group-level:
- Vendor identity: create one vendor party per real-world supplier and separate vendor accounts per legal entity that inherit the party. This gives you a way to group all accounts that mean the same supplier. The 60 duplicate vendor records must be merged or blocked, otherwise even a group report fragments.
- Cross-entity detection: build a scheduled report or Power BI view over vendor invoice headers across all legal entities keyed on party plus invoice number plus invoice date, and block payment on hits until reviewed. Run it before the payment proposal, not after posting.
- Master data governance: workflow on bank account and vendor name changes, a reason code for new vendor creation, and a weekly duplicate vendor candidate report that the Manila team must clear.
Keep the standard in-entity check switched on as the first line. The judgement point: $210,000 was found by audit, so the control must be preventive at the payment stage and detective across entities, because posting-level prevention stops at the legal-entity boundary.
3. The CFO wants invoices paid faster as well as cleaner. Where can automation safely remove touches, and where should a human still decide?
Read the worked answer
Safe to automate, because the decision is deterministic and reversible:
- Invoice capture for non-PO invoices with confidence thresholds, routing low-confidence documents to a queue rather than forcing them through.
- Vendor invoice automation workflow with matching and totals checks, auto-posting only when match status is within tolerance and the duplicate check is clean.
- Totals matching for freight-only and subscription vendors that will never have a PO line; line matching for those is a design error, not a control.
Keep human decision on:
- Invoices above a value threshold or with a new vendor, changed bank details, or a match outside tolerance.
- Anything flagged as a possible duplicate across entities.
- Invoices with a unit-of-measure change or a new charges code, because posting them auto-teaches no one and hides a master data defect.
Measure straight-through processing rate by vendor segment, not overall, and report exception reasons weekly. A 10% target is only meaningful if the 90% that flows through is genuinely correct; track payment accuracy and vendor queries alongside it.