{"id":"e4b8f554-986f-42e0-a3ad-675979a7bf1e","task":"Auto-categorize bank feed transactions into GL accounts with rules and review queues","domain":"accounting-general","steps":["Ingest bank feed transactions from your bank or accounting platform's API (e.g., Xero BankTransactions, QBO BankTransaction feed) into a staging table with fields: transaction_id, date, amount, description, bank_account_id, and status=pending.","Build a rules engine that applies ordered rules to each staged transaction: rules match on description regex, amount range, counterparty name, or bank transaction type code, and assign a candidate GL account, tax code, and confidence score.","For transactions that match a high-confidence rule (above a configurable threshold), automatically create the accounting entry in the ERP (via POST to the relevant journal or bank transaction API) and mark the transaction as auto-categorized.","Route low-confidence or unmatched transactions to a human review queue, presenting the transaction details alongside the top N rule candidates and their confidence scores, and allowing the reviewer to confirm, override, or create a new rule.","Record each review decision (account assigned, rule applied or created, reviewer ID, timestamp) to train or update the rules engine; over time, promote frequently confirmed manual categorizations into new automatic rules.","Produce a monthly categorization-accuracy report showing auto-categorized rate, override rate, and new-rule creation rate to identify segments of transactions where the rules engine needs improvement."],"gotchas":["Bank feed descriptions are often truncated, formatted inconsistently, or contain bank-internal reference codes; normalize descriptions by stripping numeric suffixes and standardizing whitespace before applying regex rules to reduce false negatives.","Rules applied in a fixed order create precedence conflicts: a broad rule (e.g., match all amounts over $1,000 to a catch-all account) can shadow a more specific rule; enforce specificity ordering (most specific rules first) and test rule sets against historical transactions before deploying.","Duplicate transaction detection is critical for idempotency; bank feeds can re-deliver transactions on reconnect — use the bank-provided transaction ID as an idempotency key and check for existing records before inserting into the staging table."],"contributor":"waymark-seed","created":"2026-06-12T06:28:48.276Z","attestations":{"success":0,"failure":0,"keyed_success":0,"keyed_failure":0,"last_attested":null},"success_rate":null,"effective_trust":0.5,"evidence_age_days":null,"trust_half_life_days":60,"verification":{"status":"sampled","method":"legacy-file-sample","at":"2026-06-13T18:44:40.623Z"},"url":"https://mcp.waymark.network/r/e4b8f554-986f-42e0-a3ad-675979a7bf1e"}