Merchant Spending Analysis

This is a different question from expense analysis. Categories tell you *what* the money was for — software, travel, supplies. Merchant analysis tells you *who* you handed it to. Both matter, but only the merchant view answers the question that actually changes a decision: "We're paying who the most?"

Merchant analysis answers "who", not "what"

A category breakdown might tell you that "software" is your third-biggest cost. Useful, but you can't act on a category — you can only act on a vendor. Merchant analysis collapses the whole statement down to a list of payees, each with a running total, so the line that jumps out is a name you recognise and can do something about: renegotiate, consolidate, or cancel.

It also surfaces the thing categories hide — fragmentation. Pay the same supplier through two cards and a bank transfer, and a category view quietly lumps it all under "suppliers" while a merchant view shows one vendor sitting near the top, far bigger than you'd have guessed. The first time you rank by payee, the surprise is usually not the categories. It's discovering that the courier firm, or one ad platform, or a single SaaS vendor, is taking a much larger slice than anyone had clocked.

Prove the figures are complete first

Before you rank a single merchant, confirm nothing fell off the statement. Every bank prints a running balance after each transaction, and that column is a built-in checksum: start at the opening balance, apply each credit and debit in order, and you should finish exactly on the closing balance. Land there and the statement reconciles — the totals you're about to attribute to merchants are whole. Come up short, say by 240, and a transaction is missing or misread, and that gap is going to land against one merchant and quietly understate them.

This matters more for merchant work than people expect. A category absorbs a missing line without much distortion — one dropped 240 debit barely dents a category running to thousands. But merchants are smaller buckets. Lose one payment to a vendor you only pay a few times, and that vendor slides down the ranking or drops off it entirely. The merchant you should have called about never makes the list.

Export Bank Statement runs this check before you see the spreadsheet. It extracts every line, walks the running balance from opening to closing, and confirms the totals reconcile — or it flags the statement instead of handing you a clean-looking export that's short a payment. Most converters extract and leave the checking to you. For merchant analysis that's a real gap, because the whole exercise rests on every payment being attributed to the right name, and you can't attribute a payment that isn't there.

Clean the messy descriptors before you total anything

This is the step that makes or breaks the whole analysis, and the one people skip. Bank statements don't store tidy merchant names — they store whatever came down the card or payment rails, and that string is noisy. The same coffee shop can appear as `SQ *BLUE BEAN`, `BLUE BEAN COFFEE LDN`, and `BLUEBEAN 4471` across one month, because of the card acquirer prefix, the location tag, and a terminal ID. To you they're one vendor. To a raw sort, they're three.

The usual offenders, named so you know what to look for:

• Acquirer and processor prefixes. `SQ *`, `SP *`, `PAYPAL *`, `IZ *` — the payment gateway stamps its own tag in front of the real name. Strip the prefix and the merchant underneath is obvious.
• Location and terminal noise. A town, a store number, a four-digit terminal ID tacked on the end. The same chain reads differently at two branches.
• Trading names versus legal names. You know the shop's brand; the bank shows the registered company behind it. `Acme Trading Ltd` and the high-street name over the door are the same payee.
• Truncation. Long names get cut off mid-word at the character limit, so one vendor appears as two near-identical-but-not-equal strings.

Until these are reconciled, your merchant totals are wrong in the worst way — confidently. The list looks finished; it's just adding the wrong things together. Doing this by hand means eyeballing hundreds of rows and deciding which strings are secretly the same vendor, which is slow and error-prone on a busy account. The analyser does the first pass automatically: it normalises the descriptors, groups likely-same merchants, and totals each one after conversion. What you bring is local knowledge — knowing that two names with nothing obvious in common are the same supplier under different trading styles. The tool clears the volume; you settle the edge cases.

Rank the top merchants, then flag the recurring vendors

With clean names and verified figures, two reads turn the list into something you can act on.

