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 (or set a Category on the vendor itself under Edit vendor on the Vendors page). When you change the currency or category on one of a vendor's bills, TALISK_HQ also asks Remember this for the vendor: Save rule makes the change that vendor's rule, so its next bill or receipt arrives with it, and Not now leaves the rule alone. Nothing already in your books changes either way. Its box, Also update the vendor's bills and receipts still waiting for review, gives the vendor's Pending and Low confidence documents the same answer. A vendor rule fills in bills and receipts only; a bank or card charge takes its standing answer from Ledger › Banking › Rules.
2. Choose the vendor and the defaults to apply, and optionally have it auto-approve or mark the vendor's bills recurring.
3. Tick Also apply to this vendor's bills still in review to give the vendor's Pending and Low confidence bills the same defaults.

From then on, new bills from that vendor arrive pre-filled. The backfill reaches only the vendor's bills and receipts still in review. Anything you have already approved keeps what you approved it with, and that includes a receipt waiting for its bank match: nothing has posted on it yet, but it posts exactly as you approved it when the bank line arrives, so a rule changed afterwards must not change it. Discarded, cancelled and duplicate bills are never touched. To change an approved bill, edit that bill.

Auto-approve has two deliberate holds. A bill whose date TALISK_HQ could not read with certainty always waits in Pending for you, even when the rule matches and the amount is within tolerance. Approving posts the bill to the date on it, which decides the return its GST lands on, so that is not a decision to make unattended. See "Approve a bill" for how to confirm the date in one click. And a document that calls itself a proforma always waits too: a proforma is a quote, not a bill you owe.

When a bill is auto-approved, TALISK_HQ posts it to your books exactly as if you had pressed Approve yourself: the expense lands on the category the vendor rule or the vendor itself carries, and the payable is recorded so it can be matched to the bank line when it is paid. If that posting is refused, most often because the bill is dated inside a period you have closed, the bill stays in Pending for you instead of being approved with nothing behind it.

Auto-approve is off unless you turn it on here. The Dashboard's "mark as recurring" suggestion sets up the vendor's frequency, expected amount and category so its bills arrive pre-filled and TALISK_HQ tells you when one is missing, but the bills still wait for your approval. Posting to your books unattended is a separate choice, and this is where you make it.

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, not even the ones still in review when you tick Also apply to this vendor's bills still in review: it fills in a bill only as the bill arrives, so it can never move the tax on an entry already posted, 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.

The sales-tax promise above is also what decides when an automatic split stops applying. If you later change the bill's own category, TALISK_HQ checks the split again against your new choice. When the two no longer claim tax the same way, your choice wins: the bill posts to the category you just picked, and the automatic split goes back to being a suggestion, still listed on the bill for you to confirm if you want it. A split you saved yourself is never undone this way.

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.