Record a GST/HST return you filed somewhere else

Most books arrive at TALISK_HQ with returns already filed somewhere else: QuickBooks, Xero, a spreadsheet, your accountant's software. Record each one and TALISK_HQ clears the GST/HST accounts that return settled, without changing anything in your books.

Until you do, your balance sheet still carries GST you collected and input tax credits you claimed on returns that were filed and paid months ago.

Record the return

1. Go to Ledger › Reports › Tax › GST/HST (GST/HST + QST on a Quebec book).
2. Set the period to the one the return covers, either from the Filing period list or the Filing periods tab in the period picker beside it.
3. In the filing card at the bottom of the page, click Filed elsewhere. It sits beside Mark as Filed, which is the other door: use that one only when you are filing this period from TALISK_HQ.
4. Copy the figures off the return you are holding, then click Record this filing.

TALISK_HQ confirms with Filing recorded. Your books are unchanged.

Record several past returns in one pass

A book moving to TALISK_HQ usually has a year or more of returns behind it, and there is no need to open the form once per period.

1. Go to Ledger › Reports › Tax › GST/HST returns and click Record past returns. The button appears when TALISK_HQ finds GST/HST periods from the last four years with no filing recorded.
2. Each row is one of your filing periods, oldest first. Type the figures off each return, using the same lines as the single form (101, 103, 104, 106, 107, 110 and the optional 109 check), plus the date filed and the confirmation number. Leave a row blank to skip that period.
3. Click the record button at the bottom. It counts the rows you filled in: Record 1 return for one, Record 3 returns for three, and so on.

TALISK_HQ records them oldest first, whatever order you fill them in, because a return can carry late claims from the one before it. A pass is recorded all together or not at all: if one return needs fixing, nothing is recorded, that row says why in red, and everything you typed stays where it is. Fix the row and record again.

A period that ended before your conversion date (the day your books start in TALISK_HQ) has a Paid before TALISK_HQ box on its row. Tick it when that return was paid, or refunded, before you started using TALISK_HQ. Once the pass is recorded, the period reads GST/HST paid before TALISK_HQ on the GST/HST tab, exactly as if you had said so there, and nothing is posted. On a Quebec book it covers GST/HST and QST together. When a payment was due on or after your conversion date, or your books already hold an entry after that date that may record it, TALISK_HQ asks you to confirm first and nothing is recorded until you answer: click They were settled before TALISK_HQ to record the pass with that answer. The box needs full access to the books.

Some periods cannot be recorded in a pass, and the row says which:

