Rules for a supplier's bank charges

A rule is TALISK_HQ's standing answer about a supplier: the category its charges take, the sales tax it charges, and the document that proves it. You already have rules, whether or not you knew it. The first time you code a bank charge and set its sales tax, TALISK_HQ remembers that answer for that supplier, which is why the next charge arrives already coded. Ledger › Banking › Rules is where you can finally see them and correct them.

One row per supplier. Each row shows the supplier, its category, its sales tax, whether TALISK_HQ guessed the category or you chose it, and how many times it has been used. A guess is worth a second look; your own choice is not.

Change the answer and it saves itself. Pick a different category or a different sales tax and the rule updates. From then on the next charge from that supplier arrives coded that way.

A rule never overrides a bill. If a charge is matched to a bill or a receipt, that document decides its category and its sales tax, and the rule does not apply to it at all. Approving the bill is what recorded the expense and claimed the GST/HST, so a rule cannot add a second claim on top. Rules answer for the charges that have no document behind them, which is exactly what they are for.

It never re-codes what is already recorded. This is the important part. A rule can sit behind a year of posted entries. If changing it re-posted them, one click on a settings screen could move a sales-tax figure you had already filed, so it deliberately does not. Charges already in the books keep the coding they were posted with.

To bring a changed answer to old charges, open the row, pick one of the charges listed under Charges this rule stands behind, and use Apply to all beside that line's sales tax on Banking. That route exists because it tells you what it is about to do: it counts the charges, quotes the tax it would claim, skips anything in a closed period, and never overwrites a choice you made on a single line.

Attach the proof for a charge that never has a receipt

Every bank line in TALISK_HQ carries the same caveat: a receipt is the only proof of what a supplier actually charged. For a recurring fixed charge that is impossible to satisfy. Nobody issues a monthly receipt for storage-unit rent, and nobody ever will.

But there is a document: the agreement. Open a rule and attach the lease, the service agreement, or a screenshot of the rate clause (drop a file in, click to browse, or just paste a screenshot from your clipboard). Attached to the rule, it stands behind every charge that rule touches, which is a better answer than chasing a receipt that does not exist. That turns the rule from a convenience into the paper trail for the whole class of charges, which is exactly what an accountant or a reviewer will ask for.

Attach as many as you need. Once the first one is on, an Add another document button appears. Two reasons that matters:

• The price changed. Attach the new agreement and keep the old one: it is still the proof for the periods it covered.
• One supplier, two things. Two rental units at the same storage facility share one rule, so attach both leases.

There is no limit. Each document has its own View, Download and Remove, and removing one leaves the others alone.

One document can cover several charges, which a receipt cannot. A receipt attaches to a single bank line, so a statement covering four charges has nowhere to go on the Bills and Receipts side. Attached here it stands behind all four. Advertising is the common case: one monthly statement, several card charges through the month.

It also stops TALISK_HQ asking for a receipt on those charges. The books-health card that says a charge has no proof attached counts a supplier's agreement as proof, because it is the stronger one. Remove the last document from a rule and the charges start being asked about again.

Rename a document by typing over its name. Worth doing when two files arrive from a scanner both called lease.pdf, since the name is all that tells them apart in the list.

Files are stored encrypted, the same way every bill PDF and receipt image is, and nothing here touches any of the charges.

Tell TALISK_HQ a supplier never sends a receipt

TALISK_HQ raises a books-health card when a categorized bank charge has no receipt or bill attached, because without one you may lack proof of the expense if CRA asks. It already knows about the kinds of spending that never produce a document at all: bank service charges, loan and card interest, and payroll. What it cannot know is which of your own charges arrive silently. Rent taken by pre-authorized debit, a subscription charged straight to the card, a monthly fee under an agreement: real expenses, correctly coded, with no receipt now and none coming. Not all of these are suppliers, which is why the setting talks about the charge rather than who is behind it.

Open the charge on Banking, expand the row, and under Linked to choose Never expect a receipt. That is a standing answer about the charges, not about the one line, so every past and future charge that matches stops being counted. Four identical monthly debits clear in one go.

Each rule set that way shows a no receipt expected tag in this list, and expanding it gives you a Receipts setting you can put back to Expect a receipt whenever you want.

Two things worth knowing:

• It records nothing and changes no figures. The charge keeps its category, its sales tax and the entry it already posted. The only thing that changes is whether TALISK_HQ asks you for a document.
• If there is an agreement, attach it instead. The section above is the stronger answer where a lease, contract or statement exists: it is the proof, rather than the absence of one, and it clears the card just the same. Use this setting for the suppliers where no document exists at all.

Merge two rules that are really one supplier

One supplier often charges under more than one descriptor. Intuit bills as both INTUIT *QBO and INTUIT *QBOOKS ONLINE, so a book ends up with two rules for one company, and an answer set on one does not reach the other.

Open the rule you want to keep, expand it, and press Merge rules. Pick the duplicate from the list and confirm. From then on:

• Charges under either descriptor follow the surviving rule: its category, its sales tax, its receipt setting, and the evidence attached to it.
• The duplicate's evidence documents move onto the surviving rule, and its use count folds in.
• The row shows a covers N descriptors tag, and expanding it lists them under Also answers for so you can see exactly what was folded in.

If the two rules disagree, TALISK_HQ asks before merging. A different category, a different sales-tax treatment, or a receipt setting that only one of them has: each one is put to you as a choice between the two rules' own answers, and nothing is decided silently.

Merging moves nothing that is already recorded. Like every other edit on this screen, it changes what future charges inherit and which rule answers for a descriptor. Every posted charge keeps its coding, its entry and its tax exactly as it was.

Rename a supplier

Type a new Name on the row and press Enter (or click away). This is only a label: matching is done on the bank descriptor itself, so renaming never changes which charges a rule covers.

Some rules show as Unnamed supplier. Those were created before TALISK_HQ started recording a readable name, so they have none until something touches them. Give them one here.

Clearing the name puts the automatic one back the next time the rule is used, so a name you regret is never permanent.

What you cannot do here, and why

• You cannot create a rule. One appears when you code a charge, which is what teaches it.
• You cannot delete a rule. Clearing its category and sales tax is the reversible way to stop it applying, and it keeps the history of what the rule used to say.

These are not the same as vendor rules

Both are rules about a supplier, and they match on different evidence:

• These rules match a card or bank descriptor on a statement line, like STORAGE MART #4471 VANCOUVER BC.
• Vendor rules (Ledger › Expenses › Vendor Rules) match the sender's email domain on a bill that arrives as a document, and carry the extra things a bill needs: a currency, a portal link, auto-approve.

A card descriptor has no email domain and an email has no card descriptor, so the two stay separate. Set both if a supplier reaches you both ways.