Help & guide

Cash Flow

The home page is your weekly triage: a single running-cash ledger in date order, starting from the bank balance. Each row moves the running total; it turns red where you’d go negative.

• Deposits (Square in-transit + receivables) add to cash on their date.
• Reserved rows (🔒) are non-negotiable — critical vendors and recurring obligations. They’re always subtracted.
• Discretionary bills are ranked by Claude; Snooze one to free its cash for the next priority (the running total updates instantly), or Mark paid.
• PST/GST returns always rank first and are flagged ⚠ CRA / eTaxBC · penalties + interest. That money was collected on the government’s behalf and filing late accrues penalties plus daily compounding interest, so their position isn’t left to the AI’s judgment — it’s a rule. You can still pin one to Defer if the cash truly isn’t there; unlike every other bill it then stays at the top of the ledger, in red, showing what’s still owed, instead of sinking out of sight with the rest of the deferred bills.
• Every QBO-backed bill has a “QBO ↗” link to open it in QuickBooks for troubleshooting.
• Available to allocate = bank balance + counted Square deposits − reserved − safety buffer. Receivables are shown for context but not counted (too unpredictable).

Paying part of a bill

Click the amount on any payable row and type what you actually intend to send. Everything below re-cascades around that figure straight away — running cash, where cash runs out, and the “Paying this run” total — so you can see what’s left for everyone else while you’re deciding, before a dollar moves. Clear the box to go back to paying it in full.

• Nothing is sent while you’re planning. The figure sticks (it survives a reload) until you click Paid, which reads “Paid $500.00” so what’s about to go out is never in doubt.
• The bill then stays on the list at what’s still owed, keeping its place in the priority order, and shows “$500.00 paid so far · $1,500.00 still owed”. Next time round you’re budgeting the real remainder.
• A part payment is written into QuickBooks as a Bill Payment against that bill, so its balance drops there too and your bank feed has a matching transaction to land on. That isn’t optional: Refresh takes QuickBooks’ balance as the truth, so a part payment QBO never heard about would be wiped on the next refresh and the bill would return at full size — asking you to pay money you’d already sent. Undo deletes that Bill Payment again and restores the balance.
• Paying in full writes a Bill Payment too. All of one vendor’s bills paid in one click (Pay all, or several ticked for bulk Mark paid) go on one Bill Payment with a line per bill — the one e-transfer you send — so the bank feed suggests the match by itself. It’s dated today, Pacific time.
• Where the money came from. Every payable row’s ⋯ menu offers three: Mark paid (bank) draws the Bill Payment on your payments bank account (Chequing); Mark paid from cash on hand draws it on Cash on hand (1500) — for an act or vendor paid out of the till; and Mark paid on credit card charges the card. Bank and cash on hand both reduce your projected balance, because Cash on hand is one of your counted accounts; the card doesn’t. Part payments take the same three choices.
• Undo on a shared payment: undoing one bill takes just that bill’s line off the Bill Payment and leaves the others paid; undoing the last one deletes it. If the payment is already matched in the bank feed, QuickBooks won’t let it change — undo the match in Banking first.
• A recurring row for a long-term-liability vendor (SPRQ rent) is written into QuickBooks as a Bill Payment against that vendor’s oldest open bills, split across two when one doesn’t cover it. Other rows with no QuickBooks bill behind them (recurring obligations, artist payouts, PST/GST returns) are recorded here only, part payments included.

Receipts

Every vendor invoice the bills pipeline processes lands here — whether it posted to QBO or needs a look — so you can correct what the AI read and book it, with no email back-and-forth.

• Statuses: Needs review (extracted, awaiting you) · In QBO ✓(booked) · Error · Ignored.
• Expand a row to fix vendor, amount, GST, dates, expense account, etc. Saving an expense account / tax rule teaches that vendor for next time.
• Accuracy check: posted receipts show ✓ (amount + GST match QuickBooks) or ⚠ with the gap, so old/incorrect entries surface.
• PST is booked as a deductible expense line (it’s non-recoverable, so not a tax credit). Tips book with no GST.
• Combine a split expense (itemized bill + card slip): open the itemized receipt → “Combine another receipt into this one” → pick the slip → set the total. The tip is added automatically and both images attach to QBO.
• Note → QBO memo: what you type in the note posts to the QBO transaction (e.g. who attended a meal — required to substantiate meals & entertainment).
• Delete & re-post: on a posted receipt this removes the old QBO entry and books the corrected one (use it to fix the PST/old entries flagged ⚠).
• A “Posting…” badge persists while a post is in flight, even if you leave and come back.

