Bank reconciliation and transaction categorization

Requirements describe capabilities the pattern needs in your environment, not the vendors you must buy. Any system that fills a requirement satisfies it — that’s what makes the catalog portable across the long tail of SMB tooling.

1. bank_transaction_feed

   REQUIREDREADbatch

   The stream of transactions from banking and card sources.

   DATA SHAPE

   Per-transaction: date, amount, direction (debit/credit), description, counterparty if available, balance after.
   COMMONLY FILLED BY

   • bank feed integration to the accounting system
   • card processor feed
   • direct bank API connection
   • scheduled CSV import from online banking
2. open_item_register

   REQUIREDREADrequest

   Receivables, payables, and other open items the bank transactions might match against.

   DATA SHAPE

   Open invoices with amount, customer, expected payment date; open bills with amount, supplier, expected payment date; expected receipts from any other source.
   COMMONLY FILLED BY

   • accounts receivable and accounts payable modules of the accounting system
   • open items ledger
   • expected receipts log maintained by treasury
3. categorization_history

   REQUIREDREADcorpus

   The firm's historical bookkeeping decisions, which the pattern learns from. Without this, categorization is generic and often wrong.

   DATA SHAPE

   Historical transactions with their final categorization: GL account, project, class, any custom dimensions.
   COMMONLY FILLED BY

   • complete transaction history in the bookkeeping system
   • general ledger with descriptions and categorizations
   • imported historical books from prior accounting platform
4. chart_of_accounts

   REQUIREDREADrequest

   The valid set of accounts the pattern can categorize into, with definitions.

   DATA SHAPE

   Per-account: code, name, type, description, parent account, active or inactive.
   COMMONLY FILLED BY

   • chart of accounts in the bookkeeping system
   • structured account master maintained by the finance team
5. bookkeeping_write_destination

   REQUIREDWRITEevent

   Where matched and categorized transactions get recorded.

   DATA SHAPE

   Categorized transactions written as journal entries or applied against open items, with reference back to the source bank transaction.
   COMMONLY FILLED BY

   • bookkeeping system with API write access
   • queue of approved entries the bookkeeper posts
   • structured journal staged for bookkeeper review
6. ambiguity_review_queue

   REQUIREDREAD + WRITEbatch

   Where genuinely uncertain transactions go for human decision.

   DATA SHAPE

   Transaction with proposed categorization(s), confidence per option, evidence, decision capture.
   COMMONLY FILLED BY

   • review queue inside the accounting system
   • weekly review session with the bookkeeper
   • dedicated review UI built for the engagement
7. rule_definition_layer

   RECOMMENDEDREADcorpus

   Explicit rules the pattern must always follow that override learned patterns: 'transactions over $X always need approval', 'transactions to vendor Y always go to project Z'.

   DATA SHAPE

   Rules with conditions and required actions or constraints.
   IF MISSING

   Pattern relies entirely on learned patterns. Most firms have hard rules that should be encoded explicitly.
   COMMONLY FILLED BY

   • rules table maintained by the finance team
   • small admin UI for rule authoring
   • documented finance policies captured in build phase