Categorize bank transactions

On Ledger › Banking › Transactions, each account holds one list of its transactions in date order, newest first. Statements, a connected bank feed, file imports and anything you typed yourself all sit together in that one list, with a small note under each date saying where the line came from.

To categorize a line:

1. Click the Category cell on the transaction. The row opens for editing with the category picker focused. (Clicking the date, description or amount opens the same editor focused on that field instead; the pencil on the right of the row does the same. The arrow on the left of the row opens its details panel rather than the editor.)
2. The picker opens with the cursor already in a search box, so you can start typing straight away: type an account number to jump to that band (5 narrows the list to your 5000s, 51 to the 5100s), or type any part of an account name. Keep typing to narrow further, and press Enter to take the highlighted account.
3. Or just pick from the list: it starts on — none —, then lists your own accounts first under Your chart — expenses, then the extra groups that apply to your book (Assets / Capital, Owner / Shareholder, Prepaid balances), and finally the built-in Standard categories at the bottom.
4. Picking the account saves it right away: there is no check to click for a category. Edits to the date, description or amount still need the check to Save (or ✕ to Cancel, or press Esc, which throws the typing away and closes the editor). If you were part-way through one of those when you picked the category, the row stays open so you can finish it.

Categorizing an unmatched line posts a journal entry behind the scenes: the expense against your bank or card. Change the category later and TALISK_HQ re-posts it automatically.

Claiming the GST/HST on a charge

A bank line is what left your account, so the sales tax is already inside the amount. On its own, categorizing puts that whole amount into the expense and claims no input tax credit. To claim it, open the row's details and set Sales tax:

• Standard rate uses your province's full rate. In BC that is GST 5% plus PST 7%: the GST half is claimed as an input tax credit and the PST stays part of the expense, because PST is not recoverable.
• GST/HST only is for a supplier who charged the federal tax and no provincial tax. It claims more than Standard does, so it matters: on a $78.40 charge in BC, Standard claims $3.50 and GST-only claims $3.73.
• Zero-rated, Exempt and No sales tax all leave the full amount as the expense. Use the last one for a supplier who charged no Canadian tax at all, such as a US supplier.
• Not set is the same: nothing is claimed.

TALISK_HQ works the rate out from your own province, because Canadian sales tax follows where the buyer is, not where the supplier is. So the only thing you are telling it is which taxes the supplier actually charged.

A matched line takes its tax from the bill

If the line is matched to a bill or a receipt, there is no Sales tax choice to make and the box does not offer one. The document decides: approving the bill is what recorded the expense and claimed the GST/HST, so the details show what the bill charged and what was claimed, with a link to the bill itself. Supplier rules, category rules and account defaults do not apply to a matched line, and nothing you set anywhere else can add a second claim on top of the bill's. To change the tax, change it on the bill, or unmatch the line first.

Whichever you pick, TALISK_HQ shows you the split before you move on: the amount going to the expense, the tax being claimed, and anything that is not recoverable. Check it against the receipt the first time you code a supplier.

Two things then happen automatically. What you pick is remembered for that supplier, so the next charge from them starts the same way. That memory is a rule, and you can see and correct it on Ledger › Banking › Rules (you can also attach the lease or agreement there, which is the answer for a recurring charge that never comes with a receipt). And if you want a whole account to work that way, open Ledger › Accounting › Chart of accounts, edit the account and set Sales tax on purchases; every line you code to it afterwards inherits that.

Catching up a backlog

Coding one charge can code the rest from that supplier. When you set a category, the row's details show Other charges: how many other charges from the same supplier have no category, what they add up to, and a button to code them all the same way. Nothing is written until you press it, because coding a charge posts a new entry for money that is not in your books yet.

You do not need to have set the sales tax for this to appear. If the destination account or this supplier already answers the tax question, the newly coded charges inherit that answer too, and the offer says how many will, so a change to your GST figures is never a surprise.

When you set the sales tax on a line, TALISK_HQ does the same check for the tax: if other transactions from that supplier are still missing theirs, it tells you how many, over what dates, and how much tax is sitting there, and offers Apply to all.

If some of those transactions have no category yet, that offer can code them the same way as this one at the same time. It is ticked by default and says exactly what it will do, because it is the heavier half: coding a transaction posts a new entry for money that is not in your books yet, where setting the tax on an already coded one only reshapes an entry that exists. Untick it and only the tax is applied.

Three things neither offer will do. It never changes a line where you already chose a treatment yourself, so a bulk apply cannot undo your own work. It never re-codes a transaction that already has a category, only blank ones (the ones it leaves alone are counted so you can see it did). And it never touches a transaction in a closed period: those are counted and reported, but left alone, because changing them would restate a return you have already filed. Unlock the period first if you really want them included.

If you categorize a transaction and nothing has answered the tax question for it, TALISK_HQ opens the details and highlights the Sales tax box so you are asked once rather than having to remember.

You can change any single line at any time, and TALISK_HQ re-posts its entry. A line already claiming tax shows a small TAX tag beside its category.

In the journal entry, the recoverable tax gets its own account (1110 GST/HST Input Tax Credits) and anything non-recoverable gets its own line on the expense account, labelled with the rate that produced it, for example PST 7% (not recoverable). PST cannot have an account of its own because it is part of what the purchase cost you, not something you reclaim; splitting it onto its own line means you can still see it without the expense account saying the wrong thing.

