Why your payee list has 400 names for 40 vendors, and how a converter finds the name in a bank memo

The vendor list that would not stop growing

A bookkeeper wrote to me after her first year-end with a new client. She had converted twelve monthly statements of a business checking account and imported them into QuickBooks Online. The books balanced to the cent. Then she opened the vendor list to start categorizing, and it had more than four hundred names. The client bought gas at the same two stations, groceries at the same store, and paid the same six suppliers. Forty vendors, maybe fifty. Four hundred names.

The reason was on every line of the statement. Each purchase had a different description, even at the same store, and the converter had passed those descriptions through as the payee. QuickBooks did what it does with a payee it has not seen before: it made a new vendor. Her bank rule for the gas station matched nothing, because no two visits to the gas station had the same text.

This article is about what banks put into a transaction description, why it defeats payee matching in every accounting program, and how ProperConvert pulls the name out. I rewrote that part of the converter in September 2026, and the rewrite taught me a lot about how banks write.

What is in a description

A bank description is not a name. It is a log line. The bank's system writes down what kind of transaction it was, which card did it, when the purchase happened as opposed to when it posted, where the merchant is, and one or more reference numbers that the bank uses when you call to dispute it. The merchant name is in there, but it is one field among six or seven, and every bank orders the fields differently.

A few real shapes, with the numbers changed:

Across the many description cases I have worked with, almost every description is unique because of a number, not because of a different merchant. And a large share of them end in a US state or Canadian province code, because card networks print the merchant descriptor as name, city and state, in fixed widths of 25, 13 and 2 characters. The city is cut at 13 characters, which is why you see FORT LAUDERDA and SAN FRANCISC on your statements.

Why it matters more than it looks

Two things depend on the payee being a name.

The first is matching. QuickBooks, Xero, Quicken and Sage all match an incoming transaction to a vendor or a rule by the payee text. A rule that says "payee contains HOME DEPOT, category Repairs" works only if the payee contains HOME DEPOT and the rest does not get in the way. When the payee is POS Withdrawal THE HOME DEPOT #4712 1715 SOUTH 352ND ST FEDERAL WAY WAU Machine# 00000101 Trace# 00000000999999999999, a "contains" rule still fires, but a vendor match by name does not, and the vendor list grows by one per visit.

The second is room. The file formats that carry a payee limit it hard. An OFX or QBO file has a NAME field of 32 characters and a MEMO field of 255. Quicken's QIF payee is longer, but the register shows about 30 characters. So the converter has to make the text shorter without losing the name, and if it cuts from the wrong end, the payee becomes POS Withdrawal THE HOME DEPOT on a good day and POS Withdrawal THE HOME DE on a bad one.

The memo has no such limit, and the bank's reference numbers belong there. When you call the bank about a charge, the trace number is what they ask for. The job is to split the description in two: a short name for matching, and the full text as a memo for the audit trail.

How I used to do it, and why it stopped working

The first version of the payee cleanup, which ran in ProperConvert for many years, was a list. A long list of phrases to remove, BILL PAYMENT TO, Debit Card Purchase at, CHECKCARD, each followed by a rule that ate the digits and punctuation after it. Then a second list of words to delete anywhere, CARD, DEBIT, PURCHASE. Then a rule that removed every run of three or more digits after the first space.

It worked on the layouts I knew when I wrote it, and every new bank layout added a few phrases to the list. The list grew, and the order of the list started to matter: the longer phrase had to sit above its shorter cousin, or the cousin would fire first and leave a tail. And because the rules worked on characters, not on words, they did damage I did not see for years. CARDINAL HEALTH became INAL HEALTH, because CARD was deleted from inside the word. 7-ELEVEN became ELEVEN, because the digit rule took the 7. CASH APP*ROBERTS became CASH APPROBERTS, because removing the star glued the words. A reference like S581092646129437 became S, a single orphan letter at the end of the payee. And a Chase ACH row became a soup of labels, Orig CO Name Att Orig ID Desc Date CO Entry Descr Payment Sec Web Trace, with the actual name somewhere in the middle.

When I finally checked it against every description case I had collected, a good share of them came out with a word that had not been a whole word in the original, and many still had digits in the payee. The list approach had reached its limit.

How it works now

The rewrite, shipped in September 2026, starts from one rule: a description is a sequence of words, and every word is either kept whole or dropped whole. Nothing is cut inside a word. That one rule removed the INAL HEALTH and ELEVEN class of mistakes at once.

