How payouts land in your books

Once a store or processor is connected, 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. (PayPal is recorded differently, as an account in Banking: see below.)

To see what one order leaves you after Shopify's fees and the tax, try the free Shopify payout calculator.

To review them, open Ledger › Banking › Payouts. That tab appears once a store or payment processor is connected, and it stays for the rest of the fiscal year after a disconnect if that year has payouts in it. A connected processor is also listed under Ledger › Banking › Accounts › Payment processors: click its row to expand its payouts, with the same columns and statuses, and a Stripe or Square account also lists its live activity above them (payments and refunds as they happen; your books record the money when the payout lands). PayPal is not there: its days are listed on the PayPal account itself, under PayPal sales by day. The revenue also shows on the Ledger Dashboard, whose card links to the payouts on a business with no store. On the Payouts tab:

• 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. PayPal is the exception: its money is an account in Banking, so a PayPal row shows that day's Sales (tax included), Fees and Net, and reads In PayPal instead of Matched or Open. It has no Unmatch or Link deposit, because it never matches a deposit. See PayPal in Banking.

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. A payout in a currency HQ can't post yet is shown but not posted.

Sometimes two deposits of the same amount land in the same few days, or two payouts are for the same amount, and 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 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 Banking tab bar narrows Ledger › Banking › 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 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 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.

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. A bookkeeper you invited needs Full access for both steps, because the correction records income and sales tax.

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 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, 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. 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 HQ, 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. 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. 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 sales tax on a Stripe payout

Stripe's payout records don't say how much of each sale was tax, so HQ looks at the invoice or Checkout page each charge came from and records the tax Stripe actually charged that customer. An Ontario customer's 13% HST is booked as HST, a Quebec customer's GST and QST as GST and QST, and a sale Stripe charged no tax on (a customer outside Canada, say) is booked with none. PST is recorded against the province it was charged in.

This only works when Stripe worked out the tax. A charge from somewhere with no tax set up in Stripe is recorded the way it always has been: its tax is worked out from your business's own province and registration, as if the sale were taxed there. Each charge is decided on its own, so one payout can hold both kinds.

If HQ could not reach Stripe to check, the payout is Held and nothing is recorded until a later sync gets an answer. Hover the badge to see why: Stripe could not be reached (it is retried at every sync, and if it keeps failing, check your Stripe connection in Ledger › Setup), the check is still queued, or your business's province is not set, which charges Stripe did not work out the tax for need. HQ does not guess at a tax figure, because one recorded by mistake would end up on a return.

A Stripe payout is also Held while HQ has not received Stripe's full breakdown of what it paid out, rather than being booked with some of its sales and tax missing. It posts once the breakdown arrives.

HQ records a Stripe payout's sales, refunds, Stripe fees (including fees Stripe gives back) and disputes, which are booked as chargebacks. A refund that failed and came back reverses its refund: it goes back into sales, and the tax the refund gave back is collected again. A payout that also holds something HQ does not record yet is Held too, and the badge names it: a top-up of your Stripe balance from your bank, a transfer between Stripe balances, a Stripe Issuing card transaction, a Climate contribution, or anything else new. Nothing from that payout is in your books until it is dealt with, so nothing is booked as an unexplained difference.

Reserves, Capital and other money the processor moves

Some of what a Stripe or Square payout carries is not a sale or a fee. HQ books each of these to its own account, created the first time a payout needs it:

• A reserve or a hold (money the processor keeps back, and later releases) goes to Funds Held by Stripe or Funds Held by Square, an asset. It returns to zero as the money is released into later payouts. PayPal is different: a dispute hold records nothing, and the PayPal account in Banking shows what PayPal is holding (see PayPal in Banking).
• A Stripe Capital or Square Capital repayment taken out of a payout comes off Stripe Capital Loan or Square Capital Loan, a liability. The loan itself usually arrives as a deposit in your bank account: categorize that deposit to the same loan account (it is offered under Settles a balance you carry in Banking). The account appears with the first payout that carries a repayment, so a loan deposit that arrives before then can wait uncategorized until it does. HQ does not split the financing fee out of the repayments; how that fee is recognised is a question for your accountant.
• Square Balance folders and automatic savings go to Square Balance Folders, an asset, since the money is still in your Square account.
• A Square subscription fee is an expense, booked to your Software & Subscriptions account (or Payment Processing Fees if your chart has none).
• Sales tax Square or Stripe charged on its own fees is claimed as an input tax credit when your business claims them on its bills, and otherwise is part of the fee. In Quebec the tax is split at Quebec's rates: the GST part is a GST credit, and the QST part is a QST refund if your business is registered for QST, otherwise part of the fee. In British Columbia, Saskatchewan and Manitoba the GST part is a GST credit and the PST part is part of the fee, because PST you pay cannot be claimed back. When Stripe's own figures show it charged GST alone (5% of the fee rather than the GST and PST rate together) on every fee, all of it is a GST credit; when its figures cannot show that (the fees are too small to tell, or they disagree), HQ assumes PST was charged. The split uses the province your business was in when the payout was recorded, so changing the province later does not change payouts already in your books.
• Application fees a Stripe Connect platform earns are income, booked to Platform Fee Income; a refunded application fee lowers it.

