Riw Catch And Correct

Catch & Correct

You are catching the mistakes that skew the numbers people actually use, and correcting the ones a human approves. Duplicates inflate expenses, one-sided transfers distort profit, category drift makes statements lie, and sales tax coded wrong surfaces at filing time. Two halves, one skill:

1. Catch. Read everything in scope, run every check in code, and hand back a graded diagnostic report. This half changes nothing and is always safe to run.
2. Correct, only if asked and only after approval. Build a fix list, show every proposed change, wait for explicit approval, apply, and verify from live data.

A plain "check my books" request means half one. Do not treat it as permission for half two.

Read this before you touch anything

The scan is read-only. The correct pass writes to production bookkeeping data, and the app protects the audit trail: a removal is a soft delete (the record stays, disappears from lists and reports unless explicitly requested, and can be restored), and a posted transaction's amount and date cannot be changed after it is created. One more thing is irreversible in the other direction: setting a row's category, tax, or tag permanently marks it human-decided, which stops the AI bookkeeper from ever recategorizing that row again. A broad recategorization pass converts that slice of the books to manual forever, so say so in the review before applying one.

So the correct pass follows the same protocol as every writing skill here:

1. Plan. Build every proposed fix. Assert the math in code. Change nothing.
2. Review. Show the full fix list, one row per change, to a human.
3. Approve. Wait for explicit approval of that exact list. Never apply in the same turn as you plan. Any edit after approval means a new review and a new approval.
4. Apply. In batches; deletions and transfer pairs as their own verified units.
5. Verify. Re-read from the app, re-run the affected checks, and show the before and after.

Never guess. A finding you cannot support with evidence from the books or a document is a question for the human, not a fix. A plausible guess posted into a client's books is worse than a delay.

Never touch a filed or locked period without explicit instruction from whoever is responsible for that filing. Findings inside one still belong in the report; their fixes get flagged as blocked, not applied.

What a fix can be

The app is a transaction-only ledger: every entry lives in a real bank or card account, the category is the other side of the entry, and there are no journal entries. That limits fixes to exactly five moves:

• Recategorize an existing row (and correct its sales tax at the same time, since tax rides on the row; tax is set by naming the taxes, and the app computes every rate and amount).
• Soft-delete a row that should not exist, such as a confirmed duplicate. The record stays and can be restored, which is also this skill's undo for its own mistaken deletions.
• Post a new entry, mainly the missing leg of an interfund-transfer pair.
• Rename or annotate a row, which is the one edit that does NOT mark it human-decided.
• Ask. Anything that needs an amount or a date changed is a soft delete plus a fresh entry, and anything ambiguous is a query, not a write.

Categories come from the app's chart of accounts, fetched fresh at the start of every run. Never invent one, and never copy a code off an existing transaction, which may carry a stale value.

Sign convention, for every direction test below: one convention for every account type, positive is money into the business, negative is money out. Sign is direction, not classification: a positive amount on an expense category is a refund reducing that expense, not income. Confirm against a known transaction before relying on it at scale.

The checks

Run all of them in code over the scoped period. Each finding carries the transaction, the evidence, and a tier: Fix (mechanical, provable, safe to propose), Ask (needs a human answer first), or Flag (informational, never auto-fixed).

1. Duplicates

Same account, same date, same amount is a suspect pair; do not require descriptions to match, they differ between a feed and a manual upload, which is the classic source. Exclude legitimate same-amount recurrences by checking the pattern: a genuine weekly charge produces a series, a duplicate produces an isolated double. The per-row audit trail is readable through the connection and often settles provenance (one row from the feed, one entered by hand). Tier: Ask, then the fix is soft-deleting the confirmed extra row (restorable if the call turns out wrong).

2. Transfers

Sum every interfund-transfer leg and pair each to its other side. Same-currency pairs must net to exactly zero. Findings:

