How payouts land in your books

Once a store or processor is connected, TALISK_HQ handles payouts for you. On each sync it books every payout summary to your ledger (sales, fees, and tax) and then matches it to the bank deposit when that deposit lands. You mostly do nothing.

To review them, open Ecommerce › Payouts (for a processor-only book (Square, PayPal or Stripe with no storefront) there is no Ecommerce section; its payout revenue shows on the Ledger Dashboard instead):

• Filter by source (Shopify, Stripe, Square, PayPal) and by reconciled status.
• Each row shows Gross, Fees, Net, and whether it's Matched to a bank deposit or still Open.

If a payout matched the wrong deposit (it can happen when deposits arrive close together), click Unmatch to unlink it: the deposit goes back to the pool and re-matches automatically or by hand. Foreign-currency payouts are shown but not posted yet.

Sometimes two deposits of the same amount land in the same few days, or two payouts are for the same amount, and TALISK_HQ can't tell which deposit is which payout's. It doesn't guess: the payout stays Open with a Link deposit button. Click it, and TALISK_HQ lists the bank lines that fit the payout's amount and dates; pick the one that is its deposit. Nothing new is booked, because the payout already put that money in your books, and Unmatch undoes the link. Until a payout like this is linked, its deposit can't be matched to a bill or a credit note either, because that would count the same money twice.

If you categorized the deposit before its payout matched it, the match takes over. The payout already put that money in your books, so the entry behind your category is removed and the money is counted once, not twice. The line keeps the category you picked, and Unmatch puts its entry back. If that category's entry is dated in a period your books are locked through, the deposit is left unmatched instead, because a locked period can't be changed, and the books-health card for payouts with no deposit names that line and says why.

Unmatch changes your books too, so a locked period stops it as well: when the payout's entry or the deposit's category is dated inside the period your books are locked through, Unmatch is refused and says so, with both dates. Move the lock back under Ledger › Accounting › Period Lock, unmatch, then lock the period again.

More than one store

If your business has more than one storefront connected, the store selector at the right of the Ecommerce tab bar narrows Ecommerce › Payouts to one store's payouts, and the count of payouts still waiting for a bank deposit follows it. Square, Stripe and PayPal payouts belong to a payment processor rather than a storefront, so they are listed only under All stores.

A payout marked "Held"

A payout tells you what was deposited, but not what was sold. The sales and the sales tax behind it come from the orders themselves, so if those orders have not reached TALISK_HQ yet the payout is Held: nothing about it is recorded until they do. Hover the badge and it says how many orders are still missing.

This normally sorts itself out within a sync or two, and nothing is needed from you. It shows up most often when a store is paid out monthly, or when an order was placed weeks before it shipped and was paid for, because TALISK_HQ pulls the last two weeks of order activity on each sync.

Holding it is deliberate. Recording the deposit without the sales behind it would put the money in your books with no revenue and no GST or QST against it, which understates both until somebody notices.

A payout that went in without its sales

Before September 2026 a Shopify payout could be recorded before its orders had arrived, instead of being held. When that happened the deposit went into your books with no sales and no GST or QST behind it, and the whole amount sat in 1150 Ecommerce Clearing. Your revenue and your sales-tax figures were understated for those dates.

TALISK_HQ finds these and says so: open Ledger › Dashboard and look at the books-health panel, which lists each one by its date and its amount. Nothing is corrected for you, and it takes two steps. Review correction fetches that payout's orders from Shopify and shows you exactly what would be recorded: the sales, the shipping, the GST or QST, and the clearing amount released. Nothing is written until you press Post correction.

The review step also tells you what date the entry will carry, and why, before you approve it. There are two answers:

• If the payout's own period is still open and you have not filed a return covering it, the correction is dated in that period. Your March sales stay in March, which is where they belong, and nothing about a return is involved.
• If that period is already closed in your books or marked filed, the correction is dated today instead, and the sales tax lands on the return you are working on now. That is what TALISK_HQ does with a correction found after filing, and it is what a bookkeeper usually does by hand. There is another route, which is asking the CRA to adjust the original return, and whether a particular correction should go that way instead is your accountant's call.

