Hishob: A Local AI Home Finance Dashboard with a Privacy-First Approach to Bookkeeping

When Bookkeeping Meets Local LLMs

Most bookkeeping apps focus on a single transaction account, but household finances are far more than that—the connections between mortgages, offset accounts, various bills, and paper documents are the hidden clues that truly affect cash flow. Developer Koustubh shared his open-source project Hishob (Marathi for "accounts") on Dev.to, a finance dashboard running on the home LAN that uses a local AI model to automatically discover "where the money went" and offer actionable advice.

According to the author, Hishob is part of the "gharasathi" (home AI) series. Early versions ran on a mini PC with 6GB of RAM using a small 3B model; as requirements grew, the hardware was upgraded to a Mac Studio (M3 Ultra, 96GB unified memory) running the Qwen3.5-122B-A10B model locally. All inference happens at home, and bank statements and bill PDFs never leave the house.

Architecture Breakdown: Five Microservices Named in Marathi

The entire system uses a mixed stack of Go, Python, and React, deployed on a k3d (lightweight Kubernetes distribution) cluster, with Neo4j graph database and Postgres as core data stores. Each service has a Marathi name and a clear division of responsibilities:

• aapla-dhan ("our wealth", Go): Syncs bank accounts to Neo4j via the Australian Consumer Data Right (CDR, open banking), triggered manually once a week.
• aapla-patrakar ("our reporter", Go): Reads bills and statements from a Gmail label folder and a Nextcloud drop directory.
• aapla-olakh ("our recognition", Go): A handwritten PDF parser that extracts fields and validates the document's own arithmetic.
• aapla-hushar ("our smart one", Python/FastAPI/LangGraph): Rule detectors, the nightly AI analyst, and the chat assistant anna.
• aapla-hishob ("our accounts", React): The frontend dashboard.

Only two things need to go out to the internet, and both are read-only: the bank CDR interface and Gmail IMAP. Everything else is inferred locally on the Mac Studio.

Consumer Data Right (CDR) is an open banking regime introduced by the Australian government, rolled out in phases starting in 2020. It gives consumers the right to securely obtain their own bank account data in machine-readable format and to share that data with accredited third-party providers. Unlike traditional screen scraping, CDR provides read access through standardized APIs, with data including account balances, transaction details, direct debits, and recurring payments. Providers must pass strict accreditation (such as ACCC approval) and comply with privacy and security standards. Hishob's use of CDR to sync bank data means it receives first-hand structured transactions rather than second-hand results from parsing web pages or PDFs, which explains why its "count spending only once" rule can be reliably enforced.

k3d is a tool for running k3s (a lightweight Kubernetes distribution) in Docker containers, used to quickly create multi-node Kubernetes clusters on a single machine. Compared with full Kubernetes, k3d starts faster and uses fewer resources, making it ideal for home labs or local development. Hishob deploys its five microservices on k3d, gaining Kubernetes' declarative deployment, service discovery, and rolling update capabilities without having to maintain a full production-grade cluster. For a personal project running on a Mac Studio, this is a pragmatic compromise between engineering discipline and resource overhead.

Whole-Account View: Not Just Bookkeeping, but a Balance Sheet

Hishob's differentiation lies in putting the everyday account, offset account, and mortgage into a single graph. The author lists several key design decisions:

• Count spending only once: Transfers between accounts and transfers into the offset account are not spending; mortgage principal counts as savings (increasing equity), while interest counts as a real cost.
• Link interest to cash: Offset account balances are shown side by side with interest actually received; the author observed that in the month with the highest offset balance, average daily interest dropped by about one-fifth. The system also flags "idle cash sitting in the everyday account that could have been offsetting interest."
• Model the mortgage: Balance, offset, repayments, and estimated interest rate all come from data, turning "what would happen if I put another AUD 10,000 into the offset account" into a calculation rather than a guess.
• Match refunds and reversals: Refunds are automatically matched to the original payment and are not mistaken for extra income and spending.
• No fake "complete months": Each bank data source syncs independently, and the dashboard only treats data as complete up to the last transaction of the oldest account, preventing a lagging data source from making the current month look "cheap."

Semi-Automatic Data Entry: Deliberately Preserving Human Control

The author states clearly that Hishob is not fully automatic, and this is intentional. Bank transactions are synced manually once a week; bills are forwarded to a dedicated mailbox, where Gmail filters tag them by type (such as gharasathi/utilities, gharasathi/childcare), and nightly jobs read only those labels; other files are dropped into a Nextcloud folder. Day-to-day operation involves just two steps: forward a bill when it arrives, and press sync once a week.

