Hledger Is "Command-Line Powerhouse" While Fava Offers "Modern Polished Dashboard"—Do We Need Both or Should Plain Text Accounting Pick One Philosophy?

General
1

hledger Is “Command-Line Powerhouse” While Fava Offers “Modern Polished Dashboard”—Do We Need Both or Should Plain Text Accounting Pick One Philosophy?

I’ve been using Beancount + Fava for about 4 years now, and I’m starting to notice something interesting in our community. There’s a philosophical divide emerging that I think deserves discussion.

The Two Paths

On one side, hledger champions the command-line approach: “rich set of built-in commands for generating reports directly in terminal,” text-based workflows, Unix philosophy of composable tools. It’s keyboard-only, scriptable, SSH-friendly—the developer’s dream.

On the other side, Beancount + Fava embraces the GUI: “full-featured web interface with interactive charts, graphs, net worth trends, expense treemaps.” It’s visual, intuitive, modern UX that feels comfortable to accountants and bookkeepers who came from QuickBooks.

My Personal Journey

When I started with Beancount, I came from GnuCash (which has a GUI). Initially, I thought I’d miss the graphical interface, but what I discovered is that I use both paradigms depending on the task:

  • Command-line for routine work: Running my import scripts, checking balances, quick queries while I’m already in terminal
  • Fava for analysis: Exploring spending patterns, showing reports to my spouse, visual treemaps that reveal insights I’d miss in text

The question is: should we be building toward convergence or divergence?

The Convergence Argument

Maybe we should build amazing Fava-equivalent for hledger (or amazing CLI for Beancount) so both tools offer both paradigms. Why force users to choose between CLI power and GUI accessibility?

The Divergence Argument

Or maybe it’s healthier if hledger becomes “CLI champion” and Beancount becomes “GUI champion”—serve different audiences well rather than trying to be everything to everyone.

Real-World Implications

Here’s where it gets practical:

  • If you need a client portal (show financials to non-technical board members or business owners), Fava wins. I can’t imagine asking a nonprofit board treasurer to SSH into a server and run hledger balance --monthly --tree Assets:Checking.

  • If you need SSH access from anywhere (manage finances on remote server via terminal only), hledger wins. When I’m traveling and only have my phone + SSH client, I can’t run Fava easily.

  • For automation and scripting, both can work, but hledger’s rich built-in commands means less Python glue code.

My Question to the Community

Do you primarily use CLI or GUI for your financial analysis? Does it depend on the task?

For those who’ve tried both tools: did you choose based on CLI vs GUI preference, or were other factors more important?

And the bigger question: is it realistic to expect one tool to serve both the developer who wants hledger balancesheet --forecast --tree --depth 3 and the bookkeeper who wants to click pretty graphs? Or are we fundamentally different user bases?

I’m genuinely curious because I see value in both approaches, but I wonder if trying to serve both audiences means we serve neither particularly well.

Edited to add: I’m not trying to start a tool war here. I use Beancount because it’s what I learned first, but I respect the hledger community’s different philosophy. Just trying to understand if there’s a “right” answer or if diversity is actually the healthiest path.

2

This resonates hard. I’m a data analyst by day and FIRE blogger by night, and I’ve built my entire financial tracking stack around Beancount + Fava specifically because of the GUI.

Here’s my controversial take: CLI-only is a barrier to mainstream adoption, and that matters if we want plain text accounting to spread beyond developer circles.

The FIRE Community Reality

Most people in the FIRE movement aren’t developers. They’re teachers, nurses, engineers (not software), government employees. They’ve been using Mint, Personal Capital, YNAB—all GUI tools with pretty charts.

When I write blog posts about Beancount, the #1 question I get is: “Can I see screenshots?” Not “what’s the command syntax,” but “what does it look like?”

Fava is what makes Beancount accessible to that audience. Without Fava, I’d be telling FIRE people to run Python queries to see their net worth trend. That’s a non-starter for 95% of them.

Where CLI Still Wins for Me

That said, I absolutely use command-line for my automation:

# My morning routine
bean-check main.beancount && \
  bean-price -u main.beancount && \
  bean-query main.beancount "SELECT account, sum(position) WHERE account ~ 'Assets:'"

This runs in 2 seconds. Fava would require loading the web interface, waiting for the page, clicking around. For quick checks, CLI is objectively faster.

The Tools Should Specialize

I actually think divergence is better than convergence. Here’s why:

  • hledger for power users: People who live in terminal, manage finances from SSH, prefer keyboard-only workflows. Lean into that. Make the CLI experience phenomenal.

  • Beancount for accessibility: People who want visual dashboards, web-based analysis, easier onboarding. Lean into that. Make Fava amazing.

Trying to build both means neither is exceptional. Look at what happened with text editors: Vim didn’t add a GUI menu bar, VS Code didn’t become CLI-only. They serve different users, and that’s okay.

One Exception: Mobile

The one area where I think we’re ALL failing is mobile access. Neither hledger CLI nor Fava is great on a phone. If I want to check my net worth while waiting in line at the grocery store (yes, I’m that person), both tools are painful.

We need mobile-first interfaces built on top of plain text accounting backends. That’s the actual gap, not CLI vs GUI.

Bottom line: I love that we have both. The diversity makes plain text accounting stronger, not weaker. Different tools for different workflows.

3

Coming from a developer background (DevOps engineer), I thought I’d be firmly in the CLI camp. But after 3 months with Beancount, I’m finding that I need both, but for completely different reasons than I expected.