Either way the original entry is not changed or removed, so a return you have already filed still says what you filed.

If Shopify no longer has the orders, or what it sends still does not add up to the deposit, TALISK_HQ refuses and records nothing. Those are worth going through with your accountant.

A payout can pay for sales on both sides of the day your books start, and that one is handled rather than refused. TALISK_HQ records only the sales made after your books started, with their tax, and leaves the older part sitting in Ecommerce Clearing, because those sales are already counted in your opening balances. The review step shows you that split before you approve it.

One refusal is not a problem at all: if the sales behind the payout were made before your books started in TALISK_HQ, TALISK_HQ says so and stops. Those sales are already counted in your opening balances, so there is nothing to record again. See "Payouts that straddle the day your books start" below.

When you refund a customer

A refund inside a payout is money going back out, and part of it is usually the sales tax you collected on that sale. TALISK_HQ splits it: the goods or shipping come off your sales, and the GST, HST, PST or QST comes off what you owe the tax authority. That is true whether you refunded the whole order or only part of it, such as the shipping.

The split comes from the order's own tax lines, so a refund to a customer in a province you charged no tax in reverses no tax, and a refund on a taxable order gives back tax at the rate that order was charged.

Occasionally an order's tax cannot be split with confidence, usually because some items on it were taxed and others were not. TALISK_HQ then books the refund against sales without touching the tax, which leaves a little more sales tax showing as owed than you actually owe. Nothing is lost, and your accountant can adjust it on the next return.

The month a payout's sales are counted in

A payout pays you for sales made over the days before it, so a payout can easily be settling sales from the month before. TALISK_HQ counts those sales in the month they happened, not the month the money arrived. A payout landing on 5 August for sales made across late July puts that revenue, and the GST on it, in July.

The deposit itself is still recorded on the day the bank shows it. TALISK_HQ holds the difference in Ecommerce Clearing until the sales and the cash meet, so bank reconciliation and your bank balance are unaffected.

This matters most at the end of a quarter. A sale made on 30 June that pays out on 3 July belongs on the return covering June, and that is where you will find it.

Two kinds of book work differently, and both are deliberate. A book kept on a cash basis counts money when it moves, so its payouts are recorded in full on the payout date. A foreign-currency payout is also recorded on the payout date, at that day's rate.

Payouts that straddle the day your books start

Payouts settle a few days after the sale, so the first payout or two after your books start can be paying you for sales that happened before them. Those sales are already counted in your opening balances, so TALISK_HQ does not record them as income again. The deposit still lands in your bank as normal; it clears the pending balance your opening figures set up instead of adding new sales.

Because nothing is recorded as income, those payouts can look like the problem in the section above: the deposit is in your books with no sales behind it. Books Health tells them apart and raises "some payouts paid for sales from before you started" instead, with no correction offered, because there is nothing to correct. What it asks you to check is different: the money is sitting in Ecommerce Clearing waiting for your opening balances to absorb it, so your opening figures need to carry a clearing balance at least that big. If they do not, that balance goes negative, and putting it right is an opening-balance correction your bookkeeper makes once.

The reverse happens when you move your conversion date to a month end that falls inside a payout already in your books, for example a payout on 2 February for sales from late January and early February, with balances as of 31 January. TALISK_HQ divides that payout at the date: its January entries are removed, because your opening balances now carry those sales and fees, and the February sales and the deposit stay. Open the payout and the Recognition by month card says so. It names the date the payout was divided at and how much of the deposit settles what your opening balances carry, and the months it lists are the part these books hold.

If your books were converted from an accountant's records and payouts were already recorded across that date, Books Health raises "payouts recorded sales from before your books started" with the income and sales-tax amounts counted twice. Send those figures to your accountant: reversing them is an adjusting entry, which is their job, not something to change here.