Then each word gets a class. Some words are bank talk that is never part of a name: POS, PURCHASE, CHECKCARD, ACH, ZELLE, AUTHORIZED, WITHDRAWAL. Some are bank talk that is also a real word in business names, CARD, ONLINE, MOBILE, PAYMENT, TRANSFER, BUSINESS, ELECTRONIC; those are removed only when they sit next to the first kind, because ELECTRONIC LOCKSMITH INC and MOBILE MINI are real companies. Some words introduce an identifier: REF, CONF, TRACE, TXN, ID, CARD, MACHINE, INV, and a # on its own. And some tokens are identifiers by their shape: a date in any of the forms banks use, 04/02, 120217, 08APR, AUG'23; a time; a run of three or more digits with separators, which covers phone numbers and store numbers; a mask like XXXX3729 or ****1934; and letters mixed with three or more digits, S581092646129437, EFT03482908. A one- or two-digit number is a word, so CIRCLE K 76 and FUEL 4 LAKEWOOD keep their numbers.

With the classes in place, the rules are short. The run of bank words at the start of the description goes, together with any identifiers inside it. A key word followed by an identifier goes, anywhere: Card 0074, Machine# 00N53701, Conf# gv6yr3pg2. A phrase of bank words followed by an identifier goes: PAYMENT 090265619003026. Lone identifiers after the first kept word go. A processor prefix before a star goes and the merchant after it stays: SQ *ROSIE S HAIR SALON becomes ROSIE S HAIR SALON, TST* BIG OAK CAFE becomes BIG OAK CAFE, and PAYPAL INST XFER BRADSHAW PLUMBING becomes BRADSHAW PLUMBING. For the Chase and Bank of America label lists, the payee is the value of the Orig CO Name field, and nothing else is read.

The city and state at the end were the hardest part, because there is no list of every city, and OR is both Oregon and a word in Deposited OR Cashed Check. The state code is removed only when it is the last word. The city is learned from the statement itself: when the same one or two words sit right before the state after two or more different merchants, they are a city in that town, and they come off. One Chase statement teaches the converter LEANDER; one BECU statement teaches it TACOMA, FEDERAL WAY and FORT LAUDERDA after ten merchants. A short built-in list of large cities covers the one-off case. A street address is found by its house number and removed wherever it sits, so 7-ELEVEN 7016 VALLEY AVE E becomes 7-ELEVEN and PUGET SOUND ENERGY INC 355 110TH AVE NE 8882255773 becomes PUGET SOUND ENERGY INC.

Two guards sit over all of it. At least one real word must survive; the location and address rules never take the last one. And if nothing is left after the bank words go, the payee falls back to the original description with only its numbers and dates stripped, so a row that reads Check #2438 gets the payee Check, and a row that is nothing but a number keeps the number. A payee is never empty.

The result on the statements above: Heb Online, THE HOME DEPOT, Audible, Ben E. Keith Com, Att. The full description stays in the memo, so the trace number is one click away when the bank asks for it.

What to do on your side

If you convert statements with ProperConvert, the setting that does this is "Get missing name from memo" in the main settings, on by default for PDF statements, which have no separate name column. If a payee comes out wrong for your bank, the setting "Use legacy name extraction" brings back the old behaviour for that file while you send me the row, and the rules feature lets you rename a payee by matching text, which is the right place for Ben E. Keith Com to become Ben E. Keith.

If you import into QuickBooks Online or QuickBooks Desktop, build your bank rules on the payee, not the memo, and use "contains" with the shortest text that is unique to the vendor. Then review the vendor list once after the first import and merge the duplicates; QuickBooks remembers the merge for the next file. In Xero, the same idea is called a bank rule with a "contains" condition on the payee. In Quicken, the memorized payee list does the matching, and a clean payee is what makes it fill the category on its own. Sage, Wave and other accounting apps each have their own version of the same rule, and in every one of them it keys on the payee.

And whatever software you use, keep the full description somewhere. A payee that says Audible is right for the books, and a memo that says Debit Purchase - VISA On 120217 adbl.co/bill NJ 6100563471 REF # 24692167336100563471806 is right for the audit you may need sometime in the future.

The banks where this shows up most

The statement layouts behind the examples above, with the exact field order of each bank:

More articles about bank statement conversion