Help & guide
How each part of the app works. Opened from a page, this jumps to that page’s section.
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, recurring obligations, and artist payouts. 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 a bill in full is unchanged — nothing is sent to QuickBooks; record those there as you do now.
- Rows with no QuickBooks bill behind them (recurring obligations, artist payouts, PST/GST returns) can take a part payment too — recorded here only, exactly as marking one of those paid has always been.
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.
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.
- Artist payouts come from the event tracker (deal terms + sales): guarantees are exact, door splits are estimated from ticket sales and firm up at settlement. They show as reserved “Artist: …” rows on their settlement due date.
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, …)
- Artist payouts owed (from the event tracker)
- 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
- A refresh now keeps what it pulled. The last thing a refresh does is ask Claude to re-order the payment run, and that one step is half the total time — about 70 seconds of the two and a bit minutes. It also used to run before the “last updated” time was recorded, and without a safety net: if it failed, or ran out of time, the whole refresh was reported as never having happened, even though the QuickBooks pull, Square, the deposits and the receipts had all landed a minute earlier.
- The order is swapped. Your data is stamped as current the moment it IS current, and the re-ranking happens after that. If the re-ranking can’t be done, the button says so — “Data updated, but the payment run didn’t re-rank” — and you can click Re-rank on the dashboard when you want it. Nothing is silently thrown away.
- For reference, where the two and a half minutes actually go: the QuickBooks pull is 33 seconds, Claude’s re-ranking 69, and everything else together about 31.
- Refresh All works again. For the last while it has spun for a couple of minutes and then said “Refresh didn’t finish — try again”, however many times you clicked it.
- Nothing was broken about the refresh itself — the overnight one has been running fine, which is why the figures still looked roughly right each morning. The button was being cut off partway through. A full refresh now takes about two and a half minutes (the QuickBooks pull, Square, Eventbrite, the deposit splits, and Claude re-ranking the payment run, which is a good 70 seconds on its own), and the button was only allowed three, out of which it also had to redraw the page. It never got to the end, so the work it had already done was thrown away and the last-refreshed time never moved.
- The button now goes through the same path the nightly refresh uses, which has the room for it, and redraws the page as a separate step afterwards.
- While it runs it counts the seconds up and tells you roughly how long to expect, so a long refresh doesn’t look like a hung one.
- Also: if the re-ranking call to Claude ever hangs, it now gives up after two minutes and falls back to the rule-based order instead of retrying and taking the whole refresh down with it.
- Clicking Paid now records the payment in QuickBooks. Until today only PART payments went across; a bill paid in full was left for you to enter in QBO by hand, on the assumption that a paid bill just quietly drops off the list. That assumption stopped being true in July, when Jimmy began posting talent, sound and security settlements to QuickBooks as Bills.
- Here's what was going wrong. Jimmy posts a bill for, say, $112.50 of security. You send the e-transfer and enter it in QuickBooks as an Expense — which is how it always worked, back when there was no bill. But an Expense doesn't pay a bill: it's a second, separate cost. So the $112.50 hit the P&L twice, and the original bill sat in Accounts Payable still looking unpaid. August alone carried $2,516.25 of that, and July another $1,971.20 — roughly $4,487 of costs counted twice and the same amount showing as owed to people who'd already been paid.
- Now Paid writes a Bill Payment against the actual bill, from the account set under Settings → “Part payments → QuickBooks”. The bill closes, the cost lands once, and there is nothing left for you to re-enter in QuickBooks. “Pay all” for a vendor does the same for each of their bills.
- QuickBooks goes first. If it refuses the payment, the click fails and nothing is marked paid here — better a button that didn't work than Cash telling you a bill is settled while QuickBooks still says you owe it.
- Undo removes the Bill Payment again, whether you undo it during the run or correct it afterwards from Runs.
- Unchanged: rows with no QuickBooks bill behind them — recurring obligations, artist payouts, PST/GST returns — are still recorded here only, because there's no document there to pay.
- You can pay part of a bill now. Click the amount on any payable row and type what you actually intend to send — $500 against a $2,000 supplier invoice — and the ledger immediately re-does its arithmetic around that figure: the running-cash column, where cash runs out, and the “Paying this run” total all treat that bill as costing $500. That's the point of typing it before you pay anything: you can see how much is left for everyone else while you're still deciding who gets what.
- Nothing is sent while you're planning. The figure just sits there (it survives a reload) until you click Paid, which now reads “Paid $500.00” so there's no doubt what's about to go out.
- Once recorded, the bill doesn't disappear — it stays on the list at the $1,500 still owed and keeps its place in the priority order, with “$500.00 paid so far · $1,500.00 still owed” under its name. So the next time you look at the list, you're budgeting the real remainder instead of the original invoice.
- A part payment is written into QuickBooks as a Bill Payment against that bill, so the bill's balance drops there too and your bank feed has a matching transaction to land on. It has to be: Refresh takes QuickBooks' balance as the truth, so a part payment QBO didn't know about would be wiped on the next refresh and the bill would come back at full size — asking you to pay money you'd already sent. Undo deletes that Bill Payment again and puts the balance back.
- Which account it comes out of is set under Settings → “Part payments → QuickBooks” (Chequing by default). Paying a bill in FULL still isn't sent to QuickBooks — record those there the way you do now.
- Rows with no QuickBooks bill behind them — recurring obligations, artist payouts, PST/GST returns — can take a part payment too; it's recorded here only, same as marking one of those paid has always been.
- Website ticket sales can stop landing in Uncategorized. They were never classifiable: the classifier reads a Square catalog category off each sold item, and a ticket sold through the website is created by The Events Calendar with no catalog item behind it — so there was nothing to read, every ticket fell into Uncategorized, and Uncategorized has no account, which is what blocked the Post button on those deposits.
- A Square LOCATION can now be mapped, not just a category. Sell one thing at one location — online tickets — and the location IS the answer: map it once in the mapping table and every un-catalogued sale from that location's payouts books to that account. Catalog categories still win where they exist, so mapping a location can never hide a properly categorised item.
- The mapping table lists every configured Square location by its real Square name, added automatically on Refresh. Leave one blank and nothing changes — its sales keep falling into Uncategorized, which stays the safe default, and the venue location is meant to stay blank since its sales are catalogued.
- Item-name rules (“cover”, “merch”, “coat check”) are switched off at a mapped location. They're POS heuristics tuned for the bar; at a ticket location a show called “Undercover” would have booked its tickets as door cover. For the same reason the “Unmapped items” warning stays quiet there — those items aren't a gap to fix, they're the whole point of that location.
- Deposits from a second or third location now show that location's real name (“Square · Online Tickets”) instead of “Location 2”.
- Splits already sitting in review from a location you've just mapped rebuild themselves on the next Refresh, so you don't have to hunt them down — and the per-refresh build budget now serves brand-new payouts first, so a backlog of rebuilds can't hide a deposit that hasn't appeared yet. The budget went from 8 builds a refresh to 12 to make room for a third location.
- “Pay Type: Mastercard” no longer means the invoice was paid. The BC LDB agency order form has a Pay Type box naming a card — that's how the order will be settled, not proof the money moved — and the AI kept reading it as a paid receipt. It did that to the Steamworks order for $960.25 (“indicating payment was made at time of order issuance”) and to #101026 before it, while every other Steamworks order in the system is booked as an ordinary Bill.
- Now a payment has to be RECORDED, not just described: PAID / RECEIPT on the page, Balance Due 0.00, Amount Paid equal to the total, Tendered/Change, or a card transaction with its trace (masked card plus an approval or terminal number). A payment-METHOD field — Pay Type, Payment Method, card on file, a bare card brand — is explicitly not evidence, and a printed AMOUNT DUE above zero is still owed no matter what the pay type says. Unsure still defaults to owed: mis-booking a paid receipt is a correction, but booking an unpaid invoice as paid hides money you still owe.
- The Steamworks order that was flagged paid has been set back to Bill, so it posts as accounts payable without asking for a paid-from account.
- Container deposits are read now. A Steamworks order for $960.25 sat in review saying “off by $127.20”: five goods lines came to $793.38, GST was $39.67, and the missing $127.20 was exactly four keg deposits at $30.60 plus 48 can deposits at $0.10 — charged in the totals block below the product subtotal, where the AI never looked. Nothing was wrong with the goods; the refundable deposit simply wasn't captured, and every brewery/BC LDB order has one.
- The extraction prompt now spells out where that deposit is printed and that it sits outside the GST base (GST is 5% of the goods subtotal only), and the AI checks its own arithmetic before answering: goods + deposits − returns + GST + PST has to equal the invoice total. If it doesn't, it gets one more read — told exactly how far off it is and where to look — and if it still can't explain the gap the receipt is held under the auto-post threshold for you instead of being booked.
- That guard matters because QuickBooks is booked from the LINES, never from Amount. An invoice whose lines came up $127.20 short used to post at $833.05 and then never match the bank line. Posting is now blocked at every entry — the tab, the pipeline, and the poster itself — until the parts add up to the total, and the reason says so in words.
- Deposits also stopped being invisible. They're kept as an editable deposit line AND as the deposit total the poster books to Kegs Held, with the two held in step in both directions: a deposit the AI reported only as a total now shows as a line you can see and correct, a line worded “Container Deposit” that came through as ordinary goods is re-flagged (so it stops landing in Alcohol - COS with GST charged on top), and a deposit line you add or delete updates what actually posts. When the lines fall short there's a one-click “+ $127.20 container deposits” button in the editor. A container recycling fee or enviro levy is deliberately NOT treated as a deposit — that one is a real, taxable cost of the goods.
- Line items on a receipt are editable now — add, edit, remove, or Clear all. They never were before: the AI wrote them once and you could only look at them. That mattered more than it sounds, because when a receipt has line items QuickBooks is booked from the LINES, and the Amount field is only used when there are none. So a garbled extraction could not be corrected: fixing Amount changed nothing about what posted.
- That's what happened to a faded BC Liquor photo on July 2. The AI read $365.16 on a $174.92 receipt (its own confidence: 55%, note: “amounts are estimated from visible barcode and numeric patterns”), invented a second product line, and even got the year wrong. Amount was corrected to $174.92, but the stale lines won and QuickBooks was booked at $347.24 — which is why it would never match the bank line.
- Posting is now blocked when the lines don't add up to Amount, and the line editor shows a running “lines + GST + PST = X · Amount = Y” with the gap called out. Clearing all the lines is a legitimate fix — it books Amount as a single line. Six existing receipts are affected; five are correct in QuickBooks today but would have silently changed amount if they were ever re-posted (the worst by $717), and they're all blocked from posting until their lines are reconciled.
- Deposits has a cutover date now, under Settings → “Square deposits start date”. Payouts that landed before it are never ingested and can't be posted. This closes a real hole: three deposits dated June 1 ($12,426.11) had been posted by the July 4 backfill for payouts whose money was ALREADY on the books the old way — the month-end journal entry that recognized the revenue into Square Clearing, plus one “Square, Inc. Misc Payment” transfer per payout draining it to the bank. Those transfers are what matched the bank feed; the app's deposits were duplicates that counted the revenue twice and could never clear. They've been deleted and the three rows are marked Ignored.
- Why a plain duplicate check wouldn't have caught it: the real record was a Transfer and the duplicate was a Deposit — different transaction types, so nothing lined up to compare. A hard date boundary is the thing that actually works, which is why it's a date and not a smarter matcher.
- The boundary is enforced in three places, so there's no way around it by accident: the refresh skips pre-cutover payouts (and says how many), Post to QBO refuses one with an explanation, and the backfill endpoint rejects a `since` earlier than the cutover instead of quietly ingesting nothing. Only the last of those existed as a footgun before — the backfill URL is exactly what caused this.
- Deposits now looks back 30 days instead of 14. The OffSite Event location's two July 13 payouts never appeared no matter how many times you hit Refresh — they were 22 days old, and the everyday window only reached back a fortnight. A second location that only runs occasionally will keep hitting that, so the window is wider now. Nothing else changes: already-reviewed and posted deposits are skipped as cheaply as before, and the per-refresh build cap still bounds the work.
- The one-time backfill is back: /api/deposits/backfill?since=2026-07-01 (signed in) ingests every Square payout back to that date as review-ready splits, for anything older than even the 30-day window. It reuses the normal ingest, so it never posts to QBO, never overwrites a deposit you've edited or posted, and is safe to re-run — if a wide range doesn't finish in one call, call it again to drain the rest. (This endpoint was documented in the v0.24 notes but had been removed from the code; it exists again.)
- Deposits now supports more than one Square location. Set SQUARE_LOCATION_IDS (comma-separated) in the trickster config scope instead of the single SQUARE_LOCATION_ID, and payouts from every listed location get pulled in, split, and posted the same way — no separate setup per location, and Square catalog category mappings carry over automatically since the catalog is shared across locations on one merchant account.
- A payout from any location past the first shows a “· Location 2” (etc.) tag next to Square in the Deposits list, in the order the locations are configured, so it's obvious which venue a deposit belongs to once more than one is live. Existing single-location setups are unaffected — leave SQUARE_LOCATION_ID as-is and nothing changes.
- The payroll overhead reclass is back, and it now runs itself. Payworks books every run's wages to cost of labour, so half of James' salary was sitting in COGS and making each event look less profitable than it is. Nothing has moved it since Jul 5 — the old in-app payroll module was removed that day and the adjusting entry went with it. Set it up under Settings → “Payroll overhead reclass”.
- How it works: each Refresh watches QuickBooks for a new Payworks journal entry (recognized by the credit to your payroll clearing account) and books one two-line adjustment against it — debit the overhead account, credit the labour account. One entry per payroll run, numbered PR-RC-<pay date>, dated the same day as the payroll so the two sit together.
- You tell it the amount, because the Payworks entry can't. That entry is account-level — it says how much went to cost of labour in total, never who was paid what — so there's no per-employee figure to read. Enter the person's gross per pay plus an overhead % (James, 50%), or a flat amount per run if that's simpler. The panel shows the exact dollar figure that will post before you save.
- Guardrails: it's off until you turn it on and set both accounts; a reclass larger than the payroll run itself is flagged instead of booked (that means the gross is stale — a raise, or a changed pay frequency); a run can only ever be reclassed once, even if two refreshes overlap; and each posted entry is re-checked against QuickBooks, so one deleted there stops reading “In QBO ✓” and offers a Re-post.
- The history under the settings shows every reclass, what it moved, the basis it used, and a link straight to the entry in QuickBooks — so “did this happen for the last run?” is answerable without opening QBO.
- Catching up on what was missed: it looks back 60 days, so the runs since Jul 5 get their adjustment on the first Refresh after you configure it. If you already booked one of those by hand, delete your manual entry in QuickBooks — a duplicate under the app's own PR-RC number is impossible (it checks first), but it can't recognize a hand-written one.
- Bills no longer land on the bare “Cost of Goods Sold” parent. When the pipeline couldn't work out a vendor's expense account it used to book to that top-level account anyway — the bill posted, the total was right, and the amount sat on the roll-up line uncategorized. Worse, it learned from itself: one posting there became that vendor's history, so every later invoice from them went to the same place and the pile only grew.
- An undecidable account is now a review item instead of a guess. The receipt waits in this tab with an AI-suggested account pre-filled and an amber “Check the account…” note. Pick the account once and it's saved as that vendor's rule — every future invoice from them books itself correctly, with no review.
- Roll-up parent accounts (any account with sub-accounts under it) are gone from the account pickers, on receipts and deposits alike. QuickBooks lets you post to one, but it shouldn't be an option — and the AI suggester is fed the same list, so it can't pick one either.
- Cleanup note: this stops new bills from piling onto the parent, it does NOT move the ones already there. In QuickBooks, run an Account QuickReport on Cost of Goods Sold and re-categorize what's sitting on the parent itself; once a vendor's history is consistent the pipeline picks it up automatically.
- You can now undo a payment on a run you've ALREADY closed. Previously undo only worked while the run was open — once you reconciled, a bill marked paid by mistake was stuck that way. On Pay-run history, expand Payments on any closed run and hit “undo…” next to the offending payment.
- It's a deliberate two-step with a warning, because it touches a reconciled run: it spells out that the run's own figures and your Bank balance control number are NOT adjusted (correct the balance yourself in Settings if the correction changes it), and it requires a note. What it does do is put the bill back on the pay list as still owed.
- The reversal is recorded, not hidden: the payment stays in the history struck through, marked “↩ Reversed <date> — <your note>”. A closed run's totals deliberately still include it (that's what you confirmed against your bank at the time — history isn't rewritten), and the “Paid this run” line notes “incl. $X since reversed” so the numbers are explainable.
- Payments now show their invoice number (#1234) in both “This run” and Pay-run history — so when two bills from the same vendor are in a run, you can tell which one you're about to reverse.
- New “Paying this run” list at the top of the cash ledger — every bill you're about to pay, with its invoice number, date and amount, plus the total. It's the worklist for bank Bill Pay, so you don't have to hunt the “#1234” off each row. It updates live as you drag, pin Pay/Defer, or mark rows paid, and says how many you've already done. Rows that genuinely have no invoice number (recurring obligations, artist payouts, tax returns) say so rather than showing a blank.
- PST and GST returns now outrank every other bill — by rule, not by the AI's judgment. They were quietly landing in the “important” tier because a tax remittance has no QuickBooks vendor to carry a tier, so they competed with any ordinary invoice. They're now forced to the top of the pay list, oldest due date first.
- A tax return is flagged “⚠ CRA / eTaxBC · penalties + interest”, and — uniquely — if you defer one it STAYS at the top of the ledger in red, spelling out what's still owed, instead of sinking to the bottom with the other deferred bills. Deferring a remittance is the one deferral that costs real money (penalties + daily compounding interest), so it shouldn't be the easiest one to lose track of.
- Close run & reconcile is dramatically faster. It was blocking on a full AI re-ranking of every bill before the dialog would close (tens of seconds). Reconciling changes your available cash, not which bills matter most — so it now carries the existing priority order and your Pay/Defer pins forward and just re-runs the cash cascade. Same for saving a new bank balance in Settings. The “Re-rank” button still does a full fresh analysis whenever you want one.
- Your Pay/Defer pins (📌) now survive a rebuild of the run. They used to be silently reset every time the pay list was rebuilt.
- Dragging a bill to reprioritize, pinning Pay/Defer, and “Pay all” for a vendor are all much snappier — each was firing one database round-trip per bill (and “Pay all” several per bill); they're now batched into a fixed handful regardless of how many bills are in the run.
- Cash flow: a deferred bill now shows the amount you still owe, in parentheses — e.g. ($412.30) — instead of a blank “—”. It's parenthesized because that money isn't leaving the bank in this run, so the running-cash column is unchanged; you can just see the size of what you're putting off when you decide whether to pay it after all.
- The deferred divider now carries the total: “deferred · not paid in this run · $2,180.55 still owed (6 bills)”.
- “Notes for the AI” on a vendor rule now actually reaches the AI. It was saved but silently ignored by the receipts pipeline; now, once the vendor is identified, extraction re-runs with your standing notes as authoritative guidance — so you can teach it things like “the invoice # is the top-right number, NOT our customer number” once, and every future receipt from that vendor obeys.
- The extractor is much more careful about which number becomes the doc #: it now refuses customer/client/account/store/PST numbers (they repeat on every invoice — and a repeated doc # can make a real bill look like a duplicate and silently skip posting), knows that BCLDB licensee order forms put the order number unlabelled at the top-right, and cross-checks the email subject/filename for the number the vendor themselves used.
- Vendors page: vendors merged into another (or deleted) in QuickBooks now drop out of the priority list into a collapsible “Merged / removed in QBO” section, so triage only shows vendors you actually pay.
- Settings “Save” now confirms with “Saved ✓” (and shows “Saving…” while it works). Changing your bank balance auto-re-runs the analysis, so the dashboard text isn’t stale — unless this week’s run is already approved, which is left untouched.
- Recurring obligations (rent, SQRQ…) can now be mapped to a real QBO vendor, so they stop showing as “Unknown” on the dashboard — and they’re editable right on the Liabilities page (add/edit/delete), not just Data.
- A long-term-liability vendor’s recurring obligation now appears on the weekly cash view (mapped to the vendor) as the real cash commitment, while its underlying QBO bills stay on the Liabilities page.
- Cash is installable as an app: an “Install app” button appears in the nav (Chrome/Edge desktop + Android; on iPhone use Share → Add to Home Screen). Opens in its own window with a Cash icon.
- Deposits: one-time backfill to catch up older payouts beyond the usual 14-day window — visit /api/deposits/backfill?since=2026-06-01 (signed in) and it ingests every Square payout back to that date as review-ready splits. Safe to re-run; if a big range doesn't finish in one go, hit it again to drain the rest. The everyday refresh window is unchanged.
- Deposits: “Re-build all pending” button — re-runs the classifier on every not-yet-posted split (needs-review + error) using fresh Square data and your current mappings, in one click. Use it after changing a mapping or fixing a Square tax setting. It replaces those splits' draft lines, and deliberately leaves alone anything you've hand-edited (so your edits aren't lost) and anything already posted. A confirmation spells this out before it runs; a large backlog rebuilds in batches (click again to continue).
- Deposits: fixed QBO “429” rate-limit errors during “Post all ready” — deposit posts now run one at a time (QBO throttles per company, and the company is shared with our other tools), and any transient 429/503 now backs off and retries automatically instead of failing the split. Bulk posting a backlog just takes a little longer; nothing errors out.
- Deposits: “Post all ready” button — one click books every reviewed split that's mapped, balances to the cent, and has landed; anything needing attention is skipped and reported. (Never touches already-posted splits, so no re-match dance.)
- Deposits: fixed “in transit” sticking on payouts that are already in the bank — a payout now counts as landed once its deposit date is today or past, not only when Square's (refresh-stale) status flips to PAID.
- Deposits: the “Lands” column is now “Deposit Date” (the date the QBO deposit is dated / the bank-feed match date).
- Deposits: each split now shows when it was Built/Rebuilt, last Edited, and Posted to QBO (expand the row).
- Deposits: the mapping table now expresses INTENT (what each category should collect — e.g. Cover/Tickets → GST only), and the builder reconciles it with REALITY per deposit: if Square actually collected a tax the intended code can't carry, that deposit's line is coded to the smallest QBO code that can carry it, with an amber ⚠ note naming the category and the collected tax — your cue to fix the Square item/channel settings. Once Square matches the intent, the override stops firing by itself.
- Cover/Tickets and Uncategorized are mapped back to your intent (GST); the tax-code snapshot now records each code's rate composition to power the check (kicks in from the next Refresh).
- Deposits: after a SUCCESSFUL post, if what Square collected doesn't match what the coded sales imply at their rates (e.g. covers charged 7% PST on the door but $0 online), the row shows an amber ⚠ note with collected vs expected per rate — a pointer to fix the Square tax settings. The deposit itself always books the exact collected amounts.
- Mappings: Cover/Tickets and Uncategorized reverted to GST/PST BC — Square still collects PST on door covers, and a tax can only book if some line's code carries its rate. Rule of thumb: codes with extra rates are harmless ($0), missing rates block the post — when unsure, pick the broader code.
- Deposits: fixed posting splits where Square collected NO tax but the categories are tax-coded (e.g. untaxed online ticket sales) — QBO ignores “tax inclusive” on deposits and was adding 12% on top, drifting the total (the post-check caught it and deleted the deposit, leaving an error). Tax-coded lines now always book through the exact-override path with every code-implied rate pinned to $0.
- Deposits: each posted deposit's QBO memo now carries a visible “posted YYYY-MM-DD HH:mm PT” stamp so you can see when it was booked.
- Deposits: rows no longer jump to the top of the list while posting and back afterwards — they stay put; the “Posting…” chip shows progress in place.
- Deposits: a row stuck on “Posting…” now updates itself — the page polls while a post is in flight, so the chip flips to Posted/Error without a manual reload.
- Re-posting a deposit that's already matched in the QBO bank feed fails with a clear instruction (undo the match in Banking → Categorized first, then re-post and re-match) instead of QBO's cryptic 6480 “Matched Transaction Delete Error”.
- Deposits: diagnosed QBO's “encountered an error while calculating tax” (error 6000) on tax-aware posts — the combined “GST + PST Liquor” code in QBO was built from the 0% “GST ES” (exempt) rate instead of the real 5% GST, so QBO couldn't allocate the GST override across the alcohol lines. The poster now catches this shape before posting: when a tax amount implies more taxable sales than the lines carrying that rate add up to, it fails with a plain-English error naming the suspect tax codes. Fix in QBO: recreate the combined code from the real GST 5% + PST Liquor 10% rates, remap alcohol categories, Re-build, re-post.
- Deposits: an open split row now updates on screen when its lines change server-side (Re-build, a mapping save refilling pending splits, a refresh upgrade). Before, the row kept showing its old lines until a full page reload — which made Re-build look like it hadn't applied the new tax codes.
- Deposits: fixed the “Invalid Tax Rate” post error — QBO only accepts tax amounts for rates carried by some line's tax CODE, so taxed income categories now need a code (one-time, in the mapping table: alcohol → a combined GST + PST Liquor code, soft drinks → GST/PST BC, food → GST). The poster validates this up front with a plain-English error naming the right codes, and pins any extra code-implied rate to $0 so QBO can't drift the total.
- Deposits: investigating QBO's “Invalid Tax Rate” on tax-aware posts — added a read-only tax-structure diagnostic (/api/refresh?debug=taxes) and rate-id logging on the poster.
- Deposits: “Re-build” now clears a split's old post error (and flips Error back to Needs review) — a fixed split no longer keeps shouting last attempt's failure.
- Tax names with special characters (e.g. “GST/PST Liquor (Sales)”) display and match correctly — QBO returns them HTML-encoded and they're now decoded everywhere.
- Deposits: the tax pickers are now dropdowns of your REAL QBO names — income lines pick from your tax codes, tax lines from your sales tax rates (e.g. “PST Liquor (Sales)”) — snapshotted from QBO on every Refresh. No more free-typing names QBO has to match; a saved name QBO doesn't recognize shows with a ⚠.
- Posting is also more forgiving: a tax line named “GST” finds your “GST (Sales)” rate automatically when the match is unambiguous.
- Deposits: “Re-build” is now available on POSTED splits too — re-posting an old split reused its pre-tax-passthrough lines (deposit landed “Out of Scope of Tax” in QBO). Now: Re-build (pulls fresh tax-aware lines), then Delete & re-post books it correctly.
- Deposits now track your tax obligations exactly: the GST / PST (liquor 10%) / PST (7%) that Square actually collected ride each split as their own tax lines — exact cents, straight from the register — and income lines are pre-tax. Posting books the taxes through QuickBooks' sales tax module (Sales Tax Centre / returns see the real collected amounts), not as a rate re-computation.
- Map each Square tax to its QBO sales tax rate once in the mapping table (new “Square tax” rows — GST defaults sensibly; set the PSTs). A safety check after every post verifies QBO booked the exact bank amount; if its tax engine disagrees, the deposit is removed and the split shows the error instead of stranding a mismatched deposit in QBO.
- Existing pending splits upgrade themselves to the tax-aware format on the next Refresh (owner-edited and posted splits are left alone — use “Re-build” on those if you want the tax lines).
- Bank balance fixed: QBO's book balance was −$13.9k because months of deposits sit unbooked in the bank feed. The forecast now uses a working balance = QBO book balance + landed Square deposits that are still awaiting categorization on the Deposits tab (real money the books haven't caught up to). It self-corrects: each split you post moves from the adjustment into the book balance. The stat shows the math.
- Nothing is auto-reserved anymore — the buffer you set in Settings is the only held-back amount. Critical vendors and artist payouts now sit in the movable pay list with everything else (critical still ranks first); the whole list stays live so you can shuffle what little cash there is.
- Fixed the top-nav Refresh crashing the app (“Application error: a client-side exception…”): the refresh grew past its server time budget once deposit splits joined it, and the timed-out call took the page down. The budget is now 3 minutes everywhere, the refresh itself got faster, and if it ever fails again you get a “Refresh didn't finish — try again” note instead of a broken page.
- Deposits: dropped Eventbrite from the tab — EB remittances have no category split, so they stay on the cash forecast only and get matched in the bank feed directly. The tab is Square payouts only now.
- Deposits: account pickers no longer hide accounts by type — your COGS-typed sales accounts now lead the list (“Suggested”), with every other account reachable under “All accounts.”
- New Deposits tab: every Square payout and Eventbrite remittance arrives pre-split into your sales categories (Draft, Wine, Well Booze, Zero-Proof, Food, …) from what was actually sold — minus Square's fees and the 10% loan holdback — so the split equals the bank deposit to the cent. Review, tweak if needed, and Post to QBO; the bank feed then matches the deposit automatically. No more adjusting journal entries.
- Map each Square category to its QuickBooks income account once (bottom of the Deposits tab); every future deposit books itself. Unmapped items land in “Uncategorized sales” for you to sort.
- Recurring bills: mark a receipt's vendor as “Repeats” (weekly/biweekly/monthly) and the forecast anticipates the next invoice. When the real bill arrives it replaces the projection — small variances (the internet bill that moves a dollar or two) match automatically; bigger ones ask you to confirm.
- Receipts: the Type selector is now Bill (owed) / Paid receipt / Credit — so you can fix the AI when it mistakes a bill for an already-paid receipt (or vice versa). Picking “Paid receipt” asks for the paid-from account; save (or Delete & re-post) books it as the right QBO entity.
- Fixed the “QBO ↗” / “View in QBO” links: they now use app.qbo.intuit.com so QBO opens the actual bill instead of redirecting to a blank page (the bare qbo.intuit.com host dropped the transaction id).
- The Receipts nav link now shows a red count bubble for how many receipts need review.
- The “Watch” section on the dashboard has a ▸ chevron that rotates when open, so it's clearly expandable.
- Cash flow: the pay/defer badge is now a compact dropdown (Auto · pay / Pay / Defer) that sets the pin inline — replaces the separate Pay/Defer buttons to save horizontal space.
- Cash flow is now pay-priority ordered: drag a bill to reprioritize and pay/defer re-cascades from your available cash (pay top-down until it runs out); a “cash runs out here” line shows the cutoff.
- Pin any bill to Pay or Defer (📌) to override the cascade, or Auto to hand it back. Pinning asks an optional “why?” that’s fed to the ranker so it learns your preferences.
- Receipts: a receipt folded into another now shows its status as “Combined” instead of “Ignored,” and the combine note no longer reads like an error.
- Talent settlements pushed from Jimmy now land here as real QBO bills, due the day after the show — and the soft “Artist (est.)” estimate for that show drops off so it's never double-counted.
- Those bills show a “Proof ↗” link on the cash ledger (next to “QBO ↗”) that opens the original settlement in Jimmy — the calc, the door split, and the plain-English explanation.
- Long-term liabilities: flag a vendor (e.g. SQRQ) as “LT liability” on the Vendors page and its QBO bills move off the cash view to the new Liabilities page; the real cash commitment is the recurring obligation you pay.
- Recurring obligations now show OVERDUE occurrences (e.g. last week's + this week's $2,500), and recurring/payout rows on the ledger have a “Mark paid” button so you can clear each as you pay it.
- Square: completed (closed) business-day batches now count as expected deposits on the cash timeline + in available cash, at the accurate net (90% − fees). Today's active sales stay reference-only (not counted). Replaces the old payout-feed number that lagged until Square cut the payout.
- Square: the pending/“not yet paid out” estimate now uses the real payout formula — 90% of card sales minus fees (the other 10% is withheld off the top to repay the Square loan) — so each day's Net matches what actually deposits (e.g. it now lands on Square's pending instead of being ~$50–200 high).
- Settings: bank accounts that count as cash are now checkboxes of your real QBO account names (no more typing names that must match exactly).
- Cash Flow: the “Reserved + buffer” stat now includes the safety buffer, so it ties out with Available.
- Square: the “not yet paid out” estimate now counts full business days (was truncating the latest day), so it tracks closer to Square's pending.
- Receipts: added an editable PST field so you can correct a missed PST and re-post it to QBO.
- Extraction now captures PST on beer/brewery/liquor invoices (it was wrongly assuming alcohol is PST-exempt).
- Unified Refresh: one “Refresh” button in the top nav now does everything — QBO, Square, recurring obligations, artist payouts, the receipts QBO comparison, and the re-rank — with a “last updated …” marker (also reflects the nightly cron). The per-page Refresh buttons were removed.
- Receipts: the QBO ✓/⚠ accuracy comparison now refills automatically right after you post or re-post (no separate Refresh needed).
- Receipts: removed the small inline document preview — use the “View original” link to open the full receipt.
- This Help & guide page — opens to the section for whichever module you came from, with a changelog of releases.
- Artist payouts: what you owe acts/organizers is pulled from the event tracker and shown on the cash ledger as reserved “Artist: …” outflows, dated by the deal's settlement terms (guarantees exact; door splits estimated from ticket sales, firming up at settlement).
- Receipts ↔ QBO accuracy check: each posted receipt is compared to what actually landed in QuickBooks (✓ matches / ⚠ differs), and entries deleted in QBO flip back to review.
- PST is now booked as a non-recoverable expense line (was being dropped).
- Bills book with the invoice's own due terms, defaulting to due-on-receipt (no longer inherit the vendor's stored QBO term).
- Combine tool: merge an itemized bill + its card slip into one expense, adding a no-GST tip line; both images attach to QBO.
- Owner memo on a receipt → posts to the QBO transaction's note (e.g. who you dined with).
- Persistent “Posting…” status that survives leaving the page.
- Recurring obligations (rent, SQRQ loan paydown) generate weekly/monthly ledger entries; managed on the Data page.
- QBO deep-links (“QBO ↗”) on every bill row in the cash ledger.
- Receipts: AI pre-picks the expense account; your correction trains it for that vendor next time. Plus exact GST, reliable account dropdowns, and an in-app Refresh on the Receipts tab.
- Receipts: inline document preview + match-or-create vendor/account dropdowns.
- Dark mode toggle.
- Receipts: correct-and-post to QBO (Bill / Vendor Credit / paid-receipt Purchase) + per-vendor rule learning.
- Receipts inbox: every vendor invoice the pipeline processes is stored and shown here.
- Pending Square deposits factored into available cash; unified cash ledger with a running balance.
- Vendor tiers save-on-change and feed the ranking; owner overrides are logged and taught back to the AI.
- First release: QBO open bills + bank balance, Claude-ranked weekly payment run.