Auto-categorize a vendor with rules

Vendor rules set the defaults TALISK_HQ uses each time a bill comes in from a supplier (its currency, expense category, and tax handling) so you stop fixing the same vendor by hand.

1. Go to Ledger › Expenses › Vendor Rules and click Add Rule (a rule is also created automatically the first time you set a currency or category on a vendor's bill, or when you set a Category on the vendor itself under Edit vendor on the Vendors page).
2. Choose the vendor and the defaults to apply, and optionally have it auto-approve or mark the vendor's bills recurring.
3. Turn on apply to existing to backfill the vendor's current bills too.

From then on, new bills from that vendor arrive pre-filled. The backfill option rewrites your active bills for that vendor; it deliberately skips bills that are discarded, cancelled, or already settled, since those are finished.

The sales-tax default

A vendor rule can also answer "does this supplier charge sales tax?" once, instead of on every bill. Pick a Sales tax treatment on the rule: Standard rate, GST/HST only, Zero-rated, Exempt, or No sales tax (foreign / not registered). It is the same list you get on a bank line and in Ledger › Banking › Rules, because it is the same question.

It is used in one situation only: when a bill from that vendor breaks out no tax of its own. Then TALISK_HQ works the tax back out of the total at your book's provincial rate and fills the split, so the input tax credit is claimed instead of quietly buried in the expense. A bill whose document states its tax keeps exactly what the document says, and so does a bill that states a subtotal different from its total. The document always wins.

Bills filled this way say so above the tax fields, and every figure stays editable, so you can correct one the supplier charged differently.

Two things it deliberately does not do. It never changes bills you already have, even with apply to existing turned on, because that would move the tax on entries already posted and possibly in a filed period. And it claims nothing on a foreign-currency bill, or on a book with no business province set under Ledger › Setup.

Line splits: one supplier, several accounts

Some suppliers always send mixed bills. A single monthly Shopify invoice can carry app subscriptions, the platform subscription, and shipping labels, and those belong in different accounts. A vendor rule's single category cannot say that, so the supplier's Line splits can: open the vendor on Ledger › Expenses › Vendors and add rules like "lines containing Shipping go to Shipping & Freight" and "lines containing App go to Software".

From then on, when a bill from that supplier arrives, its Split across accounts editor comes pre-filled: each line that matches a pattern suggests its account, lines nothing matches fall back to the vendor's usual category, and a small note under a line says which rule filled it. Review the split and click Save line coding. Nothing posts until you save the split on the bill, and a line split never changes bills you already recorded.

You rarely need to type these rules by hand. The first time you split one of the supplier's bills yourself, TALISK_HQ asks "Remember this split?" and offers the patterns it saw, ready to edit. Rules match in order and the first match wins, so put the more specific pattern above the general one.

Letting TALISK_HQ split them for you

Once a supplier has line rules, you can tick Split this supplier's bills automatically. From then on a bill from that supplier can have its split recorded for you when you approve it, instead of waiting for you to save the split by hand.

It only does that when the bill comes out exactly like a split you have already approved for that supplier: the same patterns matching, landing on the same accounts, and the lines adding up to the bill to the cent. A line TALISK_HQ has not seen before, a rule you have re-pointed at a different account, or a total that does not add up all mean the bill waits for you, as it does today. Approve that one split by hand and the new shape counts as approved from then on.

Two things it can never do. It never changes a bill you have already coded yourself: your split always wins. And it never changes your sales tax. An automatic split is limited to accounts that claim tax the same way the bill already would, so the input tax credit and the amount you owe the supplier come out to the cent identical whether the bill is split or not. Only which expense lines the cost appears under changes.

A bill TALISK_HQ split for you says so at the top of its Split across accounts editor. Change any line and save to record it differently, or use Clear line coding to go back to a single account.

Changing your mind also changes what TALISK_HQ does next time. If you drop a line from a bill's split and save, that line stops counting as approved, so a later bill with the same line waits for you again. Clear line coding does the same for every line on the bill. Splits you approved on the supplier's other bills are left alone. Merging two suppliers keeps the splits you approved on both. Where the two disagree about the same line, the supplier you kept wins, the same way its line rules do.

These rules are for bills that arrive as a document, matched on the sender's email domain. A supplier who only ever shows up as a line on your bank or card statement has no email domain to match, so its answer lives in a separate place: Ledger › Banking › Rules. Set both if a supplier reaches you both ways.

Linking a rule to its vendor

A supplier often reaches you more than one way: two email domains, two trading names. Each way gets its own rule, but the supplier has only one answer to "what category?" or "do they charge sales tax?". Linking a rule to its vendor (from the rule editor's Vendor picker, or from the vendor's own panel on Ledger › Expenses › Vendors) is how you tell TALISK_HQ those rules are the same supplier.

When you link, the vendor adopts the rule's defaults as its one answer set, and every rule linked to that vendor uses those answers from then on, whichever of them matched the bill. If the rule you are linking disagrees with what the vendor already says (say one rule claims standard sales tax and another says zero-rated), TALISK_HQ shows you both values and asks you to pick. Nothing is decided silently, and the link only happens once you choose.

Unlinking puts the rule back exactly as it was: it keeps its own defaults, and the vendor keeps its answers.

Some domains cannot be a rule

TALISK_HQ will not let you build a rule on an email provider such as gmail.com or outlook.com, or on a domain belonging to one of your own connected mailboxes. Neither of those says who sent a bill.

A provider is shared by every sole trader who uses it, so a rule on it would code all of them the same way. One of your own domains is worse: it appears when you forward a receipt to yourself, so it describes how the bill reached you rather than who it came from. Match on the supplier's name instead, or on their own domain if they have one.

Marketplaces such as notice.alibaba.com are still allowed. They cover more than one supplier, but that is a real fact about how those bills reach you, and the vendor panel shows you which suppliers a rule touches.

When the statement calls your vendor something else

Some vendors bill you under one name and appear on your bank or card statement under another. Amazon charges show up as AMZN MKTP, Wayfair as WF/, Canada Post as CPC / SCP. When that happens, TALISK_HQ cannot tell from the name alone that the bill and the charge belong together, so it has less evidence that a suggested match is the right one.

You can tell it. Open Ledger › Expenses › Vendors, open the vendor's row, choose Edit vendor, and add the statement wording under Statement names:

1. Put one name per line. The distinctive part is enough, so AMZN MKTP rather than the whole line with its order number.
2. Save. TALISK_HQ uses them from then on to confirm that a bill and a charge are the same supplier, and matching charges rise to the top of the Match picker.

Keep them specific. Generic words that appear on lots of unrelated charges (a province code like ON, or VISA, PURCHASE, CAD) would confirm the wrong match, so TALISK_HQ refuses them and tells you which line it rejected.

Statement names only help TALISK_HQ recognise a supplier. They never change a category, a currency, an amount, or anything in your books.

If the same supplier has ended up as two vendors, say Amazon and Amazon.com.ca ULC, use Merge on the vendor page to combine them first, so everything you have taught TALISK_HQ lives on one vendor.