Vendor Spend Analysis: Finding the Expenses Worth a Second Look

A bookkeeper who's been doing this for twenty years develops a habit: before closing the month, they scan the vendor list one more time, looking for the thing that doesn't quite look right. A vendor that billed twice what they usually do. A new name nobody remembers approving. Two payments to the same company, same amount, ten days apart. Most months, nothing's actually wrong. But the scan is what catches the month something is.

That habit is a real skill, and it doesn't scale past however many vendors one person can hold in their head.

The Real Problem: Nobody's Actually Scanning Every Line

The instinct when something feels off in expenses is to open QuickBooks and start scrolling -- which works fine at forty transactions a month and stops working somewhere around four hundred. Past that point, the review that actually catches problems doesn't happen every month; it happens when something's already gone wrong enough to notice on its own, which is later than anyone wants to find out.

A vendor spend analysis that's worth the time doesn't replace the twenty-year bookkeeper's instinct -- it runs that same scan on every vendor, every month, without skipping anyone because the list got long.

What an Expense Anomaly Scanner Actually Does

Run against a General Ledger export and a rolling three months of vendor totals, a proper scan checks four things: which vendors are spending well above their own recent average (not an industry benchmark -- their own history, so a seasonal business doesn't get flagged for being seasonal); which vendors are brand new and already billing a meaningful amount; which payments share a vendor, an amount, and a date close enough together to be worth a second look; and which round-dollar entries landed in a catch-all account like "Uncategorized Expense" instead of somewhere specific.

None of those four checks accuse anyone of anything. A vendor spending 200% of their usual run rate might be a legitimate rush order. Two identical payments ten days apart might be a deposit and a balance, not a double-payment. A round $1,500 entry to an uncategorized account might be a placeholder waiting on an invoice, not a mistake. The scan's job is to shorten the list of things worth fifteen seconds of a human's attention -- not to decide the answer for them.

Getting the Export Right: QuickBooks and Xero

The scan is only as good as the two exports behind it, and most of the ways this goes wrong happen at the export step, before a single formula runs. Two pastes are needed: one month of General Ledger detail for your expense accounts, with the vendor name on every line, and a short vendor history -- each vendor paid this month, with what they were paid in each of the three months before.

What you actually need, part one: the ledger. A General Ledger (or account transactions) export filtered to the one month you're reviewing and to expense and cost-of-goods accounts only, with date, account, amount, and vendor on every row. Vendor is the column that does the work -- the duplicate check and the new-vendor check both key on it -- so it has to be the real, legible vendor name, not an ID. If a customer or employee name would otherwise land in that column (a reimbursement, a refund), anonymize that name instead; the vendor column is the one that must stay readable.

What you actually need, part two: the vendor history. One row per vendor paid this month, with that vendor's total spend in each of the three prior months. This is the trailing average the spike check compares against, and it's what tells the scan a vendor is new: three blank trailing months means "no prior spend on file," not "missing data." QuickBooks Online has this as Reports -> Expenses by Vendor Summary with columns set to Months; QuickBooks Desktop has the same report under Reports -> Company & Financial; Xero's equivalent is Expenses by Contact, run once per month or with the date range set to cover the three months and the columns split by month.

The trap that catches the most people: vendor names that don't match themselves. "ABC Supply" in one month and "ABC Supply Co." in the next reads, to any scan, as one vendor disappearing and a new vendor appearing -- a phantom new-vendor flag and a phantom drop in the first one's run rate. Before pasting, glance down the vendor column for near-duplicates and pick one spelling. This is also worth fixing at the source; inconsistent payee names are one of the earliest signs of a books-mess problem, and the scan will keep surfacing them until they're cleaned up.

One period, one basis. Pull the ledger for exactly one month and pull the vendor history on the same accounting method. On an accrual basis, expense lines carry the vendor from the bill, which is what you want; on a cash basis, the same spend shows up when the bill was paid, which can land a large invoice in a different month than the history report expects and manufacture a spike that's really a timing artifact. Whichever basis you normally review, use it for both pastes.

Anonymize the right column. The scan never asks for the posting user, and class, job, and memo are optional. Vendor names are required. If your export mixes vendors with customer or employee payees in one Name column -- a customer refund, an expense reimbursement -- replace those specific names with an ID (CUST-001, EMP-001) and leave the vendors alone. Anonymizing the whole column defeats the two checks that make the scan worth running.

A five-minute sanity check before you paste anything in: does the ledger's total for the month roughly match what you already know the business spent? Does the vendor history list the vendors you'd expect to see, with prior-month totals that look like the right order of magnitude? A ledger that's missing an account, or a history report run on the wrong three months, will produce a confident-looking set of flags that mean nothing. Bad input makes a bad scan just as easily as bad bookkeeping does.

A Worked Example

Four checks, four different outcomes, on the same ledger:

None of these four is presented as a confirmed problem -- each is a specific, computed reason a bookkeeper's fifteen-second gut check would land there anyway, surfaced automatically instead of by scrolling.

These figures are a worked illustration, not a benchmark for your business -- what counts as a spike depends on the vendor's own history, and the thresholds are meant to be adjusted, not matched.

What This Does NOT Do

It does not confirm a duplicate payment happened. Same vendor, same amount, close dates is a pattern that's worth checking -- it is not proof, and a business that pays a recurring bill in two installments, or splits a deposit from a balance, will trigger that same pattern without anything being wrong. Anything that tells you a duplicate WAS found, rather than a duplicate LOOKS possible, is overstating what the ledger alone can show.

It does not know whether a vendor spike is a problem. A price increase, a rush order, a one-time project -- all look identical to "spending more than usual" from the outside. And it does not know whether a round-dollar entry is miscoded; it only knows the account name matches a pattern that catch-all accounts tend to have.

It also won't catch anything that never made it into the ledger in the first place -- a payment made outside the normal process, or one recorded to the wrong vendor name entirely, so it never shows up as "new."

When Vendor Spend Analysis Isn't the Right Starting Point

If the books aren't reconciled or current, a scan run against incomplete data will miss real problems and flag phantom ones -- get the books current first, which is a QuickBooks-is-a-mess question before it is a vendor question. If a bookkeeper just left and you're not sure what state the file is in, the cleanup decision path comes before any scan. And if the concern is really "are we making money on this job," not "does anything in the ledger look off," that's a job-costing question -- a vendor can be paying exactly what's expected and the job can still be losing money. If what moved is gross margin rather than a single vendor, a margin bridge answers that question at the account level instead.

The Decision Path

Run the scan monthly, not just when something already feels wrong -- the whole value is catching what doesn't feel wrong yet. When something flags, treat it as a starting point: pull the actual invoice or bill before deciding anything. A possible-duplicate flag that turns out to be a legit deposit-and-balance costs fifteen seconds to rule out. One that turns out to be real costs a lot more to catch three months later.

FAQ

How do I find duplicate payments in QuickBooks?
QuickBooks doesn't flag this automatically. The manual check is sorting a vendor's transactions by amount and scanning for repeats within a short date window -- workable for a handful of vendors, slow past that.

What's a normal amount of vendor spend increase month to month?
It depends heavily on the business and the vendor, which is why comparing a vendor to its OWN trailing average matters more than any fixed percentage -- a seasonal vendor spiking in its normal season isn't an anomaly.

Is a round-dollar entry to "Uncategorized Expense" always a mistake?
No. It's often a placeholder waiting on the actual invoice or receipt. It's worth a second look specifically because catch-all accounts are where miscoded entries tend to hide, not because every entry there is wrong.

Does this replace a bookkeeper's monthly review?
No. It's built to support that review by surfacing candidates faster, especially past the point where scrolling the full ledger by eye stops being practical.

Next Step

If vendor spend has gotten harder to keep an eye on as the ledger has grown, the first move is running the four checks on every vendor, not scrolling for the ones you remember. Expense Anomaly Scanner is a $14.99 workbook that does exactly that from a General Ledger export and a vendor history you already have -- paste them in and it flags vendor spend off its own trailing average, new vendors, possible duplicate payments, and round-dollar entries to catch-all accounts, with the "possible, not confirmed" limitation above disclosed in the workbook itself, not just this article.

If the deeper question is whether the gap is a process problem, a provider problem, or just a volume problem that needs a better tool, the are-my-books-a-mess diagnostic at GetAFractional is the better starting point -- see also the books-mess pillar guide for the fuller breakdown of that question. A vendor scan answers "what looks off this month," not "is the bookkeeping itself the problem."

This article is informational and does not constitute financial, legal, or tax advice. Consult a qualified professional for decisions specific to your situation.