Fava: a web interface for Beancount ledgers

What Fava solves, and for whom

Beancount keeps a ledger in plain text files. That is a strength for version control and diffing, and a weakness for anyone who wants to see balances, income statements or a register without writing a query. Fava fills that gap: it is, in the README's words, a web interface for the double-entry bookkeeping software Beancount "with a focus on features and usability". The audience is people who already write Beancount syntax by hand and want a read-oriented view on top of it. It is not a bookkeeping application that stores your data in its own format. The ledger file stays the source of truth; Fava renders it.

The package metadata in pyproject.toml lists classifiers such as "Intended Audience :: End Users/Desktop" and "Intended Audience :: Financial and Insurance Industry", and the dependency list pins beancount>=3.2.0,<4 alongside beangulp and beanquery. That dependency set is the clearest statement of scope: Fava is the presentation layer of the Beancount toolchain, not a replacement for it.

How Fava reads a ledger: Flask, beanquery and a file watcher

Fava is a Flask application. The dependency list names Flask, Flask-Babel, Jinja2 and Werkzeug, so the server side renders templates and serves JSON to a frontend built from the frontend/ directory. The Makefile compiles frontend sources into src/fava/static/app.js, which means the shipped Python package carries a prebuilt JavaScript bundle rather than asking you to run a Node toolchain.

Queries against the ledger go through beanquery, pinned to >=0.1,<0.3. That is the layer that turns a BQL query into results over the Beancount data, and it is why Fava can offer report views without reimplementing Beancount's semantics. Importing transactions is delegated to beangulp, listed as beangulp>=0.2, so the importer framework is a separate project rather than code inside Fava.

One dependency deserves attention: watchfiles>=0.20.0. Fava watches the ledger file, so edits made in your editor are picked up by the running server instead of requiring a restart. For a plain-text workflow this is the feature that makes the browser tab usable alongside an editor. The production server is cheroot, pinned >=8,<12, which is what Fava uses when you run it as a server rather than through the Flask development server.

Installing Fava and viewing a ledger for the first time

The README gives the shortest path for someone who already knows Beancount. Install from PyPI, then point the fava command at a ledger file:

pip3 install fava
fava ledger.beancount

After that command, the README says to visit the web interface at http://localhost:5000. That port is the default the README documents; if something else already listens there, the command will fail to bind and you will need to check the Getting Started page for the option that changes it. The command takes the path to a Beancount file, so the working directory matters: run it where ledger.beancount actually is, or pass a path.

If you would rather not install into your system Python, the repository is set up for uv. The Makefile defines a dev target that creates a virtual environment from uv.lock:

uv sync
uv run fava ledger.beancount

The dev target also installs pre-commit hooks via prek, which is aimed at contributors rather than users. For a normal install, the pip3 route from the README is the one to follow; requires-python is >=3.10, so an older interpreter will refuse the install.

Where Fava is the wrong tool

Fava is a single-ledger web interface, and that shapes its limits. The README describes installation as a local command and points at http://localhost:5000, which is a loopback address. Nothing in the README describes user accounts, authentication or a hosted deployment model. If you need several people editing the same books through a browser with per-user permissions, Fava as documented is not that product; you would be exposing a local tool and solving access control yourself.

The mobile question is similar. The related searches show people looking for an Android client and a mobile experience, but the README mentions only the online demo and the website. There is no mobile application in the repository layout, which lists frontend/, src/, tests/ and docs/ but no platform-specific client directory. A browser on a phone can reach a running instance, but that is a consequence of it being a web app, not a documented mobile offering.

The other boundary is Beancount itself. Fava's value depends on your ledger being valid Beancount. If your accounts live in a proprietary format, or in a spreadsheet you are not willing to convert, Fava has nothing to render. The dependency pin beancount>=3.2.0,<4 also means a ledger written for an older Beancount major version is not a supported target.

Fava compared with hledger and its web interface

The related searches pair Beancount with hledger, which is the natural comparison because both are plain-text accounting tools. The difference is in the stack. hledger is a Haskell implementation with its own ledger format and its own command-line tooling; Beancount is a Python project with its own syntax and a query language, and Fava sits on top of it through beanquery. Choosing between them is mostly choosing the ledger format and the surrounding ecosystem, not the web view.

Within the Beancount world, the alternative to Fava is the command line. You can run beanquery directly against a ledger and get the same underlying data without a server process, which is lighter and scriptable. What you give up is the rendered reports, the register view and the live reload that watchfiles provides. Fava's own dependency list makes that relationship explicit: it depends on beancount and beanquery rather than replacing them, so the command-line path remains available and does not conflict with running Fava alongside it.

Maintenance, releases and the MIT licence

The repository is not archived, and the last push was on 2026-09-26. The project metadata carries the classifier "Development Status :: 5 - Production/Stable", and pyproject.toml declares support for Python 3.10 through 3.14. The maintainers are listed as Jakob Schnitzer, with Dominik Aumayr as author. No release information was retrieved, so version history has to come from the changelog link in project.urls, which points at the website rather than the repository.

Upgrade cost is dominated by two things. First, the Beancount pin: beancount>=3.2.0,<4 means Fava tracks Beancount 3.x and will not accept a 4.x. Second, the frontend: src/fava/static/app.js is a build artifact produced by npm from frontend/, so anyone installing from source rather than PyPI needs Node available, and the Makefile's frontend/node_modules target runs npm install. Installing from PyPI avoids that entirely.

The licence is MIT, declared both in pyproject.toml and in the LICENSE file at the repository root. MIT is permissive, which in practice means you can bundle Fava with other software provided you keep the copyright notice and licence text; it does not impose a copyleft obligation on your own code. That is a description of the licence text, not legal advice, and if you are redistributing Fava inside a product you should read LICENSE yourself.

Editorial conclusion

Adopt Fava if your books already live in Beancount files and you want a browser view over them without moving data into a database. Do not adopt it if you need a hosted multi-user accounting service or a mobile app: the README points to an online demo, not to an Android or iOS client, and the project is a local web interface. Before committing, install it against a copy of your ledger, confirm that the Beancount version you use satisfies the beancount>=3.2.0,<4 requirement in pyproject.toml, and check the Getting Started page for the current install path.

Frequently asked questions

Official sources

1. beancount/fava on GitHub
2. Issues
3. License: MIT
4. Project website
5. README