invoice-chaser

# Invoice chaser Turn "they have not paid yet" into a sent follow-up, without chasing anyone who already paid. ## Purpose A solo operator or small agency invoices from three or four surfaces and reconciles from none of them. The invoices live in Stripe, PayPal, GoHighLevel, an accounting tool, and the sent-mail folder. The payments land in a bank account, a processor balance, a payout summary, and occasionally an envelope. Nothing joins the two, so "who owes me money" is a question the user answers by memory and guilt. That matters more than it sounds. 59% of US small businesses report at least some invoices overdue by 30 or more days, averaging $17.7K outstanding per business, and 39% of owners say a single late payment made it hard to cover payroll or bills [references/research/distilled-receivables-collection.md, section 2]. Collection potential falls from 88.7% at one month past due to 68.9% at three months and 21.4% at twelve [references/research/distilled-receivables-collection.md, section 1]. Waiting is expensive in a way that compounds. Littlebird capture reads every one of those surfaces, because the user looked at them. This skill joins them. ## The problem this skill is built around **You cannot prove a negative from screen capture.** "I never saw a payment" is not "they did not pay". A payment can arrive in a bank account the user never opened on screen, in a processor dashboard they did not visit that week, as a check, over Zelle, or into an account a bookkeeper manages. All of those produce the same signal here: silence. This is not a rare edge case. A funded AR team with a bank feed and a general ledger still loses payments, because "ACH and wire transfers move money electronically but often travel separately from the remittance advice that identifies which invoices the payment covers", and "Missing remittance is not an edge case: It is standard behavior" [references/research/distilled-receivables-collection.md, section 7]. This skill has less information than that team, not more. The cost of getting it wrong is the highest in this marketplace. In a vendor's own words: "Calling a customer to demand payment on an invoice they already paid three weeks ago is one of the most damaging interactions in the AR function", after which the client contact "becomes less responsive to future outreach because they now associate the AR team with errors rather than professional account management" [references/research/distilled-receivables-collection.md, section 7]. A wrong chase costs a relationship. A missed chase costs a reminder. **Three design consequences, all mandatory:** 1. **Corroboration before overdue.** An invoice with no payment observation needs two independent supports before it is presented as likely outstanding [references/payment-reconciliation.md, section 5]. One support or none is not enough. 2. **A verify-first tier.** Anything the skill could not resolve goes to "possibly already paid, verify first" with a ninety-second instruction for checking, not to a chase list [references/aging-and-verification.md, section 2]. 3. **A mandatory verification gate.** No draft is written, shown, or described until the user confirms each invoice individually [references/aging-and-verification.md, section 3]. There is no reconciliation state called `UNPAID` in this skill's vocabulary. Capture cannot produce one. Only the user can. ## Capability gate This skill requires the Littlebird MCP server on a Power or Pro plan. 1. **List the available tools before calling anything.** Use the real tool names from the live server. `references/littlebird-mcp-reference.md` records what was verified on 2026-08-17. It is a starting point, not a guarantee. 2. If no Littlebird MCP tools are present, **stop** and tell the user this skill needs the Littlebird MCP connected. Do not attempt the audit from another source. 3. If tools are present but plan status is in doubt, call `LB_INTERNAL_GET_SUBSCRIPTION_STATUS` and report what it says. 4. **Separately, list the session's other connectors.** Stripe, PayPal, QuickBooks and the rest are their own MCP servers. Do not assume any of them exists. If one is present, use it to reconcile and say so. If none is present, the skill still runs from capture alone, every line is labeled capture-derived, and the verification gate carries more weight [references/payment-reconciliation.md, section 6]. ## Littlebird MCP calls used | Call | Used for | |---|---| | `search_user_context` | Everything. Invoice discovery, payment reconciliation, client payment talk, prior-chase history. Windowed, per client, narrow queries in parallel. | | `LB_INTERNAL_LIST_MEETINGS` | With a future `end_date`, to find an upcoming meeting with an overdue client. A scheduled call outranks an email in the ladder [references/follow-up-ladder.md, section 4]. | | `LB_INTERNAL_SEARCH_MEETINGS` | Where a client discussed payment, scope, or a dispute in a recorded call. | | `LB_INTERNAL_GET_MEETING` | To read the structured summary, especially Decisions and Action Items, for anything agreed about payment. | | `LB_INTERNAL_GET_ROUTINE_REPORTS` | Read the receivables watch routine's own past reports before every run, so the ladder knows which rung each client is already on. | | `LB_INTERNAL_CREATE_ROUTINE` | To offer and create the weekly receivables watch. Interactive sessions only. | | `LB_INTERNAL_GET_ROUTINE_CONFIG`, `LB_INTERNAL_UPDATE_ROUTINE` | To read before changing an existing routine. `prompt` and `schedule` each replace wholesale. | | `LB_INTERNAL_GET_SUBSCRIPTION_STATUS` | Plan gate, and routine-count headroom. | There is no Littlebird tool that searches past Littlebird chat conversations. Where this skill needs prior conversation, it uses `search_user_context` with `filters.data_source: messages`. ## Trigger Fires on: who has not paid me, chase unpaid invoices, accounts receivable, AR aging, overdue invoices, outstanding invoices, payment follow up, invoice reminder, who owes me money, past due, collections, cash coming in, unpaid client work, follow up on that invoice. Also fires when the weekly receivables watch routine flags a bucket crossing and the user opens Cowork to act on it. ## Routine cadence **Weekly**, plus on demand. The routine observes and hands off; the interactive session does the reconciliation, the verification, and the drafting. Wiring is in [Routine wiring](#routine-wiring-the-receivables-watch) below. Weekly is the right frequency because the bucket boundaries that change the recommended approach sit 30 days apart, and a weekly check catches a crossing inside a week of it happening. Daily produces noise; monthly lets an invoice cross two boundaries unobserved. ## Process Seven phases. Phase 5 is not optional and has no bypass. ### Phase 1: scope Ask with `AskUserQuestion`, before sweeping: - **Window.** Default 90 days, walked one month at a time. Ask whether any invoice older than that is still open, since a 120-day invoice sits in the bucket where the archive places outside action [references/research/distilled-receivables-collection.md, section 1]. - **Where they invoice from.** Which processors, which accounting tool, whether any invoicing happens by plain email. - **Where money lands.** Which processor balances, which bank, whether they take checks or bank transfers. This list becomes the blind-spot list in the confidence note, and it is the single most valuable answer in this phase. - **Known exceptions.** Clients on a payment plan, clients on hold, clients in dispute. ### Phase 2: invoice discovery Follow `references/invoice-discovery.md`. Run the five query families, extract to the schema, deduplicate, and separate out the three exclusion lists. Run `scripts/aging_calc.py` on the candidate rows rather than collapsing duplicates by eye. OCR of an invoice list repeats rows, and the collapse rules interact in ways that are easy to get quietly wrong. Watch the direction trap: an invoice the user RECEIVED looks almost identical in capture to one they sent, and it is the fastest way to poison this report [references/invoice-discovery.md, section 6]. ### Phase 3: payment reconciliation Follow `references/payment-reconciliation.md`. Read section 1 before running anything else in this phase. Run the six payment query families **per client**, not as one sweep. Assign each invoice one of four states: `PAID-CONFIRMED`, `PAID-CLAIMED`, `UNRESOLVED`, `DISPUTED`. Count the independent supports behind every `UNRESOLVED`. Where a payments connector is available, reconcile against it, and where capture and the connector disagree, **the connector wins and the disagreement is reported** [references/payment-reconciliation.md, section 6]. ### Phase 4: aging and tiering Follow `references/aging-and-verification.md` sections 1 and 2. Compute days overdue from the due date with `scripts/aging_calc.py`, assign buckets, and place every invoice in exactly one of three tiers: confirmed paid, verify first, likely outstanding. Present the collectability decay as a shape with its source attributed, never as a forecast. Never multiply a balance by a decay percentage to produce an expected recovery figure [references/aging-and-verification.md, section 1]. ### Phase 5: the verification gate, mandatory Follow `references/aging-and-verification.md` section 3. **No draft is written, shown, or described before this gate passes.** Present each tier-3 invoice individually with its supports and receipts, each tier-2 invoice with its specific verification instruction, the blind-spot list, the unattributed cash total, and the open question about who is missing. Only invoices the user confirms move forward. Do not compress this into "I found five overdue invoices, shall I draft?" The entire risk lives in one line being wrong. ### Phase 6: the follow-up ladder Follow `references/follow-up-ladder.md`. For each confirmed overdue invoice, place the client on the rung its age and relationship warrant, draft the actual text at that rung and the next one, and respect the contact-frequency ceiling. Check prior contacts first. A client on their fifth contact does not get a "just following up" email that reads as though it were the first [references/follow-up-ladder.md, section 3]. If a personal voice skill is installed in the session, draft through it. If none is, say so plainly and point at this marketplace's voice creator skills. Never invent a voice profile. ### Phase 7: report, hold, offer the routine Write the three artifacts. Hold every draft. Offer to create the weekly receivables watch if it does not already exist, showing the user the exact prompt and schedule first. ## Output Three files in the working directory, dated with the run date. **`receivables-aging-YYYY-MM-DD.md`**, the report. Leads with the reconciliation confidence note [references/aging-and-verification.md, section 4], then the aging table, then the tiers, then the prevention notes. Aging table columns, exactly: | Column | Contents | |---|---| | Client | As written on the artifact | | Invoice ref | Or `unknown` | | Amount | As captured, with currency. No conversion, no cross-currency total | | Issue date | As shown | | Due date | With basis: `shown` or `derived` from terms | | Days overdue | From the due date, or `n/a` | | Bucket | current, 1-30, 31-60, 61-90, 90-plus, or unknown | | Payment status | PAID-CONFIRMED, PAID-CLAIMED, UNRESOLVED, DISPUTED | | Tier | confirmed paid, verify first, likely outstanding | | Supports | Count and list of independent supports | | Evidence receipt | Every receipt, in the canonical format, sorted by time | Grouped and subtotaled by bucket, per currency. Followed by: - **The verify-first tier**, each line with its specific check instruction. - **Disputes**, listed separately with the objection quoted and its receipt. - **Blind spots**, every account and payment method never observed on screen in the window. - **Unattributed cash**, the total of observed payouts that matched no invoice. - **Named gaps**, what was searched and did not turn up. **`receivables-aging-YYYY-MM-DD.csv`**, one row per invoice line in the same schema, machine-readable, receipts included. **`follow-up-drafts-YYYY-MM-DD.md`**, every drafted message, grouped by client, each headed `STATUS: HELD FOR APPROVAL. Not sent.` If the user names a different location, use it. If nothing was found, write only the report and have it say what was searched and what came back empty. ## Retrieval brief Every query runs through `search_user_context`, windowed one month at a time across the scope agreed in phase 1. Parallel narrow queries, never one broad sweep: a broad query against this server returns 70,000-plus characters and gets dumped to a file instead of returned [references/littlebird-mcp-reference.md, Oversized results]. **Discovery, 90-day window, five families** [references/invoice-discovery.md, section 2]: | Family | `filters` | Queries | |---|---|---| | A. Invoice sent | `data_source: snapshots` | "invoice sent to", "your invoice has been sent", "invoice was sent successfully", "invoice number amount due", "invoice due date net 30" | | B. Processor surfaces | `data_source: snapshots`, `app: chrome` | "Stripe invoices open paid", "PayPal invoice sent status", "GoHighLevel invoices", "QuickBooks invoice list overdue", "invoice status open due" | | C. Emailed invoices | `data_source: snapshots` | "please find attached invoice", "invoice attached for", "payment is due upon receipt", "here is the invoice for", "view and pay invoice" | | D. Client payment talk | `data_source: messages` via `search_queries_messages` | "did you get my invoice", "invoice for last month", "sending the invoice over", plus client names | | E. Activity digests | `data_source: summaries` | "invoice", "billed", "sent invoice", "payment terms", plus client names | **Reconciliation, per client, six families** [references/payment-reconciliation.md, section 2]. Window extends 14 days before that client's earliest invoice issue date. | Family | `filters` | Queries | |---|---|---| | P1. Payment received | `data_source: snapshots` | "you received a payment from CLIENT", "CLIENT paid your invoice", "payment received CLIENT", "invoice REF paid", "you have been paid" | | P2. Processor status | `data_source: snapshots`, `app: chrome` | "CLIENT invoice paid", "Stripe payments succeeded CLIENT", "PayPal payment received CLIENT", "invoice status paid CLIENT" | | P3. Payouts | `data_source: snapshots` | "payout to your bank account", "Stripe payout sent", "PayPal transfer to bank complete", "deposit summary", "balance available" | | P4. Bank and transfer | `data_source: snapshots` | "deposit from CLIENT", "ACH credit", "wire received", "Zelle payment from CLIENT", "check deposited" | | P5. Client says paid | `data_source: messages` | "CLIENT sent payment", "paid the invoice", "payment is on the way", "check is in the mail", "processing this week", "ACH went out" | | P6. Disputes and delays | `data_source: messages` | "hold off on that invoice", "waiting on our client to pay us", "can we push payment", "dispute the amount", "this was not what we agreed", "payment plan" | **Prior-chase history, per client**: `data_source: messages` plus `data_source: snapshots` for "following up on invoice", "second reminder", "past due notice", "just checking on the invoice". This sets the rung and enforces the frequency ceiling. **Upcoming meetings**: `LB_INTERNAL_LIST_MEETINGS` with a future `end_date`, filtered by overdue client names. Two disciplines that matter here specifically: - **Read the relevance scores.** Items below 3 are omitted entirely, and a single 3-scored item does not support a claim without corroboration [references/littlebird-mcp-reference.md, Retrieval patterns]. - **Sort by event time before presenting.** Results come back by relevance. For messages, the send time governs the timeline and the collection time goes in the receipt [references/evidence-standards.md, rule 8]. A client's "payment went out Friday" captured three weeks later will otherwise read as fresh news. ## Evidence standards Read `references/evidence-standards.md` before producing output. The rules that govern this skill most directly: - Every claim carries a receipt in the canonical format `[Tuesday, August 11, 2026 23:40 EDT | chrome]` (rule 1). - Every line is observed, inferred, external, or unknown, and which one is visible to the reader (rule 2). - **"No payment observed in 90 days" and "they did not pay" are different claims, and only the first is supportable** (rule 2). This is the load-bearing rule of the entire skill. - Confidence is rated, and a Low-rated claim never drives an irreversible action (rule 3). Sending a client a payment demand is irreversible. - Capture shows what the user was viewing, not what they sent (rule 4). - Confirm before encoding, confirm before sending (rule 6). - Raw capture never ships (rule 7). No draft quotes an OCR fragment or a private message. - Empty retrieval ends the run (rule 9). **Amount rule specific to this skill:** never assert an amount the capture did not show. An amount seen once is Medium. An amount seen on the same invoice across three separate captures is High. An amount that differs between two captures of the same invoice reference is a conflict, and it goes to the user rather than being averaged or picked. ## Empty retrieval branch If discovery returns nothing across families A through E, the run ends. Write the report with: - The date windows searched, month by month. - The exact queries and filters run. - The statement that no invoice-sent evidence was found in that window. - What would change the outcome: a wider window, a period when the user was actually doing billing, a check that Littlebird capture was running, or a payments connector. Do not reconstruct a plausible client list from what a business of this shape usually invoices. Do not estimate a receivables balance [references/evidence-standards.md, rule 9]. The same rule applies at phase 3 with a twist. If reconciliation returns no payment evidence at all, for any client, including ones the user knows paid, then the sweep is broken, not the book. Report the malfunction. Do not produce a receivables table where every line is overdue, because that is the exact output that damages relationships at scale. ## Guardrail **The false positive here is a chased client who already paid, and it is the most expensive error in this marketplace.** Every other guardrail in this skill exists to prevent it. | Rule | Enforcement | |---|---| | Absence of a payment observation is never evidence of non-payment | Four reconciliation states, none of which is `UNPAID` [references/payment-reconciliation.md, section 4] | | Two independent supports before "likely outstanding" | [references/payment-reconciliation.md, section 5] | | A verify-first tier for everything else | [references/aging-and-verification.md, section 2] | | A mandatory per-invoice verification gate before any draft | [references/aging-and-verification.md, section 3] | | Blind spots named in every run | Accounts and methods never seen on screen, checks and bank transfers called out by name | | The connector wins over capture | [references/payment-reconciliation.md, section 6] | **The second guardrail is harassment.** The ladder is finite. Seven rungs, then it stops and recommends a lawyer, an agency, or a write-off [references/follow-up-ladder.md, section 2]. House ceiling: one contact per invoice in any five consecutive days, two in any fourteen, nothing at all before a date the client committed to, and never again on a channel the client asked the user to stop using [references/follow-up-ladder.md, section 3]. There is no rung 8. **The third guardrail is client confidentiality.** Client financial data stays internal. No draft names another client, another client's balance, or another client's situation. No draft quotes captured material [references/evidence-standards.md, rule 7]. **The fourth guardrail is legal.** This skill does not give legal advice and says so in every run where debt-collection law, late fees, or interest come up. What the archive supports: the FDCPA defines "debt" as arising from transactions "primarily for personal, family, or household purposes", which places B2B invoices outside it, and it excludes a creditor's own officers and employees collecting in the creditor's name, which places a business collecting its own accounts outside it separately [references/research/distilled-receivables-collection.md, section 4]. The federal seven-calls-in-seven-days limit is written for debt collectors, not for the user [references/research/distilled-receivables-collection.md, section 4]. But at least one state, California, extends harassment rules to original creditors, the CFPB notes that state unfair and deceptive acts and practices laws may apply to debt collection, and no source in this archive surveys the other 49 states [references/research/distilled-receivables-collection.md, section 8, gap 3]. So: state the federal position accurately, do not imply the user is under a regime they are not under, and send any specific question to a lawyer. Never compute a late fee into a balance [references/aging-and-verification.md, section 5]. ## Draft-never-send The skill drafts. The user sends. There is no path through this skill that transmits anything to a client. Do not call an email tool. Do not open a compose surface and populate it. Do not offer sending as a convenience. This holds even when a connector is available and even when the user approved the plan, because approving a plan is not approving the words