BreezyCorp Handbook

Appearance

Vendor-master match isn't firing ​

You added a vendor to the client's vendor master with a default account code, but new documents from that vendor are still landing as MEDIUM (keyword) confidence or even UNCLASSIFIED instead of the expected HIGH. The classifier walks four priority branches in order — vendor master, then COA keywords, then category inference, then the unclassified bucket — and the first branch that produces a result wins. When vendor matching looks broken, it's almost always one of five things.

1. The vendor name on the document doesn't exactly match the master ​

Vendor matching is exact (with optional aliases). If the document OCR'd as DBS BANK LTD but the vendor master row is DBS Bank, the strings don't match and the classifier moves on to the keyword branch.

Check:

  1. Open the affected journal entry → the Source document panel.
  2. Note the Vendor name exactly as extracted by OCR (including casing, suffixes like Pte Ltd, Ltd, trailing periods).
  3. Compare it character-for-character with the vendor master row on client → Vendor master.

Fix: Add the OCR'd string as an alias on the vendor master row rather than editing the canonical name. The vendor master matches against name OR aliases, so a single vendor can carry several spellings. Common aliases worth adding up front: the legal-suffix form (Pte Ltd, Pte. Ltd.), the all-caps form, and any abbreviation the bank statement narration uses.

2. The vendor master is on the wrong client ​

Vendor masters are scoped per client — adding DBS Bank to Client A's master does not help Client B. If you onboarded a new client and assumed the masters carry over, they don't.

Check: Open the correct client → Vendor master tab. If the row isn't there, the master is missing for this client.

Fix: Add the vendor on the correct client. (See Add vendors to vendor master.) If you have a portfolio of clients that share most vendors, copy/paste from a similar client's master at onboarding rather than rebuilding from scratch.

3. The vendor master row is inactive ​

Vendor master rows can be deactivated without deleting them — useful when a supplier is decommissioned but you want to preserve the historical mapping. Inactive rows are skipped by the classifier.

Check: Open the vendor master row. Look for the Active toggle — if it's off, the row is being skipped.

Fix: Toggle Active back on.

4. The classification ran before you added the vendor ​

Documents are classified once, at draft time. Adding a vendor master row after the document was already drafted does not retro-classify the existing journal entry. The new vendor master will only apply to documents drafted from now on.

Check: Compare the document's Created at timestamp on the Documents tab with the Created at on the vendor master row. If the document is older, the vendor master didn't exist at classification time.

Fix: Open the journal entry → click Re-classify. The classifier reruns against the current vendor master and overwrites the account code + confidence. Approval state resets to DRAFT so the entry goes back through review.

TIP

Re-classify is also the right move when you correct a typo in the vendor master row — existing entries don't pick up the fix automatically.

5. A COA keyword matched first and the vendor branch never ran ​

This one is subtle. The classifier does check vendor master first, but only finds a match if the vendor master row points to a valid COA account code. If the vendor master row references an account code that doesn't exist on the client's chart of accounts, the engine logs a warning and falls through to keyword matching — which often grabs the entry on a generic keyword like "services" or "subscription". The result: a MEDIUM confidence entry on a generic account, when you expected HIGH on the vendor's preferred account.

Check:

  1. Open the vendor master row → note its Default account code.
  2. Open the client → Chart of accounts tab.
  3. Search for that account code. If it's not there (or it's there but inactive), the vendor master is pointing at a phantom account.

Fix: Either add the missing account code to the chart of accounts, or update the vendor master to use a code that does exist. Then re-classify the affected journal entries.

Still not firing? ​

If all five check out and a document with the matching vendor name is still classifying as MEDIUM or UNCLASSIFIED:

  1. Open the journal entry's Audit tab — every classification logs a bookkeeping.entry.classified event with the reason (vendor_master: ..., keyword: ..., category_inference: ..., or no_match). The reason tells you exactly which branch produced the mapping.
  2. If the reason starts with keyword: you know vendor matching genuinely didn't fire — return to causes 1, 3, or 5 above.
  3. If the reason starts with vendor_master: but the account code is wrong, the vendor master row itself is wrong — fix the row and re-classify.

If the audit log shows no classification event at all on a DRAFT entry, the classifier never ran. That's a worker-side problem, not a vendor-master one — escalate via the on-call channel.

Internal use only — BreezyCorp