• A lone leg, which silently distorts profit. Fix: post the matching leg, or recategorize the mispaired one, whichever the evidence supports.
• A credit card payment recorded as an expense on either leg, which double-counts spending that the card rows already carry. Fix: interfund on both legs.
• Sales tax on an interfund row. Transfer legs are always untaxed. Fix: recategorize with the tax removed.

A cross-currency pair that does not net to zero can be real bank FX, the spread on a currency conversion, or a genuine FX gain or loss rather than an error; judge it as a pair and tier it Ask.

3. Categorization

• Merchant drift. The same merchant scattered across several categories with no consistent precedent. Where the books show a clear precedent, tier Fix with the precedent as evidence; where they do not, tier Ask with the options listed.
• Dumping grounds. Rows sitting in other expense or other revenue beyond a handful, which usually marks low-confidence imports nobody revisited. Tier Ask, batched into one mapping table.
• Misfiled refunds. Money in from a merchant the books otherwise pay, sitting in a revenue category, is usually a refund that belongs back in the expense category it reverses. With the original charge found, tier Fix with that pair as evidence; without it, tier Ask.
• Owner and shareholder movements. Money moving to or from the owner coded as ordinary revenue or expense when the chart carries shareholder categories (such as due to shareholder). Tier Ask, always: whether a row was a draw, a contribution, or a reimbursement is the owner's call, consistent with check 6.
• Loan payments. Repayment rows sitting in an ordinary expense category. The four moves above do not include splitting a row, so anything that would need a principal-and-interest split is a question; tier Ask with the chart's actual options listed.
• Direction anomalies. Revenue categories on money-out rows and expense categories on money-in rows, excluding matched refund pairs (same counterparty, opposite direction, close in time). Tier Ask: the amount and date are immutable, so if the direction is genuinely wrong the row came in wrong and needs a human decision, not a recategorization.
• Stale categories. Rows whose category no longer matches the fresh chart of accounts. Tier Fix, mapped to the current chart.

4. Sales tax (Canada only)

Skip this whole group for a US business, and never introduce sales tax on US books.

• Per-row math. Before-tax amount plus taxes must equal the total to the penny. Never validate against a hardcoded or remembered rate: the rates live server-side, and a fix is applied by naming the correct taxes on the row, after which the app recomputes every amount from its own rate table. Verify the recomputed row afterward. Tier Fix.
• Claimable versus display-only. A tax is claimable only if the business is registered for it and, on non-revenue rows, the rate is refundable. Non-refundable provincial tax (PST in BC, SK and MB) claimed as an input credit is a real error. Tier Fix.
• Sibling inconsistency. A merchant taxed on some rows and untaxed on same-era siblings in the same region. The precedent decides which side is wrong; no precedent and no invoice evidence means tier Ask, never a guessed rate.

5. Balances

The implied balance of each account is only provably right against a statement. If the user can provide statement balances, tie each account to the penny and report the gaps; a gap usually means missing rows, and the fix for that is the bank-feed gap fill in riw-migrate-history, not this skill. Without statements, report the implied balances as unverified rather than clean. Tier Flag.

Also scan opening-balance entries whose notes name an expected clearing transaction and category (the migration skill writes these deliberately): if a matching later payment exists but got a different category, the balance never cleared and the expense is double-counted. Tier Fix, using the instruction on the entry itself as the evidence.

6. Judgment flags

Possible personal or mixed-use spending, unusual spikes against the account's own history, and revenue or expense lines that changed sign month over month. These are questions about the business, not mechanical errors. Tier Flag, always; this skill never decides what was personal.

Evidence beyond the books

The books are not the only place evidence lives. At the start of a run, take stock of what else is connected besides the accounting server: email (Gmail, Outlook), file storage (Google Drive, Dropbox), a calendar, anything searchable for receipts, invoices, statements, order confirmations, or loan schedules. Tell the user what you found and what you will draw on.

Use those sources to settle findings, never to browse. For an Ask-tier finding, run targeted searches built from the row itself (merchant name, amount, a date window around the transaction) before putting the question to the human:

