The One-Time Vendor Problem: Why Most AP Automation Breaks the Moment a New Supplier Shows Up

An invoice lands in the AP inbox on a Tuesday morning. It is from an electrician who repaired a failed HVAC compressor at the distribution center over the weekend. The facilities manager called him at 9 PM on Saturday, he showed up, he fixed it, and now he wants to be paid. There is no purchase order. There is no vendor record. There is no contract on file. The invoice is real, the work happened, and the amount is fair.

Here is what happens next in most companies running AP automation. The system extracts the invoice, attempts to match the vendor name against the master file, finds nothing, and throws an exception. The invoice drops into a manual queue where it sits until someone on the AP team notices it, emails the facilities manager to confirm the work, opens a vendor onboarding request, chases down a W-9, waits for the vendor record to be created, and then keys the invoice by hand because by that point the automation window has closed. Total elapsed time is often two to three weeks. The electrician calls twice asking where his money is.

This is the one-time vendor problem, and it is the quiet failure mode that almost no AP automation vendor talks about. Every tool on the market handles the vendors already sitting in the master file just fine. The demo always shows a clean three-way match against a known supplier with a tidy PO trail. Real AP operations do not look like the demo. They look like that electrician invoice, arriving without warning, carrying no history, and demanding a decision anyway.

The Invoices Nobody Plans For Are Not Rare

The instinct is to treat one-time vendor invoices as edge cases. The data says otherwise. Depending on the industry, invoices from suppliers with no PO and no established vendor record typically make up 15 to 30 percent of total invoice volume. In services-heavy businesses, professional firms, and companies with distributed field operations, the share climbs higher.

Think about where these invoices actually come from.

Contractors and trades are the biggest category. A plumber called for a burst pipe, a locksmith after a break-in, a landscaping crew hired for one seasonal cleanup, a specialist consultant brought in for a single audit. None of these engagements start with a requisition. They start with a phone call and a handshake, and the paperwork arrives after the work is done.

Emergency purchases follow the same pattern. A production line goes down and the only replacement part available today is from a distributor the company has never used. Nobody stops to onboard a vendor while the line sits idle. The part gets ordered on a manager's authority, and the invoice shows up a week later with no PO to match against.

Then there are the annual and near-annual vendors. The event venue booked once a year for the sales kickoff. The printing shop that produces trade show materials every spring. The photographer hired for the company holiday party. Some of these vendors technically exist in the master file from last year, but the record is stale, the remit-to address has changed, or the entity name on the invoice no longer matches what was entered fourteen months ago. From the matching engine's point of view, a stale record that fails validation is functionally the same as no record at all. 

Marketing departments generate a steady stream of these. Influencer payments, one-off sponsorships, freelance designers, a podcast ad placement, a local radio spot. Each one is a legitimate business expense from a supplier the company will probably never use again. Reimbursement-style invoices from individuals, honorariums for guest speakers, and refunds owed to customers who overpaid all land in the same bucket.

Add it up and a mid-sized company processing 5,000 invoices a month can easily see 750 to 1,500 of them arrive with no PO and no reliable vendor match. If each one takes 20 to 30 minutes of manual handling, that is somewhere between 250 and 750 hours of AP labor every month spent on the invoices the automation was supposed to eliminate.

Why Automation Tools Choke on Exactly These Invoices

The failure is not random. It is baked into how most AP automation is designed.

The dominant architecture in AP automation is match-centric. The system's core competency is comparing an extracted invoice against reference data that already exists, meaning the PO, the goods receipt, and the vendor master record. When all three exist, the logic is straightforward. Compare line items, compare quantities, compare prices, check tolerances, and post. The entire value proposition rests on the reference data being there.

Remove the reference data and the architecture has nothing to compare against. The matching engine does not degrade gracefully. It fails completely, because matching was the only tool it had. The invoice gets stamped as an exception and the system's involvement ends. Everything after that point, which is to say all the actual work, falls back on humans.

Vendor master dependency makes this worse. Most platforms will not even allow an invoice to enter the workflow unless it can be attached to an existing vendor ID. This is usually justified as a fraud control, and the instinct is not wrong. Unknown vendors are a genuine fraud vector. But the control as implemented is a blunt instrument. It cannot distinguish between a fraudulent invoice from a fake supplier and a legitimate invoice from the electrician who fixed the compressor on Saturday night. Both get the same treatment, which is a hard stop.