• A period your books already cleared by hand, after it ended. If a journal entry dated after the period moved its GST/HST out of the collected and input tax credit accounts, recording the return would clear the same tax a second time. Delete that journal entry first (unlock the period if it is locked), then record the return. Don't reverse it with a new entry instead: a reversal dated in a later period moves the tax into that period. An entry dated on the period's own last day is fine and does not block anything. The exception is an entry that sits inside a later return you recorded with Filed elsewhere while the entry was already in your books: that return, or a later one also recorded with Filed elsewhere that carried it as late claims, already accounted for it, so deleting it would report its tax a second time. TALISK_HQ checks this from what each return read when you recorded it. When it can tell, the period is no longer refused, and the GST/HST tab and the Filed elsewhere form say to keep the entry. When the returns recorded since do carry that check but it can't settle the question (something a return read has changed, two identical entries, a return recorded out of order), TALISK_HQ asks instead of saying delete, and says what it does know: which return first read an identical entry, and whether that return was recorded with Filed elsewhere or filed from TALISK_HQ. If a return recorded with Filed elsewhere read it and this is that entry, unchanged, keep it; if the entry was posted or changed after that return was recorded, or the return was filed from TALISK_HQ, delete it first. Then record the period from the GST/HST tab with your accountant's answer. A return recorded before this check existed keeps the advice above, and so does a period a later return reached back over.
• A monthly period whose return may have been recorded by hand on its due date. An entry dated on the last day of the next month clears GST/HST on the day the earlier return was due, so it can belong to either month. When its amounts match only one month's books, TALISK_HQ knows which. When they don't, the row asks which return the entry records, with a button to answer. Answer once and TALISK_HQ keeps it for that entry: see "A journal entry on a return's due date" below.
• A period a later return may already have swept is not offered at all. When a return is recorded after a period that has none, it can carry that period's tax forward as late claims, so recording the earlier period now could clear that tax twice. TALISK_HQ offers such a period only when no return recorded after it could have carried its tax: a Quick Method return never does, neither does one that posted no entry because its own period had no GST/HST, and neither does one recorded while no return for that period or an earlier one was recorded yet, because late claims only reach back to the earliest return recorded at the time. TALISK_HQ keeps the order in which returns are recorded, so a return recorded out of order, for example the June quarter before the December one, is known to have carried nothing from the periods in between, provided no return for an earlier period was already recorded when it was. For returns recorded before TALISK_HQ began keeping that order, your books cannot always show which later return carried what, especially once documents are added to a period after it was filed, and TALISK_HQ will not guess when a wrong guess clears tax twice. Ask your accountant how it was reported, and record that return from the GST/HST tab once they have confirmed it: the Filed elsewhere button shows the same warning and lets you confirm it there.
• Skipping a period with activity between two you are recording. The later return would carry the skipped period's tax into its entry as late claims, so the pass refuses. Add the skipped return to the pass.
• Recording an older return while a later one is already recorded and a period with activity sits unrecorded between them. Late claims reach back to your earliest recorded return, so the next return you file would report that period's tax again. Add that period's return to the pass.
• A period holding an earlier period's clearing. When a journal entry dated inside this period clears an earlier period by hand, and that earlier period is not recorded, recording this one first would net the entry into this period's own clearing. Record the earlier period first: delete its entry, record it, then record this one. Recording the earlier period in the same pass doesn't change that: delete the entry before the pass.
• Locked books. Each return's entry is dated at the end of its own period, so a lock through that date refuses it. Unlock on Ledger › Accounting › Period Lock, record the returns, then lock again.

Tick Lock the books through the end of the newest period you record to lock once the pass has landed; it is ticked by default. At most 16 returns fit in one pass. Start next to a return that is already recorded and work outwards from it; if none is recorded yet, start with the oldest.

The periods come from the filing frequency and fiscal year end in Ledger › Setup. If either changed in the last four years, your earlier returns will not line up with these rows. Record those one at a time from the GST/HST tab, where the period picker takes any dates.

A journal entry on a return's due date

A monthly return is due on the last day of the next month, so a journal entry that clears GST/HST by hand on a month's last day is either that month's own clearing or the previous month's return recorded on the day it was due. When the entry's amounts match neither month's books exactly, for example because it was booked at the figure you filed rather than the figure in your books, TALISK_HQ asks which return it records. Answer once, from the button beside the warning, a refusal or a row in Record past returns, and TALISK_HQ keeps the answer for that entry everywhere: the card, the pass and both buttons on the GST/HST tab.

• The earlier month's return (it was due that day). TALISK_HQ treats the entry as that month's clearing, so recording that month with the entry still there would clear the same tax twice. Delete the entry, then record the month.
• The month it closes. The earlier month stops asking about it, and the entry stays part of the month it is dated in.
• It isn't a return. Only someone with full access can say so, with a note saying what the entry is. The earlier month stops asking about it. The entry still counts as part of its own month when you file, but Books Health stops raising a card for that month because of it.

If the entry records some other return, or you are not sure, leave the question open and record the return with your accountant's answer, as described below. If the entry changes while you are answering, TALISK_HQ asks you to look again rather than saving an answer about an entry whose months or amounts you did not see.