Deposits

Turns each Square payout into a categorized QBO deposit whose total equals the bank line to the cent — the bank feed then auto-matches it. Replaces the old accept-then-adjusting-JE routine. (Eventbrite remittances aren’t split — they stay on the cash forecast and get matched in the bank feed directly.)

• Where the split comes from: Square’s own payout ledger (exact gross, fees, and the 10% loan holdback) + the catalog category of every item sold that day.
• Map once: the mapping table at the bottom ties each Square category (and the fixed roles: fees, loan holdback, tips, refunds) to a QBO account + tax code. Saving a mapping immediately fills every pending split.
• Posting rules: a split posts only when every line has an account, the lines sum exactly to the deposit (the Σ chip), and the payout has landed (“in transit” rows wait). Nothing posts without your click.
• Tax: the GST/PST Square collected rides each split as its own tax lines — the exact cents from the register, never recomputed from a rate — and income lines are pre-tax. Posting books the taxes through QBO’s sales tax module, so the Sales Tax Centre and your returns track the true obligation. Two one-time mappings: each “Square tax” row picks its QBO sales tax rate, and each taxed income category picks a QBO tax code that carries those rates (e.g. alcohol → a combined GST + PST Liquor code, soft drinks → GST/PST BC) — QBO only accepts tax amounts for rates that some line’s code carries. After every post a check verifies QBO booked the exact bank amount, and deletes + errors if not. Check the first posted deposit in QBO before doing them in bulk.
• Delete & re-post works like receipts; posted rows show ✓/⚠ against what QBO actually booked.

Month-end

The routine: once a month, on or after the 5th, work down last month’s numbered steps: post Cash sales, Tips paid, the Cutoff, then the Cutoff reversal, and file the PST return last (plus GST in a quarter’s last month). The cash sales entry adds tax to the return, so it has to be posted before you file.

Deposits only cover card payouts. Two things never reach the bank through a payout, so Cash drafts a journal entry for each, every month, for you to post:

• Cash sales (CASHSALES-YYYY-MM): what customers paid in cash at the register. Debits Cash on hand for the cash that went into the till, after cash refunds. The refunds themselves go to Sales Discounts. Each income account is credited using the same category mapping as Deposits. The exact GST, PST and liquor PST Square collected are credited to GST/HST Payable and PST Payable (BC) with their sales tax rate, so they land on the returns. Income lines carry the Exempt code, so the tax isn’t counted twice.
• Tips paid (TIPSPAID-YYYY-MM-DD): every deposit split credits card tips to the Tips liability, but staff are paid those tips in cash from the till. This debits Tips and credits Cash on hand for the tips on that month’s posted deposit splits, so the Tips balance comes back to zero. It waits until every split that arrived that month is posted or ignored.
• Month-end card sales (CUTOFF-YYYY-MM and CUTOFFREV-YYYY-MM): a deposit is dated the day the payout reaches the bank, one to three days after the sale. So card sales from the last nights of a month would count as next month’s income. The cutoff entry, dated the last day of the month, moves that income back: it debits Square Clearing and credits each income account for every card payment made before month-end whose payout landed after it. The reversal is its mirror, dated the 1st of the next month, so the deposits don’t count the same sales twice and Square Clearing returns to zero. Post the cutoff, then the reversal. Only income moves: the GST, PST and tips on those sales stay with the deposit. Post unlocks on the 5th, once the payouts have landed. A month that ends with nothing waiting shows “Nothing to move”; ignore it.
• When: cash sales and tips are dated the last day of the month. The current month shows as a month-to-date preview (press Build); Post unlocks once the month is over. Refresh keeps finished months’ drafts up to date until you post. Nothing posts without your click.
• Not included: “other” tender in Square (e-transfer, cheque). That money never reaches the till or a payout. The card flags it so you can book it where it went.
• June–September 2026 were entered by hand at year-end, so this starts with October 2026.
• Sales tax filings: the PST and GST worksheets (the old Taxes page) are at the bottom of Month-end. Each month’s heading shows the return that closes with it: that month’s PST, plus the GST return in the last month of a quarter, with its due date, amount and whether it’s filed. Post the month’s journal entries and press Refresh before you file, so the return includes them. Override, Mark filed and Unmark work as before.