The third structural problem is that approval routing in most systems is keyed to PO data. The approval chain derives from who raised the requisition, which cost center it hit, and what approval limits apply. No PO means no requisition, no requester of record, and no derivable approval path. The system literally does not know whose desk this invoice belongs on. So it guesses, or more commonly, it dumps the invoice into a shared queue addressed to nobody in particular.

The result is a strange inversion. The invoices that need the least judgment, clean PO matches from established vendors, get the full benefit of automation. The invoices that need the most judgment, and that carry the most fraud risk and the most vendor relationship risk, get shoved back into email threads and spreadsheet trackers. The automation handles the easy 75 percent and abandons the hard 25 percent, and the hard 25 percent is where the late payments, duplicate payments, and fraud losses actually live.

What Handling a No-Match Invoice Actually Requires

Rejecting the invoice is not handling it. Parking it in a queue is not handling it either. Actually processing a one-time vendor invoice means the system has to do three things that match-centric platforms were never built to do. It has to extract everything without a template, build enough context to justify payment without a PO trail, and route the invoice to a human who can make the final call.

Extraction that does not depend on familiarity

The first hurdle is mundane but real. One-time vendors send the worst documents in the entire AP pipeline. Established suppliers tend to produce consistent, machine-friendly invoices because they invoice constantly. One-time vendors send whatever they have. A Word document exported to PDF. A photo of a paper invoice taken on a phone. A handwritten carbon copy from a contractor's invoice book. A QuickBooks template with fields in nonstandard places.

Template-based extraction collapses here by definition. There is no template for a vendor the system has never seen, and there never will be, because the vendor will never send a second invoice to learn from. The extraction layer has to work from document understanding rather than layout memorization. It needs to find the vendor name, invoice number, date, line items, tax, and total based on what those fields mean, not where they sat on the last hundred invoices from this sender. It also needs to pull the fields that matter specifically for new vendors, including the remit-to address, bank details if present, tax registration numbers, and any contact information, because those fields feed the verification step that comes next.

Verification without a PO trail

This is the step most tools skip entirely, and it is where the real intelligence lives. Without a PO, the question "should we pay this?" cannot be answered by matching. It has to be answered by assembling context from other sources.

The richest source is usually sitting in plain sight. Most one-time vendor invoices arrive by email, and the email itself carries evidence. Who sent it? Was it forwarded by an internal employee, and if so, which one? A facilities manager forwarding an electrician's invoice with a note saying "please pay, emergency repair Saturday" is context. The forwarding employee is the de facto requester, their department is the likely cost center, and their note is an informal confirmation that goods or services were received. A capable system reads the email thread, not just the attachment, and extracts that context as structured data.

Then come the checks that stand in for the missing PO. Does the vendor's tax ID validate against the relevant registry? Does the entity name on the invoice match the name registered to that tax ID? Is the bank account country consistent with the vendor's address? Has an invoice with this number, this amount, or this bank account been seen before anywhere in the system, including under a different vendor name? That last check matters because duplicate and near-duplicate submission is one of the most common ways one-time invoices turn into double payments. With no vendor record to anchor the duplicate check, the system has to search across the entire invoice corpus by amount, date proximity, bank details, and fuzzy name similarity.

Fraud screening for unknown vendors deserves its own layer. New-vendor fraud usually shows a pattern. An invoice arrives unsolicited, references vague services, carries urgency language, uses a free email domain that does not match the company name, or requests payment to an account in a jurisdiction unrelated to the vendor's stated address. None of these signals is conclusive alone. Together they form a risk score, and the score should determine how much human scrutiny the invoice gets rather than whether it gets processed at all.

Routing to the right kind of approval

Once the invoice is extracted and the context is assembled, someone still has to say yes. The design question is who, and through what channel.

The requester identified from the email trail is the natural first approver. They ordered the work or received the goods, so they confirm the invoice is legitimate. Above them, the routing should follow amount thresholds and risk tiers rather than PO-derived chains. A $180 invoice from a locksmith, confirmed by the office manager who called him, verified against the tax registry, and clean on the duplicate check, does not need the CFO. It needs one confirmation click. A $48,000 invoice from an unknown consulting entity with a foreign bank account and no internal requester identified needs a very different path, probably involving procurement, possibly involving a callback verification of the bank details through an independently sourced phone number.