A payout is Held instead, and the badge says why, when your chart already uses one of these account numbers for something else, when a reserve, Capital or Balance-folder item comes in a currency other than your books', or when a refund of a client's card payment failed and came back.

When your clients pay invoices by card through the same Stripe account whose payouts HQ records, a client's payment is not a sale in the payout. HQ books the payment into Ecommerce Clearing when it arrives, and the payout that carries it books Stripe's fee and clears it, so your bank balance matches the deposit. A payout that carries a client's card payment that is not recorded yet is Held, and the badge names the invoice. It posts once you confirm the payment on the invoice (or Stripe's notice of it arrives), or once you reject the payment there, which counts the charge as an ordinary sale instead. If a payout already counted that charge as a sale, confirming the payment is refused rather than counting the money twice, and the payment then offers Move it onto this invoice. HQ shows what will change, then takes the charge out of that payout's sales and sales tax and records it on the invoice, so the money counts once and the invoice is paid. The change is dated the payout's day, or the first open day when that day is in a closed period (it is then listed in Notes for your accountant). The payment row then says it was moved from the payout, with Undo, which puts the charge back into the payout and the payment back to waiting. HQ refuses the move, saying why, when the charge was refunded (or, on Stripe, disputed), when the invoice is already paid, when the charge is not this invoice's payment, or when it is not in your books' own currency. With several card payments moved out of one payout, undo the latest first. A refund or dispute of a client's card payment is recorded back on the invoice; a payout carrying one HQ could not record is Held with the reason.

The same holds when your clients pay invoices by card through your Square account: the client's payment is not a sale in the Square payout that carries it, and that payout books Square's fee and clears it. A Square refund of a client's card payment is recorded back on the invoice. A Square payout carrying a refund HQ could not record, or a dispute of a client's card payment, is Held with the reason.

A refund always gives back tax the same way its sale was recorded, whichever payout it lands in. For a sale Stripe worked out, that is what a credit note says, the whole tax for a full refund, or a matching share of a partial one; when a partial refund's share can't be worked out, the refund comes off sales without touching the tax, as described above. For a sale taxed from your province, the refund is too.

The sales tax on a PayPal or Square payout

Like Stripe's, these payout records don't say how much of each sale was tax, so HQ looks at the order each payment came from and records the tax that order was actually charged, PST included, against the province it was charged in:

• PayPal: a payment for a Shopify or WooCommerce order you have connected takes that order's tax, per payment. Other PayPal sales take the tax worked out from your business's own province and registration, for that day. When a PayPal payment paid a whole WooCommerce order whose tax matches neither its province's full rate nor GST alone (only some items charged PST, say), HQ cannot tell that order's GST from its PST, so the payout is held rather than recorded with the PST counted as sales. An order that charged GST alone takes exactly that GST, with no PST or QST; its tax has to be GST on its goods to within a few cents of rounding, and shipping has to show its own tax, or the order is held the same way. The Payouts tab and the books health card for held payouts name the order; check its tax in WooCommerce, and HQ looks again at every sync. A later PayPal day that refunds that held sale waits for it, so the refund gives back the same tax the sale is recorded with. A refund of an order that charged GST alone gives back its GST, whether it refunds all of the order or part of it. When Sync further back brings in an older day whose sale a later day already refunded, HQ works that later day out again so the refund follows the sale, unless the later day is already posted, which stays as posted. A refund finds its sale after you reconnect PayPal too.
• Square: a payment rung up as a Square order takes the taxes on that order, when each one is named GST, HST, PST or QST (or TPS, TVH, TVQ) and its rate matches the province of the Square location.

A payment only takes its order's tax when it paid the whole order. Anything else, such as a quick Square sale with no order behind it, a payment split across two cards, or a tax named "Sales tax", is recorded the way it always has been: its tax is worked out from your business's own province and registration. That gives GST or HST but never PST, so if you charge PST on those sales, check the PST figure before you file. Each payment is decided on its own, so one payout can hold both kinds, and a refund gives back tax the same way its sale was recorded.

