1.8k Downloads
Overview
Local-first personal finance memory layer for OpenClaw that parses bank statements into structured JSON transactions and supports querying and manually adding spending data.
Key Advantages
1.Local storage in the OpenClaw workspace, keeping financial data on the user’s machine rather than remote services.
2.Supports ingestion of bank/credit card statements (PDF, image via vision) into a normalized JSON transaction format.
3.Queryable transaction history via jq and simple filters for categories, time ranges, and amounts.
4.Extensible data model with support for multiple accounts and metadata such as source files and timestamps.
5.Clear categorization scheme (food, transport, shopping, bills, entertainment, health, travel, other) enabling basic budgeting and spending analysis.
Use Cases
- Building a local spending tracker that aggregates transactions from uploaded card or bank statements.
- Answering personal finance questions such as total spending in a period, per-category spend, or largest expenses.
- Maintaining a lightweight transaction ledger for a specific account (e.g., Coinbase Card) without connecting to bank APIs.
- Rapid prototyping of finance agents that need persistent transaction memory across OpenClaw sessions.
- Manually logging cash or one-off transactions alongside parsed statement data for more complete tracking.
Evaluation Scores
7.6
/ 10
Reliability
7.0
Functionality
7.5
Usability
7.0
Safety
8.0
Performance
8.0
Compatibility
8.5
Based on 1 evaluation · Latest: 3/20/2026
Download Trend
Loading...
Evaluation History (1)
7.6/103/20/2026▼
OS: darwin-arm64LLM: arcee-ai/trinity-large-preview
**Quick judgment**
A solid, pragmatic local finance memory layer for OpenClaw power users. It handles statement parsing into JSON, persistent storage, and basic querying of personal spending, but expects some comfort with the command line, JSON, and dependencies like `jq` and `pypdf`.
**Strengths**
- Local-first: all data lives under `~/.openclaw/workspace/finance/`, which is good for privacy and aligns with OpenClaw’s storage conventions.
- Clear transaction schema and categories, enabling straightforward aggregation and analysis.
- Supports both parsed statements and manual transaction entry, giving flexibility when statements or integrations are missing.
**Key risks / limitations**
- **Parsing correctness:** Bank/credit card statements vary; `pypdf` text extraction plus custom parsing can misread dates, merchants, or amounts. The docs mention verifying totals, but this still relies heavily on the agent and implementer to be rigorous.
- **Tooling/dependency fragility:** Requires `jq`, `pypdf`, and a shell script (`scripts/add-transactions.sh`). Misconfigured environments or path issues can break the workflow.
- **Coverage and sophistication:** Limited to fairly simple categorization and sum/aggregate queries; not a full accounting system, tax tool, or multi-currency, multi-institution aggregator.
- **User error / oversight:** If the agent or user forgets to check that parsed totals match statement totals, silent errors can creep into the transaction history.
**Recommended scenarios**
- Developers and technically inclined users who want a **local-only, scriptable transaction store** to back personal finance agents.
- Prototyping or experimenting with **spending-analysis agents** ("How much did I spend on food last month?", "Top 10 expenses this quarter", etc.) using a simple JSON backend.
- Users with **statement-based accounts** (e.g., Coinbase Card) where Plaid or other API-based integrations are not available and statement upload is the main data source.
**Less suitable for**
- Non-technical users who are uncomfortable installing CLI tools, working with JSON, or debugging parsing issues.
- Use cases requiring **regulatory-grade accuracy**, full double-entry accounting, multi-currency handling, or automated multi-bank synchronization (these would require substantial extensions beyond this skill).
Comments (0)
No comments yet. Be the first!