If you have the receipt, uploading it from the line is the better route: the receipt carries the tax the supplier actually charged, rather than a good-faith reconstruction of it.

If a receipt for it never exists, say so instead. Expand the row and choose Never expect a receipt under Linked to. That covers every charge like it, past and future, so an auto-debit like rent or a subscription stops being counted as missing proof. It changes no figures, and you can put it back at any time in Ledger, Banking, Rules.

Money-in lines follow your pick too. A deposit or card credit categorized to an expense account books as a refund against that expense (a returned tool categorized to Small Tools cancels the original charge), one categorized to an asset, owner or loan account books against that account, and a deposit with no category is treated as income. So a purchase and its later refund, both categorized the same way, net to zero in that account.

A refund gives the sales tax back too

When a supplier refunds a purchase, the money comes back with the GST or HST that was on the original charge, and you claimed that as an input tax credit when you paid. So the refund has to give it back, or you are still claiming credit for tax you were never charged in the end.

Code the deposit to the same expense account you used for the purchase and the field reads Sales tax refunded. Pick what the supplier charged, exactly as you would on the charge itself, and TALISK_HQ splits the refund the same way in reverse: the expense comes down by the amount without tax, and the GST or HST goes back off your input tax credits. On a $123.14 return in British Columbia at the standard rate, $5.50 of GST comes off the credits you are claiming, $7.69 of PST stays with the expense because PST was never recoverable, and the expense drops by $117.64.

Under the field is Refund of, where you can point the deposit at the charge it reverses. This matters when your tax situation changed between the two. Say you bought something in March, claimed the GST on it, then went onto the Quick Method in May, and the supplier refunded you in June. Judged at the refund's date the answer is that a Quick Method book claims nothing on its everyday purchases, so nothing would come back, and the credit you claimed in March would be left standing. Point the refund at the March charge and TALISK_HQ works it out at the date you actually claimed it, which is the honest answer.

Leaving it unlinked is fine and is what TALISK_HQ has always done: the sales tax is worked out at the deposit's own date. Nothing guesses the link for you. A refund can arrive months later, for part of the amount, under a different name on your statement, and a wrong guess here would change a figure you have already filed, so it is left to you to say.

Two things worth knowing. TALISK_HQ can never give back more than the same purchase would have claimed, so a meal refund reverses the same half the CRA lets you claim in the first place, and a book that is not registered for GST reverses nothing because it claimed nothing. And a deposit that is income is left alone: the field only appears on a money-in line you have coded to an expense or an asset account, because that is a purchase running backwards. Tax on money you have collected is handled by your invoices and your store payouts, never here.

If you never set anything, the refund books the way it always did, with the whole amount coming off the expense. Nothing changes behind your back.

Recoding a batch at once

If a run of transactions went to the wrong account, you don't have to open them one at a time. Search for the category you used (typing an account name narrows the list to the lines carrying it), tick the ones you want with the checkboxes, and press Recategorize in the bar that appears.

Picking the new account shows you what will happen before anything is written: how many of your selection will move, the total, the date range, and a line for anything it will leave alone with the reason. Press Recode to apply it.

Four kinds of transaction are left alone, and the preview names each one: already matched to a bill, invoice or payout (that match sets the category, so unmatch it first); marked as a transfer between your own accounts; dated before your books opened; or sitting in a closed period, because recoding those would restate a return you have already filed. Unlock the period first if you really want them included.

If the account you are moving to has a sales tax set on it, the preview says how many lines will pick that up, since recoding changes what they claim. Lines where you set the tax yourself keep what you chose.

Lines that are already matched to a bill, an ecommerce payout, or an invoice payment don't need a category: they show an italic label like Bill payment or Ecommerce payout instead, because the match already booked the money. A transfer between your own accounts reads the same way and names the other side, for example Transfer → RBC Visa. In every one of these cases adding a category would book the same money twice, so the label is the answer, not a gap waiting to be filled.

Seeing what a line is and where it landed

Click the arrow on the left of a row to open its details. That panel shows three things:

• This transaction: the raw bank memo when it differs from the merchant name, which account and statement it came from, how it was imported, and the foreign amount, rate and Conversion cost when there is one. Click the statement's name to open the statement itself, so you can read the original page the line was pulled from without leaving the list.
• Linked to: the bill, receipt, customer invoice, payout, refund or transfer it belongs to, each with a link straight to that document.
• Where it's booked: the actual journal entries the line posted, account by account. This is where you see the other side of a transfer, or which expense account a matched bill landed in. Each account links through to GL Detail.

Why a foreign purchase shows a surprising rate

When you buy in another currency on a card held in your book's currency, the row shows the original amount and a rate under the figure, like USD $155.78 × 1.4312. That rate is the effective one: your card's conversion charge is already baked into it, so it is not the Bank of Canada rate your books post at.

This is why a purchase and the refund for that same purchase can show rates several percent apart on the same day. The charge is added when you buy and taken back off when you are refunded, so a single conversion charge appears as two very different rates.

Under the rate, the row shows what the conversion actually cost:

• Fee is your card's conversion charge.
• FX loss or FX gain is genuine rate movement between the date of the bill and the date you paid it.

A line can show both, because they are different things. Both figures are read from the entry the payment posted, so they tie to your books rather than being worked out on screen. A line shows nothing there when its entry recorded no such cost, which is the normal case for anything bought in your own currency.