Vendors

Set each vendor’s tier — critical (reserved, paid first), important, or deferrable — and free-text notes. Both are fed into Claude’s ranking every run, so this is your main lever for teaching it who to pay first. Changes save as you type.

Data & obligations

The Data page validates everything ingested from QBO and is where you manage recurring items.

• Bank balance breakdown — which QBO accounts count as spendable cash (set on Settings); clearing/contra accounts are excluded.
• Forecast math — the exact available-cash calculation.
• All ingested items — every bill/inflow with its QBO id, to reconcile against QuickBooks.
• Recurring obligations — add rent, a loan paydown like SQRQ, etc. Set the amount, frequency, and an optional outstanding balance (you maintain it by hand — it isn’t auto-amortized, since it can grow or be forgiven). These appear on the cash ledger as reserved outflows each period. Overdue ones show too if you’re behind (e.g. last week’s + this week’s payment); each recurring row on the ledger has a Mark paid button. Set the obligation’s starting date to the first date you owe from.
• Long-term liabilities: for a loan vendor like SQRQ, tick “LT liability” on the Vendors page — its QBO bills move off the cash view to the Liabilities page (so they don’t distort weekly triage), and you track the real payment as a recurring obligation here. Map that obligation to the vendor and paying it posts a Bill Payment against the vendor’s oldest open QBO bills.
• Artist payouts show only as real QuickBooks bills — pushed from Jimmy (Push to QBO) or entered in QuickBooks. Cash no longer estimates them from Jimmy’s deal terms and ticket sales.

Settings

Safety buffer (cash you never spend below), forecast horizon(default 5 weeks), the counted bank accounts, and a manual balance override for when the QBO bank feed lags.

Part payments → QuickBooks. Paying only part of a bill writes a matching Bill Payment into QuickBooks so its balance drops there too (Refresh reads that balance as the truth) and your bank feed has something to land on. These two fields say which account it comes out of — Chequing by default. Leave the credit card one blank and a 💳 part payment is refused rather than recorded: otherwise Cash would show the smaller balance while QuickBooks still showed the full one, and the next Refresh would quietly put the money back.

Payroll overhead reclass. Payworks books every payroll run’s wages to cost of labour, so a salaried manager’s admin time sits in COGS and drags every event’s margin down. Turn this on and each Refresh watches QuickBooks for a new Payworks journal entry — recognized by the credit to your payroll clearing account — then books one two-line adjustment against it: debit the overhead account (e.g. Indirect Wages), credit the labour account (e.g. Direct Wages). Numbered PR-RC-<pay date> and dated the same day as the payroll.

• You set the amount — the Payworks entry is account-level and never says who was paid what, so there’s nothing per-employee to read. Give it the person’s gross per pay plus an overhead % (James, 50%), or a flat amount per run. The panel previews the exact figure before you save.
• A change here applies to the next runs, not ones already booked. To correct a booked one, delete that entry in QuickBooks and Re-post from the history.
• A reclass bigger than the payroll run itself is flagged, not booked — that means the gross is stale (a raise, or a changed pay frequency).
• The history lists every reclass with the basis it used and a link to the entry in QBO, and each one is re-checked on Refresh — so one deleted in QuickBooks stops claiming “In QBO ✓”.

How “Refresh” works

One Refresh button in the top nav does everything, and the “updated …” marker next to it shows when it last ran (from the button or the nightly job). A single click runs:

• QBO open bills + bank balance + chart of accounts
• Square pending deposits
• Recurring obligations (rent, SQRQ, …)
• The Receipts ↔ QBO comparison (✓/⚠) + catches transactions deleted in QBO
• The payroll overhead reclass for any new Payworks journal entry
• Re-ranks the weekly payment run

The nightly job runs the same refresh ~6 AM PDT. So if a posted receipt’s ✓/⚠ comparison is blank (e.g. just after a re-post), one Refresh brings it back.

Changelog