• Top merchants by spend. Sort payees largest to smallest. As with most spending data, a handful of merchants account for the bulk of the outflow, and that's where attention pays back — a 10% discount negotiated with your biggest vendor beats hours spent trimming the long tail. Rank by total spend, but keep payment *count* beside it: a merchant you pay once for a large sum is a different conversation from one taking small amounts forty times a month.
• Recurring vendors. Some merchants aren't just big — they're regular. The same payee at a steady interval and amount is a recurring vendor: a subscription, a retained service, a standing order to a supplier. These are the ones worth auditing hardest, because recurring spend renews on autopilot whether or not you're still getting value. The analyser flags the repeats; you decide which still earn their place. There's more on the cadence side in the detect recurring transactions guide, which looks at *when* payments repeat rather than *who* they go to.

A merchant view and a category view answer different questions, and the strongest reads come from holding both. The expense analysis guide groups the same spend by category — what it was for — so you can pair "we spend most on software" with "and most of that goes to these three vendors".

How to do merchant spending analysis, step by step

You can do all of this by hand: foot each page, tick the running balance, key every debit into a spreadsheet, then sit there merging descriptors until the same vendor stops appearing four times. On a quiet personal account that's fine. On a busy business account the descriptor-merging alone is the long part, and it's exactly where mistakes creep in. The quicker route, on data you can trust:

1. Gather the statements. Download the PDFs from online banking — a few consecutive months if you want a fair picture of who you pay regularly, not just one snapshot. A scan or phone photo of a paper statement works too; it'll be read by OCR.
2. Convert them. Upload the PDFs at /convert. Each line comes across — date, description, money in, money out, balance — across every page.
3. Check the reconciliation result first. Confirm the totals reconcile before you trust any merchant total. A flagged statement means a missing payment got caught before it could drop a vendor down the ranking.
4. Review the cleaned merchant grouping. Open the analyser: descriptors normalised, likely-same payees merged, each merchant totalled. Fix the merges it couldn't know — two trading names that are really one supplier. That's the bit only you can do.
5. Rank and flag. Sort merchants by total spend, keep the payment count alongside, and mark the recurring vendors. The top few names and the recurring ones are where the decisions live.
6. Export. Take the clean .xlsx for your own working, or the CSV in the native bank-import format if the data's headed for Xero, QuickBooks or Zoho Books.

One verified month usually takes well under a minute, and that's the real value — when it's that quick, you check who you're paying monthly instead of stumbling on it at year-end.

A worked example

A small e-commerce business, three months, roughly 280 debits a month across an eight-page PDF. When I footed the first month the page-five total didn't tie — a 240 payment to a packaging supplier had dropped in the seam between two pages. On screen nothing looked wrong; that supplier just sat lower in the list than it should have, which is the quiet kind of error you act on without knowing.

Run the same PDFs through the converter and the reconciliation check flagged that month in seconds and pointed near the gap. Once it was fixed and the descriptors cleaned, the real picture showed. The single biggest payee wasn't a category anyone watched — it was one courier firm, appearing under three different strings that hadn't been adding up, taking more per month than the rent. Merged into one merchant, it was suddenly obvious and very negotiable. Two ad platforms ranked next, one of them recurring on a card that nobody had reviewed in a year. None of that shows in a closing balance, and none of it shows in a category breakdown either. It only appears once verified spend is grouped by clean merchant names and ranked. If you want to set those outflows against what's coming in, the business cash flow analysis guide does that.

One honest caveat before you act on any of it: Export Bank Statement is a file import, not a live bank feed. It converts your PDF statements, verifies they reconcile against the running balance, cleans and groups the merchants in the built-in analyser, and exports a CSV in the native bank-import format Xero, QuickBooks and Zoho Books expect — but you convert, then import the CSV, rather than syncing through a certified bank-feed API. It's a tool you run yourself, so the calls on which vendor to challenge stay yours. It just hands you complete, verified figures, with the right names on them, to make those calls.