An answer stops applying when the entry changes (its date, an amount or an account), when it is deleted, or once the month it is dated in is recorded. From then on, which return it records no longer decides anything: what decides it is whether a return recorded since already took the entry into account, whichever return that was (a later return's late claims can be the one). When the first return to read the entry was recorded with Filed elsewhere and nothing those returns read has changed since, TALISK_HQ knows it did: keep the entry, and record the earlier month if you filed it somewhere else. Otherwise the earlier month still asks, and says what TALISK_HQ does know: which return first read an identical entry and whether it was filed from TALISK_HQ (then the entry has to go), that no return has read it (then it has to go too), or that there is no record to go on. Your accountant has the last word. Answers never outrank your books: if a later document makes the entry match the earlier month's books exactly, the entry is treated as that month's clearing whatever you answered. Every answer about an entry that still exists is listed under Entries you've placed on GST/HST returns, where you can change it or choose Ask me again.

When your books show a return TALISK_HQ has no record of

Books Health raises a card when entries in your books look like a return was filed but no filing is recorded for that period: a GST/HST remittance or payment posted for a period that is not marked filed, or a journal entry that clears the collected and input tax credit accounts together, including one that pays the balance from a bank account in the same entry. It waits until that return's due date has passed, so it never contradicts the filing deadline reminder. Record past returns on the card opens the pass above.

The card is urgent when a return filed elsewhere comes after your last recorded filing. Until it is recorded, TALISK_HQ treats that tax as never reported, so the next return you file from TALISK_HQ would carry it forward as late claims and report it a second time. Record it before you file again.

When a later recorded return has probably already carried a period's tax, or TALISK_HQ cannot tell whether it did, the card says so and opens GST/HST returns instead of offering to record the period.

A hand entry that only records a refund or a payment, or that moves tax between the two accounts to correct a mistake, does not raise the card: those settle or fix a return rather than record one. Neither does an adjusting entry that touches the tax accounts alongside others: the card only reads an entry that clears GST collected and input tax credits into GST/HST payable or straight to a bank account, the way a return does. An entry you have said isn't a return doesn't raise it either, for as long as that answer stands.

When TALISK_HQ stops you, and how to go ahead

Filed elsewhere and Mark as Filed both check the period before they record anything, because each one clears the GST/HST accounts and a return recorded against tax that was already cleared clears it twice. The same warning shows on the GST/HST tab above the two buttons before you press either, so you can see it before you file with the CRA.

Some of these checks cannot be passed. The message says what to fix:

• A filed return already covers part of the period. Use a period for the dates it does not cover instead.
• A journal entry dated after the period already clears it by hand. Delete that entry, then record the return. A year-end adjustment can't be deleted on its own: discard that year's adjustments on Ledger › Accounting › Year-End and post the others again without the GST/HST clearing. If the entry also paid the return from the bank, deleting it removes that payment too, so record the payment again afterwards: from its bank line on Ledger › Banking (Tax payment, or Tax refund for money in), or with Record payment / refund on the GST/HST tab if it has no bank line.
• The period holds an earlier period's clearing. Record the earlier period first, as described above. This applies even when your earlier returns mean this one would carry that period's tax back as late claims, because deleting the entry afterwards would then report that tax a second time.

Two returns are never recorded on the same books at the same moment. If another one is being recorded, TALISK_HQ asks you to try again in a moment. If something that affects these returns changes before a pass in Record past returns is recorded, for example a journal entry that clears one of them by hand or another return recorded in between, nothing is recorded and each row that changed says why.

The others are TALISK_HQ reasoning from your books, and your accountant can settle them: a later return may already have carried this period's tax, a journal entry on a return's due date may belong to either month (answer which return it records and TALISK_HQ stops asking), or recording this return would carry an unrecorded period's tax into it as late claims. For these, tick My accountant has confirmed this is right, and I want to go ahead, write what they confirmed under What did they confirm?, and record it. TALISK_HQ records the return exactly as it would have, and GST/HST returns shows Recorded over a warning with what you wrote.

Mark as Filed also asks about two things only a return filed from TALISK_HQ needs. A journal entry that clears GST/HST by hand inside the period nets the worksheet down, so its figures are not that period's return. And a period whose return entry is already posted looks filed already; if it was filed somewhere else, record it with Filed elsewhere, which saves the figures on that return.

What to type

The fields carry the CRA's own line numbers, so each one is a box on the return in front of you:

• Line 101 — Total sales and other revenue
• Line 103 — GST/HST collected or collectible
• Line 104 — Adjustments to be added
• Line 106 — Input tax credits (ITCs)
• Line 107 — Adjustments to be deducted
• Line 110 — Instalments and other payments

Lines 101, 103 and 106 are on every return, so fill in all three. A blank is a dropped field, not a nil line: where the return shows nothing, enter 0.

Line 109 — Net tax, as printed on the return is optional, and it is a check rather than a figure. TALISK_HQ works net tax out from the lines above. Type 109 as well and it confirms the two agree before recording anything, which is free insurance against a slip on a record you cannot edit later.

Tick This return also covered QST (Revenu Québec) for the combined Quebec filing, then fill in QST collected and QST input tax refunds (ITRs).

Date filed (optional), Confirmation number (optional) and Notes (optional) are the details GST/HST returns shows you afterwards. The filing date has to fall between the end of the period and today.

The box that locks your books through the period end is ticked by default, so a return that has gone to the authority cannot quietly change behind it. Untick it if you still have work to post into that period, and lock it later on Ledger › Accounting › Period Lock.

TALISK_HQ records the return, it does not file one

This door is for a return that has already gone to the authority. TALISK_HQ produces the figures and the worksheet; you or your accountant file. Nothing here submits anything to anyone.

It also never restates your books. What you type is kept as the record of what you filed and is used for nothing else, so your ledger carries on saying what your documents say. The only entry TALISK_HQ posts is the same remittance that Mark as Filed posts, worked out from your own ledger rather than from anything on the form.

The entry is dated at the end of the period, not today

Record a March to May return in September and the GST accounts clear as at 31 May, because that is the period the return settled. Dating it today would leave your balance sheet carrying already remitted GST on every date in between, which is the problem this feature exists to fix. When you filed is kept separately, in Date filed (optional).

This is the one thing to watch if your books are locked. A lock through the end of that period refuses the backdated entry and tells you so, rather than quietly posting it somewhere else. Unlock on Ledger › Accounting › Period Lock, record the return, then lock again.

Your books will not match the return, and that is normal

Two systems rarely split a period the same way. A sale lands a day either side of the quarter end; the other system claimed an input tax credit on the next return instead of this one. Both sets of numbers can be right, and neither is an error.

So TALISK_HQ measures the difference once, as you record the filing, and keeps it. Your books carry on moving and the return never will, so a comparison worked out fresh every day would answer a different question every day.

Open Ledger › Reports › Tax › GST/HST returns. The period reads Filed elsewhere rather than Filed. Click the arrow at the start of its row to open it: under the return itself, Compared to your books has four columns: Line, Your books, As filed and Difference. The difference is the return less your books, so a plus means the return reported more than your ledger does. Nothing in it is styled as a problem, because it is not one, and opening it changes nothing.

Each filed return on GST/HST returns also shows what it came to in the Owing / refund column, taken from the figures you recorded, so it does not move when your books do. A dash means no figures were recorded for that return. Click the arrow at the start of a row, or anywhere on the row, and it opens in place: the balance, whether it has been paid, every line as filed, and on a return filed elsewhere the comparison with your books. Open in GST/HST under it takes you to the worksheet for the same period. A period that is not filed yet opens to say there is no return to show, with the same link to the worksheet.

On the GST/HST tab the same period shows the usual green Filed banner, and underneath the worksheet a note saying these are the figures from the return you filed elsewhere, that your books are unchanged, and where to compare them.

PST is not on the GST/HST return, so the return you record says nothing about it. PST has its own PST tab, on each province's own filing period, and its figures always come from your books as they stand today. The CSV export labels its PST section that way.

When the difference is large, TALISK_HQ asks what is missing

A small difference is normal. A large one usually means something is not in your books yet, such as a quarter's store sales or a missing bank statement. So when your books for the period come out far from the return you recorded, TALISK_HQ asks about it: at least $100 apart, and at least a tenth of what you filed. The question names both figures, for example "Your books show a $257.77 refund for Mar–May 2025, but you filed $2,197.09 owing", says what TALISK_HQ thinks is missing, and appears in your Today list and at the top of Ledger › Setup › Build from documents.

• I'll add what's missing puts it aside for a week. If the difference is still there then, TALISK_HQ asks again.
• The difference is right tells TALISK_HQ the two numbers are both correct. It does not ask about that period again unless the difference later changes by at least as much again.

Answering changes nothing in your books and posts nothing, and the return you recorded stays exactly as you typed it. Once the missing documents are in and your books come close to the return, the question goes away on its own. TALISK_HQ also looks again overnight whenever an entry dated inside a period you recorded is added, changed, moved or removed later, so a change to a period that matched is not missed. A period you filed from TALISK_HQ is never asked about this way; Books health tells you if its books change after you filed.

The comparison has three answers, not two

• Your books agree with the return you filed, line for line. They match.
• A table of lines. They differ, and this is by exactly how much.
• Your books were not compared against this return. TALISK_HQ could not work out its own worksheet at the moment you recorded the filing, so there is no comparison to show. That is not the same as agreement, and the panel says underneath why it could not look.

A period with nothing usable stored reads No comparison between your books and this return was recorded. for the same reason: no answer rather than a clean one.

One record per period, and it is frozen

A period can be recorded once. The figures freeze the moment you press Record this filing, exactly as they do when you mark a period filed from TALISK_HQ, and a second attempt is refused. Check the numbers before you record, which is what line 109 is for.

Three more refusals, all deliberate:

• A period already marked filed. Its filing is recorded already. If TALISK_HQ holds no copy of the figures that return reported, use Record the figures you filed on that period's GST/HST tab instead: it keeps the figures and posts nothing, so whatever that period's filing posted, or did not post, stays exactly as it is. See "Your books changed after you filed".
• A period that has not ended yet. It cannot already have been filed, and Mark as Filed refuses it for the same reason.
• A period that is not GST/HST. QST is remitted on the same return, so record the GST/HST period covering those dates. A PST return is recorded on the PST tab, against the province's own period.

The money is a separate step

This records the return, not the payment. If you paid the balance or received a refund, record that on its own: Record payment on the period's row in GST/HST returns, Record payment / refund on the GST/HST tab's banner, or the Tax refund action on the bank line the deposit arrived on. If the payment or refund was already booked by hand, for example with your old system's closing entries, the GST/HST tab's dialog and the bank line's Tax refund and Tax payment actions all show that entry before they record anything, so the money is not booked twice. They also show a deposit or withdrawal of the same amount that is already categorized to another account. If an entry already records the money, record nothing and leave the bank line as it is: click Link a settlement on the GST/HST tab's banner and link that entry, so the period reads paid without booking the money twice. If the only record is that categorized bank line, mark it with Tax refund or Tax payment on Banking instead of recording it on the GST/HST tab.

A payment or refund dated before your conversion date is refused by all three: it is already in your opening balances, so there is nothing to record. That is the usual case for a return filed and paid before you moved to TALISK_HQ: to have such a period read paid, choose It was settled before TALISK_HQ under Link a settlement, which posts nothing. A return that ended before your conversion date but was paid, or refunded, on or after it is recorded as normal. A refund dated before its period's last day is refused too, and a payment dated before its period starts is asked about first.