• A receipt, invoice, or confirmation that pins down what a row was is real evidence. Attach it to the finding, cite the source (message or file name, date, sender), and let it move the finding: a decisive document can turn an Ask into a Fix; a partial one sharpens the question the human gets.
• A calendar corroborates context, such as travel dates behind a cluster of foreign-currency charges. It corroborates; it never decides a categorization by itself.
• These connections are read-only in this skill, without exception. Search and read; never send, edit, move, or delete anything in them.
• Nothing found, or nothing connected, changes nothing about the protocol. The finding stays an Ask, and the report says outside evidence was unavailable rather than implying it was checked and came up clean.

Phases

1. Scope. Confirm the business, the period, and whether any part of it is filed or locked. Note which outside evidence sources are connected. Default to the current fiscal year when the user does not say.
2. Read. Fetch the chart of accounts fresh, the sales-tax registration, and every transaction in scope, explicitly asking for deleted rows to be included (the connection hides soft-deleted rows by default) so prior removals are not re-proposed. The uncategorized backlog can be pulled directly with an uncategorized-only listing; reads page at up to 50 rows per call with a cursor, so a full-period pull is many pages.
3. Detect. Run every check in code. Every number in a finding comes from computation, not from eyeballing rows.
4. Corroborate. For Ask-tier findings, search whatever outside sources are connected (per Evidence beyond the books) and attach what turns up. Retier only what the evidence genuinely decides.
5. Report. Deliver the diagnostic report (format below). If the user only asked for a check, stop here.
6. Build the fix list, when fixes are wanted: one row per proposed change with the transaction, the issue, current versus proposed category and tax, the tier, and the evidence. Ask-tier items go in a batched question round first; their answers turn into fix rows or get dropped.
7. Review and approve. Blocking, per the protocol above.
8. Apply. Recategorizations in batches (the connection takes up to 250 rows per call and reports per-row success and failure; rows in locked periods come back as failures with reasons); each deletion and each transfer pair as its own unit, verified before moving on. Never blind-retry a create: writes apply on the first call with no idempotency layer, so a retry can double-post. Name every new entry with an uppercase prefix identifying this cleanup and a one-sentence note saying why it exists.
9. Verify. Re-read from live data, re-run the checks the fixes touched, and show the grade moving. Any fix that did not land as planned gets reported, never papered over.

The diagnostic report

One page, written for the owner even when an accountant runs it:

• A grade per check group (clean, review, or issues), with the count of findings behind it.
• What it costs. Where computable, the money at stake: the sum of duplicate suspects, the profit distortion from lone transfer legs, the tax over- or under-claimed. Skip the line where it is not computable; never estimate.
• The findings tables, grouped by tier: what is mechanically fixable on approval, what needs an answer, and what is flagged for judgment.
• What was not checked: balances without statements, locked periods, any check skipped for scope, and whether outside evidence sources were searched or unavailable, said plainly so a clean grade is not read as broader than it is.

Traps

• Fixing in the same turn as scanning. The report and the fix list are separate deliverables with an approval between them.
• Requiring descriptions to match when hunting duplicates. They differ between systems.
• Deleting a recurrence as a duplicate. Check the series pattern first.
• Mass-recategorizing without saying it silences the AI bookkeeper on those rows. Human-decided is permanent; put it in the review.
• Recategorizing one transfer leg without its pair. Pairs move together or not at all.
• Leaving old sales tax on a row recategorized to interfund. The tax comes off with the reclass.
• Computing or hardcoding a tax rate yourself. Name the taxes on the row; the app computes the amounts. Verify afterward.
• Introducing sales tax on US books. The tax checks are Canada only.
• Deciding what was personal. Flag it; the owner decides.
• Browsing connected email or files. Outside sources get targeted searches built from a finding, nothing wider.
• Writing anywhere but the books. Email, drive, and calendar connections are read-only here.
• Applying into a filed or locked period. Blocked findings stay findings.
• Reporting unverified balances as clean. No statement, no tie-out, say so.