All posts

Systems, PMS, and buying

Your vendor master has four records for the same landscaper, and that is why coding fails

AI coding learns from history keyed to a vendor. Four records for one vendor means four thin histories instead of one good one, and no automation fixes that.

The BillRoute Team8 min read

Search your vendor master for a landscaping company you use. You will probably find "ABC Landscaping," "ABC Landscaping LLC," "ABC Lawn & Landscape," and "ABC Landscaping - DO NOT USE."

Four records, one company, and the reason it matters is not tidiness.

Coding automation is keyed to the vendor

AI GL coding works by learning your historical pattern: this vendor, this kind of line item, at this property, has been coded to this account 340 times.

That pattern lives against a vendor record. Four records for one vendor means four separate histories, each too thin to be confident, and coding accuracy on that vendor stays poor no matter how good the model is.

So vendor master cleanup is not a nice-to-have before an AP automation project. It is the input the automation learns from, and a dirty master caps how well any coding system can perform on your data. That is true of ours and of everyone else's.

Five problems in a typical master

Duplicates. The main one. They accumulate because creating a vendor is easier than searching for one, especially under time pressure at a property.

Inactive records still active. Vendors you stopped using years ago, still selectable, which is how an invoice gets coded to a vendor nobody has worked with since 2021.

Missing tax information. Vendors paid over the reporting threshold with no W-9 on file. This surfaces at year end as a 1099 you cannot file correctly, and possibly as a backup withholding obligation.

Remit-to sprawl. One vendor with three remit-to addresses, two of which are stale. This is also a fraud exposure, since a legitimate-looking third address is harder to question when the record already has several.

No default coding. A vendor record with no default GL account or property association gives the coding engine nothing to start from on the first invoice.

Match on identity, not on name

Name matching finds the easy duplicates and misses the ones that matter.

The stronger keys:

Tax identification number. The definitive one. Two records with the same TIN are the same entity, full stop. This is also why collecting the W-9 at onboarding pays off twice.

Remit-to bank account, where you have it. Two vendors paid to the same account are either the same entity or something worth investigating.

Normalized name plus address. Strip entity suffixes, punctuation, and case, then compare. This catches "ABC Landscaping LLC" against "abc landscaping, l.l.c."

Phone number. Weaker and useful as a tiebreaker.

Run TIN matching first. It will resolve a meaningful share of the list with no judgment required, and the remainder is the set that needs a person.

Sequence the cleanup by spend, not alphabetically

A full cleanup of a 2,000-vendor master is a project nobody finishes. A cleanup that captures most of the value is a week.

The order that works:

Sort vendors by trailing twelve month spend. Take the top 100. Those probably account for the large majority of your invoice volume, and cleaning them cleans most of what your coding engine will see.

For each, resolve duplicates, confirm the W-9 and TIN, confirm one remit-to, and set default coding.

Then deactivate everything with no activity in twenty-four months, in bulk, without reviewing individually. If one turns out to be needed, it gets reactivated in a minute.

Leave the long tail of low-spend vendors alone. The cost of cleaning them exceeds the benefit, and they will get cleaned naturally when they next submit an invoice.

Property associations matter as much as vendor identity

A detail that gets missed and drives real exception volume.

A vendor who works six of your forty properties should be associated with those six. When an invoice arrives naming a property outside that set, that is a signal: either a new property relationship nobody recorded, or a misidentified property, or the wrong vendor.

Without the association, every property is equally plausible and the check does not exist. With it, a Property Code Mismatch is a named validation error a person can resolve in seconds.

Vendor-property filtering is one of the flags in our own product for exactly this reason, and its value depends entirely on the associations being maintained.

Ownership changes are the case that breaks associations

Worth naming because it happens constantly in third-party management.

A property changes ownership or leaves your management. Its vendor associations, chart of accounts mapping, and open invoices all need handling, and the default outcome is that they sit stale until somebody notices an invoice coded to a property you no longer manage.

That is a process rather than a feature: a defined step at every ownership change covering vendor associations, open POs, accruals, and the final invoice cutoff. Having it written down is most of the work.

What we do and what we do not

Vendors, properties, chart of accounts, and GL codes sync from ResMan in real time, so the master you maintain there is the master BillRoute validates against. Supplier records carry coding defaults. Validation surfaces Supplier Code Mismatch and Property Code Mismatch as named errors rather than as generic failures.

Where we stop, and this is the important part of the post:

We do not clean your vendor master. There is no dedupe button. Merging vendor records happens in your ERP, because that is the system of record, and any AP platform claiming to fix your master data should be asked what happens when its version and your ERP's disagree.

We do not collect W-9s or run TIN matching.

We do not decide which duplicate survives a merge.

The reason to say this plainly: a dirty vendor master is the most common reason an AP automation rollout underperforms its demo, and it is a data project that happens before the software rather than a problem the software solves. Budget for it.

Sort by spend and read the top 100

Export your vendor master with trailing twelve month spend. Read the first hundred rows.

Count the duplicates you can spot by eye in that hundred.

Whatever that count is, it is the ceiling on how well any coding automation will perform on your highest-volume vendors.

How many did you find?

Keep reading