All data lands in the Neo4j knowledge graph, where a charge, the bill it pays, and the line items on that bill are connected to one another. The author emphasizes that this is not arbitrary node-stacking but a small ontology: fixed node types and a relationship vocabulary that only permits the listed relationships—no generic LINKED_TO, for example. This brings three benefits: local models generate Cypher queries more reliably; every Fact points to its source PDF, making evidence part of the structure; and the ontology is not limited to money—the pattern of communication → file → PDF → fact → entity applies equally to insurance renewals or medical letters.

Ontology in computer science is an explicit formal description of the concepts, properties, and relationships among concepts in a domain. In the context of knowledge graphs, it typically defines the allowed node types (such as account, bill, payment) and relationship types (such as PAID_BY, BILLED_TO), and constrains which combinations are legal. Hishob adopts a "small ontology," deliberately keeping the vocabulary of types and relationships lean and fixed and disallowing uninformative edges like a generic LINKED_TO. This approach draws on experience from the semantic web and knowledge engineering: the more explicit the constraints, the less ambiguity in reasoning and querying over the graph. For small local models, the fewer relationship terms available when generating Cypher queries, the lower the probability of hallucinating nonexistent relationships; at the same time, every Fact can be traced back to its source PDF along ontology-defined relationships, making the evidence chain part of the data structure rather than something bolted on afterward.

Highlight Feature: "What anna Noticed"

At the bottom of the dashboard, a prioritized list of findings is generated each morning, partly from deterministic rules (price increases, unpaid bills, subsidy gaps) and partly from the nightly AI analyst. Each finding comes with evidence and two buttons: Explain (anna reads the finding, pulls the underlying data, and explains in plain language what happened and what to do) and Resolve (mark it as "not a problem," and the nightly editor learns to rank similar findings lower).

The author shares three real cases:

1. "Did we pay a bill twice?" The same electricity bill was charged twice within a week, which from the bank statement alone looks like a duplicate charge. After Hishob read the original bill and matched it against bank records, it found that the first charge had been returned by the bank and only the second was a real payment—one bill, paid once.
2. Quietly lost childcare subsidy: Australia's Child Care Subsidy covers up to 42 absence days per child per year, and the statement showed the limit had been exceeded. Explain clarified that the limit was exceeded back in February and that every absence day since was charged at full price. A follow-up question—"How many absence days have we used this year, and how much would one more day cost?"—was also answered, and a rule now warns before the cap is hit.
3. Context changes the advice: One recommendation suggested negotiating the mortgage rate, and the author added information the data did not know—the loan is fixed-rate, and the loan-to-value ratio means a new lender would charge Lenders Mortgage Insurance (LMI). The answer changed accordingly: refinancing would mean paying LMI again, repricing a fixed rate carries a break fee, and the real lever is keeping more cash in the offset account.

Core Principle: Code Calculates, the Model Explains

This is the most important design constraint of the entire series. The author learned it back in season one with a 3B model, and it still holds at 122B: the model never does money arithmetic. All totals, averages, and matches are computed by code, and the model receives exact numbers and does what it is good at—finding connections, explaining causes, and suggesting actions. A fact-checker then rejects any finding containing an amount or percentage that cannot be traced back to a data source.

The nightly pipeline roughly works like this: at 01:30 new bills are read and archived; every hour, about twenty deterministic detectors run when data changes; at 02:30 the AI analyst reads a code-built "fact pack" and writes findings, which then go through fact-checking and editing; in the morning the dashboard and anna present the results.

Fact-checker here is an independent verification layer between model output and the user interface. Its job is: for every amount or percentage that appears in a finding written by the model, the checker tries to trace that value to a specific field computed by code in the "fact pack" or to an entry in the source PDF; values that cannot be traced are rejected, and the entire finding may be discarded or sent back for rewriting. This is similar to the idea of "citation validation" in retrieval-augmented generation (RAG), but stricter—it requires not only a source but also that the value itself be produced by deterministic code rather than inferred by the model. Because large language models are unreliable at arithmetic, this division of labor—"the model only does language, the code only does numbers"—lets the system retain natural-language explanatory power while avoiding the most dangerous type of error in AI financial advice: numbers that look plausible but are calculated wrong.

What This Approach Means

Hishob's value is not in how large a model it uses, but in demonstrating a replicable path: data stays at home, a capable enough model runs alongside it, and the ontology leaves room to grow. The author notes at the end that money is only the starting point—any area of household life that leaves records can follow the same pattern: code does the counting, the model does the explaining. For households that care about privacy yet want AI analytical capabilities, this is an open-source practice worth studying.

Future installments will cover how to run Qwen3.5-122B on a Mac Studio and keep it honest (part two), and findings from reading bills and statements without AI (part three).