Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Money Trail: track money owed to the business, chase it through Send on approval, and show what was paid

Open
  • Is something wrong?
#466 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
8/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
typescript
Domain
ai, backend

Research direction

This is a design-heavy feature, not a starter task. Read src/shared/quickbooks.ts for the allowlisted AR tools, then src/main/mailApprovals.ts and src/shared/mailProposals.ts for the Send on approval flow. Settle the ledger shape and the cadence rules with maintainers before coding. Done means the MVP in the issue: open-money.json is written, reminders become proposals, and a Report card shows paid-after-reminder.

Written by the indexing model from the issue text.

Description

Problem / motivation

The office does money work, but nothing proves it got the owner paid.

The home services pack already tells the team to chase money. The Finance Work style says "List overdue invoices with customer, amount and days late" and the Sales one says "When a quote goes three days without an answer, draft a short reminder" (resources/packs/home-services.json). Both live only in a prompt. The app keeps no record of which invoice is overdue, which reminder went out, or whether the customer then paid. So the owner can't answer the one question that decides whether they keep paying for a Claude plan: "Did the office get me paid?"

Existing issues measure activity and cost, not money in:

  • #81 (weekly digest) counts work done. The "time saved" estimate was dropped there because owner-set minutes would be wrong for nearly everyone.
  • #319 (track record) is cost and how often work was used as is.
  • #47 / #51 verify that a task finished, not what it earned.
  • #252 hunts new leads; nothing follows up the money already owed.
Proposed solution

Money Trail: an app-kept ledger of money owed to the business, chased through Send on approval, and reported from real amounts and dates only.

  1. Read what is owed. A weekly starter job for the Finance member reads QuickBooks receivables. qbo_accounting_get_ar_aging_detail and qbo_sales_get_invoices are already on the read allowlist in src/shared/quickbooks.ts. The member hands the rows to the app (hive message), and the app writes open-money.json: invoice id, customer, amount, due date, days late, last reminder, outcome.
  2. Chase on a cadence. At 1 / 7 / 14 / 30 days late, the member drafts a reminder. Every one goes through the existing Send on approval flow (src/main/mailApprovals.ts, src/shared/mailProposals.ts). There is a cap of 3 per invoice. Once the owner has approved a template enough times, a standing approval can take over, as it does for other mail today.
  3. Close the loop from dates, not from the model. On the next QuickBooks read, an invoice that went from open to paid after an approved reminder is marked paid after reminder with both dates. The app computes this. It is never taken from Michael's memory or wording, and it never claims "because of".
  4. Show it where the owner already looks. A Monday Report card (src/shared/askMeRouting.ts) says: "$4,200 overdue across 9 invoices · 6 reminders approved · $1,900 paid after a reminder (3 invoices)", with each invoice listed.

Phase 2: the same ledger for quotes. Track quote threads from the mailbox (threadFrom in mailProposals.ts): sent date, last reply, nudge due. A silent quote at day 3 / 7 becomes a draft nudge on Needs you, capped at 2 per thread. The owner marks it Won / Lost on the card. This turns the existing "three days" rule into state the app keeps.

Why it matters for the business, not just the owner

  • It is the first number in the app that is in dollars earned rather than dollars spent. Today the cost views (costLifetime.ts) show only the cost side. Putting "$X paid after a reminder" next to "$Y spent on the Claude plan" is the clearest case for keeping the office running and for recommending it to another owner.
  • It is local-first and owner-approved. SMB collections and follow-up tools mostly run as cloud SaaS (Podium, Birdeye and GoHighLevel are roughly $97–$599/mo) and cannot show "paid after a reminder" from the owner's own books.
  • It reuses what exists: QuickBooks read tools, Send on approval, standing approvals, starter jobs, packs and Report cards. No new connector and no new outbound channel.

MVP (about 1 week): one starter job in the home services and professional services packs, open-money.json plus its writer, a cadence that writes proposals, and one Report card. It is skipped cleanly when no QuickBooks is connected.

Success metric: share of overdue dollars paid within 14 days of the first approved reminder, compared with the same office's first 2 weeks before Money Trail was on. Secondary: days sales outstanding, and the number of owners who approve at least 1 reminder in their first week.

Risks and constraints
  • QuickBooks is a Claude account connector (#320), so the app can't read it directly. The ledger is only as good as the member's handoff. Mitigation: store the raw QuickBooks ids and amounts, and recompute paid / unpaid on every read.
  • Customer money mail is sensitive. It stays Send on approval by default, with a hard cap per invoice and no reminder to a customer the owner has marked "don't chase".
  • Attribution wording stays factual ("paid after"), as #81 set for estimates.
  • Engine coupling: like #320, this depends on a Claude connector until #85 and #109 land.
Alternatives considered
  • An estimated "time saved / money saved" figure. Rejected in #81 as wrong for most owners. Money Trail uses only amounts and dates from QuickBooks and the send log.
  • Leave it to the prompt, as today. The work happens but nothing is kept, so nothing can be shown or trusted.
  • Missed-call text-back / review requests. These have strong market demand but need an always-on phone or SMS channel, which a desktop app doesn't have.
Dominant language
TypeScript
Stars
273
Forks
211
Avg merge
13h
Merged PRs (30d)
197

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from agentvivekkumar/dontbemichael

All issues in agentvivekkumar/dontbemichael

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.