Skip to main content

Finance Receipt Sweep

Verify that nothing receipt-like or transaction-like has been missed by the finance dashboard. The dashboard is only as good as its inputs: bank data arrives through Plaid, but several real obligations announce themselves only by email, and some accounts are not linked to Plaid at all. This sweep reconciles all three sources so the stakeholder hears about a missed item from the agent, not from a late notice.

When to run​

  • On request ("check my email for receipts", "make sure nothing was missed").
  • Before reporting that a due bill is unpaid, when the payment might have been made outside the tracked accounts.
  • After the stakeholder reports making a payment or a schedule change, to confirm it landed.

Default lookback window: 48 hours. Widen only when the stakeholder asks or a specific older item is being hunted.

Sources — check all of them​

  1. Gmail (jknash@gmail.com) — Chase alerts and scheduled-payment confirmations, store e-receipts, order receipts.
  2. Outlook Mail (Justin's personal mailbox) — this is where the money mail lives: Affirm (all of it; Gmail has no Affirm mail), Apple receipts, Flex notices, card alerts from issuers that are not Plaid-linked.
  3. Plaid — Chase (checking, savings, Disney Visa card) and SoFi. Read accounts first, then transactions for the window including pending rows.

Search terms per mailbox: receipt, payment, order, subscription, invoice, charged, renewal, transaction, bill, statement, past due. Exclude promotions and social categories; a receipt is transactional mail, never a marketing blast.

Deduplication rules​

One real-world transaction counts once, no matter how many traces it leaves:

  • The same purchase often produces a receipt in both mailboxes plus a pending line in Plaid (example of record, 2026-10-03: one $16.00 Meta charge generated a Meta receipt in Gmail, a Stripe receipt in Outlook, and one METAPAY pending debit — one item, reported once).
  • Match traces on merchant + amount + date before calling anything new.
  • Cross-check against what the dashboard already knows (registry bills, the latest snapshot, the current bill-watch state) and label every finding new or already tracked. Never present a tracked item as a discovery.

Bank cross-check (Plaid)​

  • Confirm the checking account's current-minus-available gap equals the sum of its pending debits. If it does not reconcile, something pending is unexplained — find it before reporting.
  • Look specifically for:
    • Payments to the Chase card — they post as a payment out of checking and a "Payment Thank You" into the card. A Chase "payment is scheduled" email states the amount and effective date; match it to the posting before calling the payment pending.
    • The monthly Zelle to Michele — $2,000, around the 1st, a registered bill. If the stakeholder says it was sent but Plaid shows nothing posted or pending, say exactly that: bank data may lag a same-day send, and an absent row is not proof a payment failed. Never fabricate a posting to close the question.
  • Plaid data may lag the bank. Report the pull time with any "not there yet" finding.

Flex rule — email dates win​

Flex rent is two monthly installments (installment 1 around the 30th/1st, installment 2 on the 15th). Flex's emails are authoritative for installment dates. The stakeholder reschedules inside the Flex app, and the email is the record.

When a Flex reschedule email arrives ("Your payment has been rescheduled — we'll now charge your 2nd payment of $1,287.50 on Mon, Oct 19th"):

  1. Add a one-off exception to the bill's registry entry: a date_exceptions entry mapping the affected month (YYYY-MM) to the new day. Never change the standing schedule day for a one-off reschedule — later months keep the normal date.
  2. Regenerate the snapshot, commit, and deploy (see the refresh rule below).
  3. Note the source (email date and the new date) in the registry entry's notes.

Worked example: on 2026-10-04 the October installment 2 moved from Oct 15 to Oct 19. Safe-to-spend rose by exactly the installment amount ($352.65 to $1,640.15) because the charge now lands after the Oct 16 paycheck instead of before it. Date accuracy is allocation accuracy.

Accounts Plaid cannot see​

The X1 Card and Apple Card are not linked to Plaid; the dashboard does not see their balances, due dates, or payments. Email is their only signal, so surface their alerts explicitly on every sweep:

  • Past-due notices (example of record: Apple Card, 2026-10-02 — account 2 days past due, $220.00 past-due balance due immediately).
  • Limit warnings with amounts due (example of record: X1 Card, 2026-10-03 — balance $3,697.84, nearly at the limit, with a payment of $107 or more due by Oct 7).

Manually tracked bills (stakeholder-approved 2026-10-04)​

Both cards are tracked on the dashboard as manual bills in the bill registry (jknash/dashboard, scripts/bill_registry.json), under the machinery built for email-sourced obligations:

  • Registry flags: "manual": true and "source": "email". The snapshot generator stamps manual on the bill's history, upcoming-bills, and pay-cycle entries, so every consumer can see the figures are email-sourced, not bank-verified.
  • once occurrences only: each manual bill carries a single "schedule": {"type": "once", "date": "YYYY-MM-DD"} occurrence, with the amount and due date taken from the latest email evidence. Never invent a standing due day, minimum, or recurrence for an account whose cycle is not evidenced; balances are recorded in the entry's notes as context, never as occurrences.
  • The matcher never marks them paid: the generator skips manual bills in transaction matching unconditionally — no bank transaction may verify them. An occurrence leaves the unpaid state only when a sweep updates the registry entry from new email evidence (a statement, a due notice, or a payment-confirmation email).
  • Maintenance is part of every sweep: when a sweep surfaces a new statement, due, or payment email for a tracked manual account, replace the entry's once date and amount from that evidence (or record the payment) and regenerate the dashboard per the refresh rule below. If the email is ambiguous, escalate rather than guessing.
  • Adding an account is a stakeholder decision: never add a manual bill unilaterally — allocation changes are the stakeholder's call, routed through the chief of staff.

Worked examples (added 2026-10-04 at the stakeholder's direction):

  • Apple Card (apple-card-manual): one occurrence, $220.00 due 2026-09-30 — the amount from the past-due notice above (2026-10-02), the date from Apple's "payment is due today" email of 2026-09-30, the same statement cycle.
  • X1 Card (x1-card-manual): one occurrence, $107.00 due 2026-10-07, from the limit warning above (a payment of $107 or more due by Oct 7). The $3,697.84 balance sits in the registry notes as context only.

Zero-dollar statements​

A statement email is not automatically a bill. Check the amount: Spectrum Internet statements (2026-09 and 2026-10) show a statement amount of $0.00 — record them as checked, not as missing bills.

Dashboard refresh rule (standing order)​

Any Plaid pull ends with the dashboard refreshed, no exceptions:

  1. Regenerate the snapshot with the generator in jknash/dashboard (scripts/build_finance_snapshot.py) from the fresh pull, using a 120-day transaction window.
  2. Commit the snapshot (site/finance/data/finance.json) plus any registry or generator changes to jknash/dashboard on main.
  3. Deploy with the Cloudflare tooling (cf.py deploy).
  4. Verify from outside: the landing page returns 200 and the finance section returns the Access 302.

Reporting format​

Keep it short and in this order:

  1. What was checked (accounts, window, pull time).
  2. New items — anything not already tracked, with amount, date, and source.
  3. Confirmations — expected items found where they should be (scheduled card payment matched, Zelle visible or explicitly not yet visible).
  4. Anything the dashboard cannot see (unlinked-account alerts) and any date the sweep changed.

Guardrails​

  • Read-only toward the bank: never move money, pay a bill, or schedule a payment.
  • Never ask the stakeholder to paste credentials; use the connected accounts.
  • Amounts and dates come from the message or the bank record in front of you — never from memory of a previous sweep. Re-pull, re-read, then report.

Source: authored in-fleet by Muse (chief of staff) on 2026-10-04 for Justin's finance agent. Companion pieces: the bill registry and snapshot generator live in jknash/dashboard under scripts/; the live dashboard is the workbench finance section.

Published by Muse · 2026-10-04.