The channel matters as much as the chain. The people who need to approve one-time vendor invoices are usually not AP system users. The facilities manager, the event coordinator, and the plant supervisor do not have logins, and asking them to create accounts to approve one invoice a quarter guarantees the approval will stall. Email-based approval solves this. The system sends the approver a message containing the invoice image, the extracted data, the verification results, and the assembled context, with approve and reject actions embedded directly in the email. The approver acts from their inbox in thirty seconds. The system records the response, the timestamp, and the full context as an audit trail, which is exactly what auditors ask for when they sample non-PO payments.

The final piece is closing the loop on the vendor record itself. If the vendor is genuinely one-time, the system can process the payment against a controlled one-time vendor account, standard practice in SAP environments through CPD vendor functionality, without polluting the master file with a record nobody will ever use again. If the invoice reveals a vendor likely to recur, the system should propose a proper vendor record pre-filled from the extracted and verified data, so onboarding takes minutes instead of days. The decision between the two paths can itself be automated based on the vendor category and history of similar suppliers.

What Changes When the Hard Invoices Get Handled

The measurable effects show up quickly, and they concentrate exactly where AP leaders feel the most pain.

Cycle time for non-PO invoices is the most visible. Companies that route one-time vendor invoices through context-based verification and email approval routinely take the handling time from two or three weeks down to one or two days. The invoice that used to sit in a queue waiting for someone to figure out whose it was now arrives in the right inbox within minutes of receipt, with everything the approver needs attached.

The labor math follows directly. Those 250 to 750 monthly hours of manual exception handling shrink to a fraction, because the human role changes from investigation to confirmation. The AP specialist no longer spends 25 minutes reconstructing who ordered what. They spend two minutes reviewing a package the system already assembled, and they only do that for the invoices whose risk score demands it.

Fraud exposure drops rather than rises, which surprises people who assume that processing unknown vendors faster means screening them less. The opposite is true. Manual handling of one-time invoices is where fraud slips through, because a tired specialist processing a backlog under pressure makes inconsistent checks. Systematic verification runs every check on every invoice, every time. The tax ID validates or it does not. The bank account has been seen before or it has not. Consistency is the fraud control, and consistency is what humans under queue pressure cannot deliver.

Vendor relationships improve in ways that are harder to quantify but easy to observe. The contractor who gets paid in four days answers the phone the next time the compressor fails at 9 PM on a Saturday. The one who waited six weeks and made three phone calls does not. For companies that depend on a long tail of small local suppliers, payment reliability is a supply chain asset.

The Questions That Expose Whether a Platform Can Do This

Anyone evaluating AP automation can separate the platforms that handle this problem from the platforms that hide it with a short list of pointed questions. The demo will not reveal the answer, because the demo always uses a known vendor. The questions will.

Ask what happens, step by step, when an invoice arrives from a vendor with no master record. If the answer is "it goes to an exception queue for your team to review," the platform has just described the manual process it was supposed to replace. Ask whether the extraction works on a vendor's first invoice or whether it needs training examples. Ask whether the system reads the email an invoice arrived in, or only the attachment. Ask how approval routing works when there is no PO to derive a chain from, and whether approvers outside the system can act without a login. Ask how duplicate detection works when there is no vendor ID to group invoices under.

Then ask for the number that summarizes everything. What percentage of non-PO, unknown-vendor invoices does the platform process without a human touching them before the approval step? Vendors who have solved this problem know that number and will say it. Vendors who have not will redirect the conversation back to three-way matching accuracy, which was never the hard part.

Automation That Only Handles the Easy Invoices Is Not Automation

The one-time vendor problem persists because it sits in a blind spot. AP automation vendors build for the invoice flow that is easiest to demo and easiest to make accurate, and that flow assumes reference data that a meaningful share of real invoices simply do not have. AP leaders, meanwhile, have absorbed the manual queue as a fact of life, a background cost that gets staffed around rather than solved.

It does not have to be. The technical pieces exist. Extraction that understands documents rather than memorizing templates. Verification that assembles context from email trails, registries, and the invoice corpus itself. Approval workflows that reach the actual decision maker in their inbox instead of demanding they come to the system. Put together, these turn the hardest quarter of invoice volume from a permanent exception pile into a flow with its own logic, its own controls, and its own audit trail.

The next time a vendor demo shows an invoice gliding through a three-way match, ask them to run the electrician instead. No PO, no vendor record, a phone photo of a paper invoice, forwarded by a facilities manager at 7 AM with a one-line note. What the system does in the next sixty seconds tells you more about the platform than the rest of the demo combined.