Square gift cards

A gift card you sell through Square is money you owe your customer until they spend it, so it is not a sale yet:

• Selling a card: when the card is paid for in one payment, its amount goes to Gift Card Liability, with no sales tax, in the payout that carries the sale. When the same order also sells goods, only the goods are sales. A card sold in an order paid more than one way is Held, because HQ cannot tell which payment bought it.
• Spending a card: a sale paid with a Square gift card brings no money into a payout, so HQ finds it in your Square payments and records it on its own, on the day of the sale: the sale and its tax, taken out of Gift Card Liability. The tax is the order's own, the same way as for a card payment. When a customer pays part with a gift card and the rest by one card, the payout records the card part and the gift card its part, each with its share of the order's tax, so the sale is counted once.

Some cases are not recorded and wait instead, listed on the Books health card for held payouts after a week with the reason: a payout that refunds a sale which included a gift card (Square does not say whether the card or the goods went back), a gift card payment that was partly refunded, a sale paid by gift card that also sold one, and anything when HQ cannot read your Square orders. A gift card payment refunded after HQ recorded it is not taken back out of your books yet, so correct that sale by hand.

Gift cards sold before HQ's history, or sold for cash outside Square, never reached Gift Card Liability, so spending them can take that account below zero (a Books health card says so). Put the cards still out when your HQ history starts into Gift Card Liability's opening balance, and record cards sold for cash by categorizing that bank deposit to Gift Card Liability. Gift cards that are never spent stay in Gift Card Liability; when an expired card can be taken into income is a question for your accountant, and HQ does not record it.

Shopify gift cards

A gift card sold through Shopify, on its own or in the same order as goods, goes to Gift Card Liability with no sales tax, in the payout that carries it. Only the goods are sales. A sale a customer pays with a Shopify gift card is recorded the same way as a Square one, once the order is paid:

• Paid wholly by gift card: no payout carries it, so HQ reads how the order was paid and records it on its own, on the day of the order: the sale, its shipping and its tax, taken out of Gift Card Liability.
• Paid partly by gift card, the rest through Shopify Payments: HQ records the gift card's part first, then the payout records the card part, each with its share of the order's tax and shipping, so the sale is counted once. Until HQ has read and recorded the gift card's part, the payout waits.
• Paid partly by gift card, the rest by hand (a manual payment, cash on delivery, a cheque or a bank transfer): HQ records the gift card's part first, then records the rest as a direct sale for only the money you were really paid, so the deposit you match it to is the right amount and the sale is counted once. Until the gift card's part is recorded, the direct sale waits. It works the same whichever payment Shopify lists first.
• Paid partly by gift card, the rest through PayPal: HQ records the gift card's part first, then that day's PayPal sales record what PayPal received, with the rest of the order's tax, so the sale is counted once and your PayPal account shows only the money PayPal took. Until the gift card's part is recorded, that PayPal day waits, for a week at most: after that the PayPal part is recorded without it, and the gift card's part stays listed with its reason. If the PayPal day was recorded first (after that week, or before HQ saw the order), the gift card's part takes the rest of the order's tax when it is recorded, so the order's sales and each tax still add up to the order. When the gift card paid less than the tax that PayPal day left out (a small gift card on an order with PST), the gift card's part is recorded with its usual share instead, and HQ adds a separate tax correction for that order: it moves the missing PST (and any GST the PayPal day took over the order's) out of sales into the right tax accounts, so the order's sales and each tax add up to the order. It moves no money. If the order's day is in a closed period or a return you have already filed, the correction is dated the first day after it, and your accountant's notes list it. A PayPal refund of that sale takes its share of the correction back on the refund's day. A refund of everything PayPal took gives back exactly the tax that PayPal part was recorded with.
• Refunded back onto the gift card: the customer can spend that money again, so HQ puts it back into Gift Card Liability and takes that share of the sale, its shipping and its tax back out, on the day of the refund. Each refund is recorded once, and a gift card refunded in full takes the whole sale back out to the cent.

Some sales are not recorded and wait instead, listed on the Books health card for held payouts after a week with the order number and the reason: HQ cannot read from Shopify how the order was paid, the order also sold a gift card, the rest was paid through a processor other than Shopify Payments or PayPal, the order was changed after it was placed, or its date is in a sales tax period you have already filed. The rest of the payout is recorded; only that sale's card payment waits. A sale whose payout or direct sale HQ recorded before it knew a gift card paid part of it waits too, so it is never counted twice. A refund onto a gift card waits the same way when its date is in a closed period or a sales tax period you have already filed.

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