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. Ledger › Banking › Rules is where you can see them and correct them.

A rule you set codes the next charge and posts it. When that supplier's next charge arrives from your bank feed or a statement you import, TALISK_HQ applies the rule's category, claims the sales tax the rule remembers, and writes the journal entry. You do not have to open it. That is the whole point of a rule: the subscription that bills on the 24th of every month should not need a decision every month.

A rule TALISK_HQ guessed does not do that. The list tells you which is which. Your own answer gets replayed because it was yours; a guess waits for you, because a guess that posts itself is TALISK_HQ putting figures in your books that nobody confirmed.

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 is 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.

Make a rule from a charge you just coded

Open the charge on Banking, give it a category, and under Next time choose Remember this. From then on that supplier's charges are coded and posted for you.

The button says one of three things, depending on what TALISK_HQ already knows about the supplier:

• Remember this: there is no rule yet. This makes one.
• Update the rule: the supplier already has a rule saying something else. Perhaps they changed what they bill you for, or the rule was wrong.
• Confirm this: TALISK_HQ guessed the category and guessed right. Confirming is what turns a guess into your own answer, and only your own answers are used to code charges automatically.

If a supplier already has a rule saying exactly this, there is nothing to offer and no button appears.

It changes nothing that is already recorded. Charges already in your books keep the coding they were posted with, and no entry is written or rewritten. Only what future charges inherit changes. To bring the answer to charges already recorded, use Apply to all on the same charge, which counts them and quotes the dollars first.

It says nothing about sales tax. Choosing a category tells TALISK_HQ what you bought, not what the supplier charged you, and it will not claim a sales tax credit you never said was there. The tax answer is remembered separately, when you set it on a charge yourself.

When TALISK_HQ suggests a category

Open an uncoded charge and you may see a Suggestion with a single button, Code as something. Tap it and the charge is coded and recorded exactly as if you had picked that category yourself.

It comes from one of two things, and neither is a guess made on the spot:

• You have coded this supplier before. If you coded the last three charges from them the same way, that is the suggestion. When your own history is split, it says so: "You coded 2 of the last 5 charges from this supplier this way."
• TALISK_HQ worked out a category for this supplier but has not been told it is right. TALISK_HQ will not record entries from its own guess, so the charge waits for you. Using the suggestion once is what makes it the standing answer.

It costs nothing and it asks no AI. Both answers are already in your books, which is why the suggestion only appears when you open a charge rather than being worked out for every charge as it arrives.

Nothing is suggested for a charge you have already coded, one matched to a bill or receipt, a transfer between your own accounts, or anything dated before your opening balances.

Why a rule did not code a charge

A rule stays out of the way whenever coding a charge would be a guess about money rather than a replay of your answer. If a charge from a supplier you have a rule for is still sitting uncoded, it is one of these:

• TALISK_HQ guessed the rule rather than learning it from you. The row says so. Code one charge the way you want it and use Apply to all, and it becomes your answer.
• The charge is already matched to a bill, a receipt or a payout. That document is what recorded the expense, so the rule has nothing to add.
• You marked it a transfer between your own accounts. Moving your own money is not spending, so it is never coded to an expense.
• It is in a foreign currency. Those need a rate before anything can post.
• It falls in a period you have closed. TALISK_HQ does not put entries into a return you have already filed. Record it as a late charge on the line itself if it belongs there.
• It might be a duplicate. If the same charge arrived from both your bank feed and a statement you imported, TALISK_HQ holds both until you say which is real, rather than booking the expense twice. Clear it under Banking, Review.
• It is a deposit waiting to be settled against a payout or an invoice. That sale is already in your books; coding the deposit as income would count it twice.
• The rule's category no longer exists on your chart of accounts. Pick a current one on the rule and it starts working again.
• Your bank started sending a different name for the supplier. A rule is keyed on the descriptor your bank writes, so a tidier merchant name from a new feed reads as a different supplier and the rule answers for nothing. See When a bank feed renames a supplier below.

There is one more, and it is deliberate: a charge you type in yourself is never coded for you. You have the category picker open in front of you, so TALISK_HQ leaves the choice where it already is.

When a bank feed renames a supplier

A rule is keyed on the supplier's descriptor as your bank writes it, not on the name you see on the row. So the day a bank or card feed starts sending a tidier merchant name for the same supplier, that reads as a new supplier, and the rule stops firing. The charge then arrives blank every month while the Rules tab still shows the rule sitting there looking perfectly correct.

The common cause is an account switching from imported statements to a live bank feed. The statement prints something like GOOGLE *ADS4133708507 855-222-8603 ON 74537886182401844065176 and the feed sends Google Ads.

Open the charge on Ledger › Banking and expand the row. Under Supplier rule TALISK_HQ offers Same supplier whenever it can see exactly one existing rule whose own charges read like this one, and it names both spellings so you can check it before you agree. One tap joins them.

Linking posts nothing and codes nothing. It records that this descriptor belongs to that rule, so the supplier's next charge is coded for you. The charge in front of you keeps whatever category it already has, and so does everything already recorded. To bring the rule's answer to charges already in the books, open one of them and use Apply to all beside its sales tax, which counts them and quotes the dollars before it changes anything.

TALISK_HQ offers this only when the answer is unambiguous. If two of your rules could both be this supplier, or the two spellings have nothing distinctive in common, nothing is offered. Code the charge yourself and use Remember this, which gives the new spelling a rule of its own.

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 from scratch here. A rule is made from a real charge, which is what teaches it what to match on. Code a charge on Banking and use Remember this beside 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.