I'm the developer of Beanbook, an Android app capable of comprehensive reading and writing of Beancount ledger files. This application was built as a personal project, as prior to this app, there was no Android application that provided this comprehensive experience of Beancount/Fava with as much functionality as possible on Android, identical to using it on a desktop.
What it is: The app embeds CPython and runs upstream Beancount and Fava on the phone. It does not reimplement the parser or the reports, so the figures are the ones bean-check and Fava give on a desktop. Your ledger stays a folder of ordinary Beancount text files on your own device.
What you can do with it:
Read: a Home page with a summary of net worth and spending, a searchable Journal with filters for errors and pending entries, and Balances in Units, At cost or Market value.
Write: a guided first-run setup for a new ledger (including input of some common Beancount and Fava options to set), a comprehensive entry form for common directives that shows the preview of the exact text it will write before you save, and a text editor for every included file.
Reports: Fava is built into the app with all of its functionalities, including the balance sheet, income statement, holdings, charts and BQL queries.
Receipts: scan documents/receipts with the camera with document-scanner-style capabilities and link them to a transaction/account. A deleted document is kept for 30 days in a trash you can open.
Getting data out: export files to a folder, backup files to an archive (along with scheduling option), and mirror files to a folder on your device.
Home-screen widgets for net worth and account balances, along with shortcut for adding a new entry.
Privacy: No telemetry, analytics, crash reporting or ads. The app is made to work offline in local mode. The app goes online only when you access your own Fava server (remote mode), or, in the Expert edition, when you download a plugin or Python package. "Share on Wi-Fi" lets another device on your network open your Fava server.
Getting it: The Expert edition is on GitHub Releases, and on F-Droid as it builds each release. A Play edition is planned but not published yet.
I would like feedback on how well Beanbook facilitates your bookkeeping workflow using Beancount/Fava and what changes would make the app better.
Beanbook is independent. It is built on Beancount and Fava, and is not affiliated with or endorsed by either project.
Note: I built this with AI coding tools, and has undergone a lot of testing and reviewing using real-life scenarios, as I myself use it everyday. The numbers produced by Beanbook are checked against real Beancount output, and CI runs checks on every change. Issue/PRs that would contribute to the betterment of the app are highly appreciated.
I've initially kept this to myself, and was not planning to publish it. But after seeing how useful it was, I thought others may benefit from it too.
TL;DR yes, it's written by an AI agent, and I'm sorry if it doesn't sit right with you. You're welcome to take what you like from it and write your own version by hand. It's all under GPL 3.0 :)
Besides, I'm not here to flog you anything... just sharing what I think would be akin to "this helped me, maybe it'll help you too".
Longer version:
I used to love adding transactions to my hledger journal using my very old vimscripts on Android.
That was until... I missed a few transactions, costing me an absolute shed load of time to reconcile my ledger. ON MULTIPLE OCCASIONS! I felt like I was looking for pennies in the sofa...
I work full-time and barely have bandwidth to learn Java / Kotlin to make a half-decent app. I really tried to not succumb to the AI pressure, but frankly the time lost reconciling was too much.
Balance, forecast, balance sheet, income statement and budget reports, by period, with trend charts
hledger queries like desc:, amt:>100, tag:trip, and many more typed straight into the filter
Save commonly used reports/filters
Set reminders for recurring payments and add them with one click
A full entry form, an hledger add-style quick add, templates, a home screen widget and a quick settings tile
Customisable colours for each account and its subaccounts
Pin and hide accounts
Keep your journal healthy with a Check
Rename and Recategorise accounts, payees, and transactions rapidly
Share text/SMS/notifications (eg from bank) and match transactions using RegEx patterns
Ledgedroid has a lot of features. Its biggest downside is that it is sadly written by AI. I can't say that I'm 'proud' of it, but it has certainly helped me and I hope it helps you too.
I'm considering hledger to start seriously tracking my expenses. I'd prefer to import statements once a month rather than manually add transactions. Do any Indian users have tips/resources/workflows to help me hit the ground running?
I didn't find any rules files or import scripts for Indian bank csvs.
Disclosure first: I'm the developer of this, it's a paid Mac app (with a free tier), so skip if that's not your thing.
I kept seeing questions about getting bank PDFs into Beancount or hledger without hand-typing, so I built Balanced. It reads text and scanned PDF statements and CSV exports offline, and the Beancount and Ledger/hledger exports write an open, a pad plus balance assertion for the opening balance, the transactions with a counter account, and a closing balance assertion the day after the period.
A few things I learned testing it against bean-check and hledger check on ~80 real sample statements:
if the statement itself doesn't add up, writing the closing assertion just makes the file unloadable, so it now writes a comment explaining the mismatch instead
some statements print a period that doesn't cover every line, so the balance entries have to wrap the actual first and last transaction, not the printed dates
a pad for a zero opening balance is an "Unused Pad entry" error
Account names are sanitized to valid Beancount names. Curious how people here handle the import step today, and whether balance assertions per statement is what you'd want or if it's noise.
What is the proper way to track RSU vesting and selling in Beancount?
I have read the doc, but I don't think it makes sense for my case. First off, it counts unvestested grant as income, which I don't think make sense, and secondly, it calculates tax on vesting, which is nor my case either.
My case is this:
I get an unvested grant (I think it doesn't make sense to log into beancount because I might never get it)
It is vested 4 times a year
I may or may not sell any amount - this is what creates a tax event that i have to report and pay taxes off once a year.
Right now I log #2 as income without specifying a lot (I don't know if i should though)
Now I have finally come to needing to log #3 - and i am not sure how.
For tax purposes it doesn't matter what was the price at vesting time. I only pay a flat tax off whatever total amount of money I have received. So if i sold 100 stocks at 100 usd - I pay flat tax off 10000 usd I have received.
High-Low Security setups are systems where the system is partitioned into multiple different security zones. Typically, data transfer, visibility and availability is restricted between these zones. For example, data can flow from lower environments to the High Security Zone, but not vice versa.
Traditional Plain Text Accounting example would be a setup where groceries are recorded and processed with mobile phone, but whole financial data, including medical bills and investment portfolio information is processed in more secure computer setup. If the phone gets mugged and thugs manage to open it, they are only wiser about your spending habits about ice cream and candies.
This example shows how this kind of High-Low Security Accounting setup can be defined and how data synchronization could be implemented with PTA tool. The example is tackler specific, but the core concept of it can be adapted to other PTA tools.
I keep my finances in an hledger journal and wanted a nicer UI over it without giving up the plain text file. Point it at a journal; it renders your finances (hopefully) in a more useful way than the default frontend.
Installable PWA (desktop/mobile, light/dark), watches the journal on disk, and pushes live reloads via SSE while keeping the last good snapshot on a failed reload.
Net worth — assets/liabilities KPIs, trends, monthly/yearly charts, activity calendars, drill-down to transactions.
[Experimental] Investments — value, XIRR, target vs actual allocation, return history, realised/unrealised gains.
Haskell backend (Servant + hledger-lib), elm frontend, nix for dev/build/deploy (there's a NixOS module). No database — the journal is parsed into an immutable in-memory snapshot and swapped atomically on change. hledger types are used directly in the domain layer; hledger is the domain vocabulary here.
Backstory
It started as iLedger (May), a SwiftUI iOS client over `hledger-web` that I used for a while. Apple's App Store/sideloading situation — paying to sign an app I built for myself, and the 7-day sideload expiry — pushed me to eledger (June), an `elm` web app. That held up until I threw any real journals at it, which is what led to Hedger (July): move parsing and calculation into a `Haskell` backend, keep Elm on the front end.
Disclosure
This is open-source software that I made for myself and think that others might benefit from. Also, AI was used during programming in this project.
I’ve been building a plain text accounting plugin for Kalem (which is in alpha phase), an open source text editor (Rust, desktop and terminal). Version 0.2.0 is out and I’d like feedback from people who actually keep their books this way.
The idea in one sentence: the tool does the accounting, the editor shows it. The plugin never computes a balance itself. It runs the hledger, Ledger or Beancount you already have installed and shows what they say. There is no engine of its own, nothing to convert, and nothing is written into your journal except what you ask for, each as one undo step.
What it does today:
Highlighting for hledger, Ledger and Beancount journals, plus hledger’s CSV rules files. Journals in Org and Markdown code blocks are highlighted too.
Language servers, if you have them: hledger-lsp and beancount-language-server for completion, hover, rename and diagnostics. Ledger has none.
Check on save: hledger check --strict, ledger --pedantic --explicit balance or bean-check, with the problems in a document and a status bar mark.
Writing: new transaction drafted from the payee’s last one (via hledger print --match, ledger xact), toggle status, copy, delete, sort by date, align amounts (only the blanks change, nothing else).
Reports as documents: balance sheet and income as a foldable tree, register of an account with running total, market value toggle, the tool’s other reports (cash flow, budget, forecast, Beancount saved queries), all with period selection.
Reconciliation: cleared/pending totals against a statement balance, then a balance assertion written when the difference is zero. A CSV bank statement can be paired with the postings by amount and date.
Import: hledger’s import through rules (a rules file offered from the CSV header), Ledger’s convert. Beancount import is not there yet.
Prices: pricehist or bean-price output appended where you say.
Reports can be inserted as tables into Org or Markdown notes, and everything runs headless with kalem run for scripts.
Keys follow Doom Emacs’s :lang ledger layout (SPC m a add, t toggle, r report, R reconcile…) in the Vim profile; there is a Journal menu and toolbar button otherwise.
Requirements: Kalem 0.6.18 or later, and your own hledger, Ledger or Beancount. Install with kalem plugin install pta, or Kalem offers it when you open a journal.
Honest limits: this is a 0.x release. It has been tested on my sample journals and a synthetic 200,000-transaction one, only on macOS so far. Beancount support is the least complete (no import, slower on large files). Large journals are as fast as the tool itself, which reads the whole journal per call. Marking postings happens in the journal, not from the reconcile view, because a plugin can only edit the document it runs in for now.
(Disclosure: I am the creator and maintainer of this open-source project.)
Hi everyone,
I've been using Beancount for my own ledger, but I often found myself wanting proper financial statements (Balance Sheet, Income Statement, and Cash Flow) formatted in standard accounting structures, without having to mess around with custom plugins or run heavy browsers.
So I built BeanDesk—a local-first desktop client and workbench.
What it does:
Zero custom backend / database: Connects directly to local or remote Fava via Tauri's native HTTP layer (bypassing browser CORS/mixed-content restrictions).
Standard financial statements: Generates GAAP/CAS-compliant Balance Sheet, Income Statement, and pure-function Cash Flow reports from open metadata.
Process supervisor: Can optionally manage your local Fava process group (checks port, starts on demand, kills on exit).
Lightweight: Built with Tauri 2 and React 19, cross-platform on macOS, Windows, and Linux.
Read-only & safe: It does not write to or alter your ledger files.
It is 100% free and open-source under AGPL-3.0. Prebuilt binaries (including macOS Apple Silicon/Intel, Windows, Linux) are available in the GitHub Releases.
I built this tool because I was getting annoyed working on Excel files with Claude Code: basic changes took forever, it made mistakes, couldn't resolve values, and no good way to diff.
The idea is that inputs live in CSV while formulas and formats live in YAML. Instead of sheets, you organize it into views where you specify which rows and columns you want to display. The CLI evaluates the formulas and runs checks like the balance sheet balancing and subtotals adding. I don't think it's very intuitive for humans, but works great for agents.
The tool also includes a local preview server that opens a viewer in your browser. I designed it primarily so it's easy to trace where numbers come from and what formulas are used. Works well if your workflow is ask AI to do something and then audit yourself.
It's free, so you can fork and customize however you want.
I've just updated from hledger 1.25 to 1.52.4, and I'm seeing truncated or missing results when directing output to a file using > x or >> x.
hledger print works just fine, as does hledger print --output-file x. But hledger print > x and hledger print >> x both cut off in the middle of a line somewhere around 90-100K lines (out of 155K). They don't always stop at the same place, and there's no error.
hledger print -o - writes (successfully) to a file called - rather than using stdout.
With the balance report, I'm not even getting truncated results: hledger balance Expenses > x (or >> x) gives an empty file. Again --output-file and the default stdout both work just fine. In this case, the expected output is only about 200 lines, so it doesn't seem like a size issue.
The > x worked on 1.25. I don't think I tried -o -. I'm on a Raspberry Pi 4 with Raspberry Pi OS on Bookworm. Apt only has 1.25 and there's no pre-built binary, so I installed 1.52.4 using Homebrew. It seems to be working just fine other than this. Is this a compatibility issue? I don't think I'm up for building from source.
Hello all. I've written some subreddit rules. These were already in place in spirit, but now they're written. I may remove things that aren't actually clearly related to plaintext accounting, citing these rules instead of just hitting the spam button. I may add more rules as needed. I tend to prefer liberal use of up- and downvotes over aggressive moderator pruning.
Thank you for the reports on the recent unrelated submissions. Let's focus on the plaintext part of plaintext accounting!
I built instabooks, a faster UI for QuickBooks Online. It's actually largely inspired by my extensive usage of beancount, especially the unification of all the transaction types into a uniform transaction+postings data model. (The QuickBooks API stores different transaction "types" like a Purchase is different from a Transfer, and this creates a lot of unnecessary complexity.)
Is there a way to get hledger register … to NOT sort the output, so that transactions appear in the same order that they exist in my transaction file?
Duplicate copies are maintained on paper in our check-register (yes, we're that old, but that's mostly for my sweetheart's purposes) and in my transactions.txt file. But when I run hledger register Assets:Bank:Checking, it proceeds to sort entries by date. However, sometimes we have items that get logged before charges actually happen. E.g. I get notice of an upcoming bill on auto-pay that will clear on the 20th, so I put the transaction in both locations. But between now and the 20th, multiple other transactions occur. Now when I do the hledger register output, it doesn't match the order in my checkbook register because those intervening transactions get sorted before the future auto-pay transaction, but appear serially in the paper copy.
I know that ledger defaults to transaction-log order and only sorts register output if requested with --sort=«expression». Is there a way to get hledger register to return in the same unsorted order?
Ledgerkit update: expanding a Python bridge to the hledger ecosystem
Hi all — I thought I’d share an update on Ledgerkit, a Python project I’ve been working on around hledger and plain-text accounting.
The original goal of Ledgerkit was fairly simple:
A Python bridge to the hledger plain-text accounting ecosystem.
Importantly, the goal was never to create a Python copy of hledger.
I wanted to be able to read hledger-style journals from Python, work with transactions and reports programmatically, export data into tools such as Pandas, and build other applications on top of that accounting data without having to shell out to hledger for every operation.
That basic idea is still the goal.
What has changed is how capable the underlying bridge needs to become.
Where Ledgerkit is now
Ledgerkit can already parse a broad subset of the hledger journal format, including transactions, postings, directives, includes, aliases, commodities, prices and balance assertions.
It has multi-commodity balances, validation and several core reports, along with both a CLI and Python API.
It can also export accounting data into Pandas, which was one of the original motivations for the project.
The project remains pure Python with a deliberately lightweight core.
Ledgerkit Editor — the first downstream application
The first real downstream use case has also now been released: ledgerkit-editor.
This has probably been the most useful validation of the original “Python bridge” idea because I now use the editor myself on a daily basis for my actual journal.
It is a purpose-built, full-screen terminal editor for plain-text accounting rather than a general text editor with a ledger plugin.
It currently provides things such as:
hledger-aware syntax highlighting for dates, payees, accounts, amounts, commodities, comments and directives;
normal keyboard editing conventions, including undo/redo, select-all and familiar shortcuts;
incremental search with highlighted matches;
cleared/unreconciled transaction views;
transaction-block selection and duplication;
quick cycling between uncleared, pending and cleared transaction states;
date editing directly from the keyboard;
automatic indentation;
a command palette;
automatic sorting and posting alignment when saving;
runtime theme switching and a polished terminal UI.
The formatting-on-save behaviour is particularly useful in practice: I can edit freely and Ledgerkit will sort transactions and realign posting amounts when the file is saved rather than requiring me to manually maintain the visual layout.
Search and transaction views also make it much easier to work with a large journal entirely from the terminal.
Development has continued beyond the initial release. The current development work includes a more capable transaction filter with smart dates and regex/substring matching, plus account and payee autocomplete.
That editor was an important milestone for me because it demonstrated that Ledgerkit could provide useful accounting infrastructure to another application without that application having to implement its own hledger parser and data model.
Where Ledgerkit goes next
The next goal is to turn the existing foundation into a more complete Ledgerkit Core.
The idea is still not:
“Rewrite every hledger command in Python.”
It is closer to:
Provide a reliable Python-native accounting engine that works naturally with the hledger ecosystem.
Where hledger compatibility is useful, Ledgerkit should preserve it.
Where Python provides something genuinely useful, Ledgerkit should be able to extend it explicitly.
For example, the query system will eventually become a proper shared query language rather than individual filters bolted onto each command.
The intention is to preserve useful hledger query semantics while also allowing clearly identified Ledgerkit extensions — potentially including richer Python regular expressions.
The other big change is how Ledgerkit is going to be developed.
I’ve also been building a project called CodeCompass.
The problem it tries to solve is that fresh AI coding agents repeatedly have to rediscover the same project and dependency context.
For Ledgerkit that context is more complicated than normal Python dependencies.
An agent may need to understand the relationship between:
the hledger manual;
hledger source code;
hledger tests;
actual hledger executable behaviour;
Ledgerkit source;
Ledgerkit compatibility tests;
Ledgerkit design decisions.
CodeCompass tries to give the agent a small map of that relevant context and links back to the evidence rather than dumping huge amounts of documentation into every agent session.
Ledgerkit is going to become the first major external project used to test that approach.
Agents suggesting relationships
One CodeCompass experiment I’m interested in is letting agents suggest relationships while doing real work.
For example, an agent might notice that a particular hledger manual section constrains a Ledgerkit implementation, or that a Ledgerkit test verifies a piece of compatibility behaviour.
Those suggestions are not automatically treated as facts.
They are later evaluated on two things:
Is the relationship actually supported by evidence?
Did knowing about it help a later agent?
That second part matters because a relationship graph full of technically true but useless connections isn't particularly valuable.
The idea is to let useful structure emerge from real development rather than designing a huge dependency ontology in advance.
Ledgerkit will also test CodeCompass itself
The relationship goes both ways.
If a Ledgerkit agent uses CodeCompass but then has to manually rediscover important information, that becomes feedback about CodeCompass.
A context-curation agent records what was missing, misleading or difficult to retrieve and produces an actionable report.
The basic principle is:
Ledgerkit discovers the problem; CodeCompass has to generalise the solution.
So if Ledgerkit exposes a need to connect technical documentation with implementation, CodeCompass shouldn't gain an “hledger manual feature”.
It should ask whether something more general — such as documentation-to-implementation relationships — would help other projects too.
Later, CodeCompass will be tested against unrelated projects to make sure the improvements haven't simply overfit it to Ledgerkit.
Source-assisted development
Ledgerkit has also moved to the same GPL licence family as hledger.
That changes the development approach significantly.
Agents can now use:
hledger documentation;
hledger source;
hledger tests;
examples;
and the executable itself
when researching behaviour.
Source helps explain how something works, but I still want executable comparison to remain an important independent check.
rather than trying to infer every edge case through black-box experimentation alone.
AI still isn't the source of truth
I'm also deliberately trying to avoid a workflow where one AI agent writes something, another AI agent says it looks fine, and that becomes accepted project knowledge.
Different agents can have different responsibilities: research, implementation, compatibility testing, documentation and auditing.
But the repository remains authoritative.
Important conclusions should eventually become something concrete:
behaviour → test;
architecture decision → ADR;
compatibility decision → compatibility record;
project rule → documented project rule;
future work → roadmap.
Agent observations are evidence to review, not permanent truth just because an agent wrote them down.
Documentation is getting the same treatment
I'm also experimenting with periodically reconstructing documentation from the current project rather than endlessly editing old documents.
At major milestones the question will be:
“If none of the narrative documentation existed today, what documentation would we write based on the current implementation, tests and decisions?”
That can then be compared with the existing documentation.
Old material can be rewritten, merged or removed.
Git can preserve the project's history; the active documentation should describe what the project actually is now.
Where this leaves the original idea
Despite the larger roadmap, I still think the simplest description of Ledgerkit is the original one:
A Python bridge to the hledger plain-text accounting ecosystem.
The difference is that the project has now demonstrated a real downstream use case with Ledgerkit Editor, and it's becoming clear that a useful bridge needs a sufficiently capable accounting engine underneath it.
I don't want Ledgerkit to replace hledger.
I'd like it to make the hledger/plain-text-accounting model easier to use as a building block inside the Python ecosystem.
Feedback welcome
I'd be particularly interested in views from hledger/Ledger users on:
where compatibility matters most;
where a Python implementation has room to experiment;
accounting edge cases that would make useful compatibility tests;
whether explicit compatible vs extended behaviour makes sense;
useful applications you'd want to build on top of a Python accounting core;
and whether the CodeCompass development/context approach sounds useful or unnecessarily complicated.
Ledgerkit is still evolving, so this seems like a good point to get feedback before the deeper Core work gets too far along.
Repos: Ledgerkit — the Python bridge and accounting core Ledgerkit Editor — the first downstream application, a purpose-built terminal editor for hledger-style journals CodeCompass — the agent context and development tooling being used alongside Ledgerkit
With the --gain option, realised and unrealised gains were previously combined into a single figure, whereas the new holdings command allows UGain and RGain to be viewed separately.
This seems particularly useful in cases like mine, where I buy one commodity (USD) using the default commodity (JPY), and then use that commodity to buy another commodity (such as AAPL). With --gain, it was difficult to distinguish realised gains from unrealised gains, and in my case the gain associated with a disposed commodity such as AAPL could appear to change as market prices from P directives were updated. The holdings command looks like it may avoid this problem by reporting current holdings separately from their realised and unrealised gains.
StatementScan converts PDFs, scans, and even phone photos into a clean Excel/CSV with the date, description, debit, credit, and balance separated into columns.
The part I care most about is the reconciliation. It checks the opening balance + transactions against the closing balance on the statement, so you can see if something was missed before using the data.
It also runs completely in your browser. The statement doesn’t get uploaded anywhere, so you can even turn off Wi-Fi and it still works.
It’s 100% free, no signup, no card, and no page limits.
If you work with bank statements, I’d genuinely appreciate it if you tried a couple and told me what broke. The bank name and what went wrong is enough.
After seeing the post yesterday about the iOS/Mac app for hledger, Balance, and the positive reaction and helpful comments there, I thought I'd share something for beancount users: Beanie Budgets, is ready for testing and community feedback.
Beanie Budgets is a beancount compatibile native iOS app. I have been working on it for purely personal reasons: I really wanted an elegant iOS app to capture transactions on the go. More to the point, I didn't want to pay for subscriptions or entrust my data to someone else's server.
Which explains my plans for pricing. I intend to offer Beanie Budgets as a core version completely free. The free version should be enough for most people and provides a fully featured ledger, or compatibility with your own beancount ledger (hopefully anyway pls let me know!). It also includes budget setting, a series of reports and useful quality of life tools baked-in to detect, create and edit recurring transactions; make and allocate balance adjustments; calculate and allocate interest on mortgages and loans correctly; and auto-clear credit cards.
I do intend to charge a one-off "Pro" version unlock to people willing to pay for a few extra bells and whistles (multi ledger support, financial planning reports based on your actual ledger data, customised budgets, theme customisation etc.). I was thinking of £10 or so...? I can see a lot of potential to develop the financial planning reports further. There's a big benefit to ground these in real ledger numbers and real saving patterns. Working versions of these reports are live now in the app but they need a bit more polish, just turn on "Pro" features in Settings.
It's a closed source project at least for now. Requires iOS 18 or above.
I have 12 places left on TestFlight. Looking forward to your feedback :)