The Surprising Truth About Learning

When I was learning Beancount, Fava was absolutely essential. Not for the pretty charts, but because:

  1. Visual feedback on mistakes: When I fat-fingered an account name, Fava showed me the typo in red immediately. With CLI, I had to parse error messages.

  2. Understanding account structure: Seeing the hierarchical tree view in Fava helped me grasp how Assets:Bank:Checking relates to Assets:Bank:Savings. Text output would’ve been harder to visualize.

  3. Confidence building: Being able to click around and explore my data without fear of breaking something (it’s read-only!) gave me confidence to experiment.

Where I’ve Grown Into CLI

Now that I understand the basics, I’m using CLI for everything I do regularly:

  • Import scripts: python import.py chase.csv >> main.beancount is my weekly ritual
  • Balance checks: bean-check main.beancount before every commit
  • Quick queries: bean-query main.beancount "SELECT * WHERE account ~ 'Groceries' AND year = 2026" when I want to know specific numbers

CLI is faster once you know what you’re looking for. GUI is better when you’re exploring or learning.

The Developer Analogy

It’s like git vs GitHub Desktop:

  • New developers? Start with GitHub Desktop (GUI) to understand commits, branches, merges visually.
  • Experienced developers? Mostly CLI (git add, git commit, git push) because it’s faster.
  • But even experienced devs use GitHub’s web interface for pull request reviews, commit history exploration, visual diffs.

Both tools have a place in the workflow.

My Hot Take: We’re Gatekeeping

@finance_fred is right—CLI-only is a barrier. But here’s what I think we’re missing:

The plain text accounting community is accidentally gatekeeping by emphasizing CLI power in our documentation and tutorials. When hledger says “command-line powerhouse” as a selling point, it signals to non-developers: “this isn’t for you.”

Meanwhile, Fava’s existence makes Beancount seem more welcoming, even though under the hood they’re equally complex.

What I’d Actually Want

A world where:

  • Learning path starts with GUI (Fava for Beancount, maybe hledger-web for hledger) to build mental models
  • Power users graduate to CLI for speed and automation
  • But GUI remains excellent for exploration, analysis, and showing reports to others

Neither tool should abandon either paradigm. But maybe we need better guidance on “use GUI for X, use CLI for Y” instead of treating them as philosophical opposites.

Also +1 to the mobile comment. I tried running Fava on my phone and… yeah, no. That’s the real gap.

4

As someone who uses Beancount professionally with 20+ small business clients, I have to add the client-facing perspective that I think is missing from this discussion.

The Hard Truth: Clients Don’t Care About Your Workflow

My clients don’t know (or care) whether I use CLI or GUI internally. What they care about is:

  1. Can they understand their own financials? (GUI wins here—I send them Fava links)
  2. Can they get reports quickly? (CLI automation wins—I script monthly reports)
  3. Does it look professional? (This is where it gets tricky…)

Professionalism Perception Problem

Here’s something uncomfortable I’ve encountered: when I show a client a beautifully formatted Fava dashboard, they’re impressed. When I show them a terminal window with hledger balancesheet, they get nervous.

“Wait, is our financial data in some… command-line thing? Is that secure? What happens if you get hit by a bus?”

Fair or not, GUI = professional in many clients’ minds. CLI = hobbyist or “too technical to trust.”

This is especially true for:

  • Nonprofit boards (they want something that looks like QuickBooks)
  • Small business owners over 50 (never used terminal in their lives)
  • Investors/stakeholders reviewing financials (want familiar-looking reports)

Where CLI Saves My Business

But internally, CLI is what makes Beancount viable for professional work:

Monthly close workflow (runs via cron every month):

#!/bin/bash
for client in clients/*/; do
  bean-check "$client/main.beancount" && \
  bean-report "$client/main.beancount" income --monthly > "$client/reports/income.txt" && \
  bean-report "$client/main.beancount" balance > "$client/reports/balance.txt"
done

This runs for all 20+ clients in minutes. Doing this through GUI would take hours of clicking.

The Middle Path I’ve Found

My actual workflow is CLI for me, GUI for them:

  • I work in terminal: imports, reconciliation, error checking—all CLI because it’s faster
  • Clients see Fava: each client has a Fava instance on a subdomain (client1.mybookkeeping.com), they log in and see pretty dashboards
  • Monthly reports: automated via CLI, but exported to PDF that looks professional (not raw CLI output)

This hybrid approach works, but it requires maintaining both. If I had to pick one, I’d pick GUI reluctantly, because client perception matters for business sustainability.

Disagree on Divergence

@finance_fred I actually disagree that tools should specialize completely. Here’s why:

Professional bookkeepers need both. I need CLI for automation efficiency and GUI for client communication. If hledger went CLI-only and Fava development stopped on Beancount, I’d be in trouble either way.

What we actually need is acknowledgment that both interfaces serve essential but different functions:

  • CLI = production workflow (speed, automation, batch processing)
  • GUI = communication interface (clients, stakeholders, visual analysis)

Neither is optional for professional use. They’re complementary, not competitive.

The Real Question

Maybe the question isn’t “CLI vs GUI?” but rather: “How do we make plain text accounting tools that support both professional bookkeepers AND developer-hobbyists?”

Because right now, I feel like the community is optimizing for developer workflows (which value CLI) at the expense of professional workflows (which require client-facing GUI).