Every AP automation pitch quotes a touchless rate against the invoices that work. The number that actually decides whether a team trusts the system is the one nobody quotes: what happens to the invoices that don't.
A meaningful share of real-world invoices — anywhere from 10% to 30%, depending on supplier mix and document quality — arrive where OCR cannot confidently identify the supplier from the printed name. Faded scans, logos rendered as images instead of text, trading names that don't match the registered entity, multi-page documents where the name sits on a cover sheet, foreign-language letterheads. The extraction isn't wrong exactly — it's uncertain. And what a pipeline does with that uncertainty determines whether automation feels like a force multiplier or a leaky bucket.
The failure mode: uncertainty becomes manual triage
The lazy answer is to route every supplier-uncertain invoice to a human. It's defensible — better than guessing — but it quietly defeats the purpose. If a fifth of your volume drops into a manual queue, your real automation rate is the headline number minus that fifth, and the team's lived experience is "I still have to deal with a big pile every morning."
Worse, manual triage on these is genuinely tedious. A human opens the invoice, reads the name, searches the vendor master, and resolves what the system could have resolved if it had a second way to identify the supplier. That's not judgement work — it's lookup work the pipeline should have done. The opportunity isn't to accept the manual pile as inevitable; it's to recover most of it deterministically before a human ever sees it.
A second, harder identity: the tax or registration number
The key insight is that the supplier name is only one identifier on the invoice, and it's the least reliable one. Most invoices also carry a government-issued business identifier — a tax registration or company number that exists precisely to identify a legal entity unambiguously:
- An ABN in Australia
- a VAT number in the UK and EU
- an EIN or TIN in the US
- equivalent registration numbers in most jurisdictions
Unlike a name, these are structured, fixed-length keys that often carry their own validation rules (checksums, format patterns). That gives a deterministic fallback two powerful properties. First, you can validate an extracted number before trusting it — a candidate that fails its checksum or format isn't a near-miss to reason about, it's simply rejected. Second, once validated, the number is an exact key into the vendor master, not a fuzzy string to be reconciled. Either it matches a vendor's stored identifier or it doesn't.
So when name-based resolution comes back uncertain, the fallback is: extract the tax or registration number, validate it against its format rules, and look it up as an exact key against the vendor master. A clean hit resolves the supplier with higher confidence than the name ever would have — because you matched on identity, not on text.
Why this beats loosening the name match
The tempting alternative is to make name matching more aggressive — lower the fuzzy threshold, accept weaker candidates. That's exactly the wrong direction, because it trades one problem (manual triage) for a worse one (mispayments). Auto-accepting a weak name match is how one company's invoice gets paid against another company's vendor record. We laid out the disciplined, escalating name-resolution cascade — exact, then normalized, then bounded fuzzy — in matching an OCR'd supplier name to the Oracle vendor master, and the rule there holds here: you never loosen a string match to avoid a hold.
A validated identity number is the better lever precisely because it's deterministic. It doesn't guess; it either resolves to an exact key or it doesn't. That makes it safe to run automatically — it can sit ahead of the name tiers as the highest-confidence anchor when the number is present, and serve as the recovery path when the name is uncertain. The principle is the same one that governs good extraction generally, which we touched on in the data-quality tax on global AP: prefer the structured, validatable signal over the ambiguous one.
Where the line still has to be drawn
A deterministic fallback recovers most of the uncertain pile — but not all of it, and the discipline is knowing when to stop:
- Number present and validates to a unique vendor — resolve automatically. This is the recovery you're after.
- Number present but no vendor match — this is signal, not noise. It may be a genuinely new supplier; surface it for review with the validated number attached, so the human starts from a clean key rather than a blurry name.
- Number absent or fails validation, and name is uncertain — now route to a human. This is the residue that genuinely needs judgement, and it should be a small fraction of where you started.
The goal isn't zero manual work — it's making sure the only invoices that reach a person are the ones that genuinely require one, with the system having already done every lookup it possibly could.
Where EZ Cloud fits
EZ Cloud doesn't treat an uncertain supplier name as the end of the road. When name resolution can't confidently identify the vendor, it falls back to extracting and validating the tax or registration number and matching that as an exact key against the vendor master — recovering most of the otherwise-manual invoices automatically, and only escalating the genuine new-supplier and no-identity cases to a person. Reading the vendor master directly, the way the ERP exposes it, is part of our native ERP integration, and resolving the hard 10–30% deterministically rather than dumping it into triage is how that touchless rate stays real on the Oracle EBS and Fusion integration we built it for.