Client Portal Expectations in 2026: Why Fava Isn't Enough for Non-Technical Clients

General
1

I just had a reality check moment this week. One of my clients - a local coffee shop owner - asked if she could “check the books from her phone” while traveling. I excitedly showed her Fava, thinking she’d love the clean interface and powerful filtering. Her response? “This looks… complicated. Can’t I just get an app like the one my friend uses for QuickBooks?”

That conversation has been haunting me. We’re in 2026, and client expectations have fundamentally changed. They expect:

  • Mobile apps they can check while standing in line at the grocery store
  • Push notifications when invoices are paid or bills are due
  • Photo uploads of receipts taken with their phone camera
  • Guided workflows that walk them through data entry step-by-step
  • Instant confirmation when documents are uploaded at midnight

And here’s the thing: Fava doesn’t offer any of these features.

Don’t get me wrong - I absolutely love Fava. For me (a bookkeeper who lives in spreadsheets and terminal windows), it’s perfect. The real-time filtering, multi-account views, and interactive reports are exactly what I need for my work. But I’m starting to realize that what works brilliantly for us as Beancount users doesn’t translate to what clients expect from accounting software in 2026.

The Fava Reality for Non-Technical Clients

Let me be honest about what happens when I try to show Fava to clients:

  1. The Interface Intimidates Them - Even though Fava is clean and well-designed, clients see text-based data and accounting jargon. They’re used to QuickBooks Online’s guided dashboards that literally say “Do this next.”

  2. No Mobile Experience - Clients expect to tap an app icon on their phone. Fava works on mobile browsers, but it’s clearly designed for desktop. The filtering and navigation feel clunky on a small screen.

  3. No Push Notifications - When a client pays an invoice, other platforms send a cheerful push notification. With Fava, you have to log in and check. That sounds minor, but it’s a huge behavioral difference.

  4. Technical Barrier to Entry - My coffee shop owner doesn’t want to learn about account hierarchies or query syntax. She wants to tap “Show me this month’s sales” and see a simple chart.

The Two-Track Dilemma

This is creating a split in my workflow that feels increasingly unsustainable:

  • Track 1 (My Internal Work): I keep perfect books in Beancount, use Fava daily for analysis, leverage all the power of plain text accounting. This part is working beautifully.

  • Track 2 (Client-Facing): I… export to PDF? Email Excel spreadsheets? Build custom reports? None of these feel like the “modern accounting experience” clients expect in 2026.

I’m starting to wonder if Beancount + Fava is inherently an internal-use-only tool system, and I need to accept that client communication requires a different presentation layer entirely.

The Questions Keeping Me Up at Night

I’m hoping this community can help me think through this, because I really don’t want to abandon Beancount’s precision and auditability:

  1. Do you show Fava directly to clients? If yes, what types of clients accept it? Only technical ones?

  2. What’s your client communication workflow? PDF exports? Custom dashboards? Hybrid approach with another tool?

  3. Has anyone built a custom client portal on top of Beancount as a backend? Using Fava’s API with a different frontend?

  4. Is there a philosophical answer here? Should we accept that Beancount is a professional tool (like Vim or Emacs) and stop trying to make it client-facing?

I’d love to hear how other bookkeepers, CPAs, and solo practitioners are handling this. My clients love the quality of my work, but they’re starting to expect the experience that comes with modern SaaS platforms. How do we bridge that gap?

TL;DR: Fava is perfect for Beancount users, but clients in 2026 expect mobile apps, push notifications, and guided workflows. How do you handle client-facing reporting and communication while keeping Beancount for your internal workflow?

2

Alice, this resonates so hard. I’ve been wrestling with this exact problem for the past six months.

What you’re describing is exactly my experience. I have 20+ small business clients, and every single one of them expects what I call “the QuickBooks Online experience” - mobile apps, push notifications, the whole nine yards. Meanwhile, I’m sitting here with Fava open on three monitors, loving every second of plain text accounting, and they just… don’t get it.

Here’s what I’ve landed on (and I’m still iterating):

My Current Two-Tier System

Tier 1 (My Internal Workflow):

  • Keep the books in Beancount - this is non-negotiable for me
  • Use Fava for all my analysis, reconciliation, and monthly close
  • Version control everything in Git for audit trails
  • Python importers for automated bank feed processing

Tier 2 (Client-Facing):

  • PDF reports generated via Python scripts (I’m working on styling these to look more professional)
  • Monthly email delivery on a schedule
  • For clients who demand “real-time” access… honestly, I’m still figuring this out

The frustrating part? I’m maintaining two separate presentations of the same data. The coffee shop owner you mentioned? She gets a PDF emailed on the 5th of each month. She’s happy with it, but she’s also not a “check daily” type. For clients who want daily access, I’ve been… avoiding taking them on? Which feels like a business limitation I shouldn’t accept.

What I’m Experimenting With

I’ve been playing with the idea of using Fava’s query API to generate custom reports that I could host on a simple web page. Nothing fancy - just monthly P&L, balance sheet, and maybe a cash flow chart. The challenge is that I’m not a developer, so even “simple” web development feels like learning a foreign language.

I’d be really curious if anyone in this community has built something like this. A “Fava-Lite” interface that shows just the reports clients care about, without all the power-user features that intimidate them.

The Philosophical Question

Your Vim/Emacs analogy is spot on. I’ve been thinking about it more like this: Beancount is PostgreSQL, and we need an Airtable layer on top of it. The database is perfect for what it does - structured, precise, auditable. But end users don’t interact with databases directly; they interact with applications built on top of databases.

Maybe the answer isn’t to make Fava more client-friendly. Maybe the answer is to accept that Fava is our professional tool, and we need a separate “client portal layer” that queries Beancount data but presents it in a way that matches 2026 client expectations.

I just wish that layer existed already, because I don’t have the technical chops to build it myself.

3

Oh man, I’ve been exactly where both of you are. Let me share my hard-learned lesson from trying to solve this problem.

My Failed Experiment

About two years ago, I tried to introduce Fava to one of my rental property landlords. I thought it would be brilliant - give him read-only access to see exactly how his properties were performing, all the detailed transactions, filtering by property, the whole nine yards.

His response after one week: “Mike, this is way too complicated. Can’t you just send me something I can look at on my phone while I’m getting coffee?”

That stung. I’d spent hours setting up the perfect Fava instance with beautiful account hierarchies, and he wanted… a PDF he could scroll through on his iPhone.

The Analogy That Changed My Thinking

Here’s how I think about it now: Asking a client to use Fava is like asking them to read Git commit logs instead of using GitHub’s web interface.

Yes, Git commit logs contain all the information. Yes, they’re more precise and detailed. Yes, power users love them. But GitHub didn’t become successful by exposing raw Git commands - they built a beautiful UI layer on top of Git that makes it accessible to non-technical users.

Fava is our Git. It’s a power tool for people who understand double-entry bookkeeping and want maximum control. That’s us. That’s not our clients.

My Current Solution (That Actually Works)

After that failure, I completely changed my approach:

  1. Beancount + Fava = My Internal Tools - I do all my actual bookkeeping work here. This is the “source of truth.”

  2. Python Report Generator = Client Delivery - I wrote a Python script (admittedly, took me a month to get it right) that:

    • Queries Beancount data using beanquery
    • Generates styled HTML reports (monthly P&L, balance sheet, property summaries)
    • Converts to PDF using WeasyPrint
    • Emails automatically on schedule

  3. Client Never Sees Beancount - They receive professional-looking PDFs that match what they’d get from any other accounting service. They’re happy, I’m happy.

The script isn’t perfect, but it’s working. My landlord gets his monthly reports, views them on his phone, and occasionally replies with “Looks good!” That’s the level of engagement most clients actually want.

Could We Build Something Better?

I’ve been thinking about this a lot. What if someone built a “Fava-Client” fork? Something like:

  • Mobile-responsive design that actually works on phones
  • View-only mode with simplified navigation
  • Pre-built report dashboards (P&L, Balance Sheet, Cash Flow)
  • No query bar or advanced features that intimidate non-technical users
  • Still powered by Beancount as the backend

It would be a separate project, not trying to make Fava itself more user-friendly (which might compromise what makes Fava great for us), but rather creating a companion tool specifically for client access.

My Advice

Alice, Bob - don’t abandon Beancount. The precision and auditability are too valuable. But also don’t try to force Fava on clients who aren’t ready for it.

Instead:

  • Use Fava as YOUR tool
  • Build or find a presentation layer for clients
  • Accept that these are two different audiences with different needs

If anyone wants to see my Python report generator, I’m happy to share it. It’s rough around the edges, but it gets the job done. DM me if you’re interested.

The good news? Your clients don’t actually want to learn Beancount. They just want clear, timely information. You can give them that while still keeping the power of plain text accounting for yourself.

4

This is fascinating to read from the professional accounting perspective. I’m coming at this from a completely different angle - I use Beancount for personal FIRE tracking, not client work - but I ran into the exact same problem.

My Version of This Problem

My wife wanted to check our finances while traveling. She’s smart, capable, not afraid of technology. But when I showed her Fava, her eyes just glazed over. “Can’t we use something simpler?” she asked.

That was my wake-up call that Fava, as awesome as it is for me, wasn’t going to work for someone who just wants to quickly check “how much can we spend this month?”

What I Built (And What It Taught Me)

I spent about three months building a custom dashboard on top of Beancount. Here’s the architecture:

Backend:

  • Beancount files remain the source of truth
  • Fava runs as a backend API server (not for UI)
  • Python Flask API queries Beancount data and reformats it

Frontend:

  • React web app (mobile-first design)
  • Progressive Web App (PWA) so it feels like a native app
  • Shows only the metrics my wife actually cares about: monthly budget, net worth trend, upcoming bills

Result: She uses it daily. Has it bookmarked on her phone home screen. Never sees Fava, never sees Beancount files, doesn’t need to.

The Key Insight: Fava Is An Excellent API

Here’s what I learned: Fava is actually a fantastic backend API. The problem isn’t Fava itself - it’s trying to use Fava as both the engine AND the user interface.

Think of it like this:

  • PostgreSQL = Beancount (data storage/processing)
  • pgAdmin = Fava (power user interface for database administrators)
  • Airtable = The missing piece (user-friendly interface for end users)

Bob’s PostgreSQL/Airtable analogy is exactly right. We don’t ask end users to interact with PostgreSQL directly, even though it’s a brilliant database. We build applications on top of it.

The Business Opportunity Here

For professional bookkeepers and CPAs reading this: there’s a huge market opportunity here.

Right now, you’re competing with QuickBooks Online and Xero, which offer:

  • Native mobile apps
  • Real-time client portals
  • Modern UX
  • But also: subscription costs, vendor lock-in, limited customization

What if you offered:

  • All the benefits of Beancount (precision, auditability, version control, plain text)
  • Plus a custom client portal that looks and feels like modern SaaS
  • Marketed as “boutique accounting with transparency you can’t get elsewhere”

I genuinely think there’s a competitive advantage in being the bookkeeper who can show clients “here’s your mobile-friendly dashboard” while you maintain the books in Beancount on the backend.

ROI Calculation (Because I Can’t Help Myself)

Let’s say you spend:

  • 40 hours learning React/Vue basics
  • 60 hours building a simple client portal template
  • 20 hours per client customizing it

Total: 120 hours for the first client.

But then:

  • Each additional client needs only 20 hours of customization
  • You can charge a premium for “modern tech stack”
  • You’re not paying $50/month per client for QuickBooks Online licenses

Break-even after client 5 or 6. Every client after that is pure margin improvement.

My Offer To This Community

I’m not a professional accountant, so I can’t monetize this directly. But I’d be happy to:

  • Share my frontend code as a starting point
  • Help anyone interested in building a “Beancount-as-a-Service” platform
  • Collaborate on an open source “Fava-Client” project

The technical foundation exists. What’s missing is someone with accounting expertise to shape it into something client-ready.

Alice, Bob, Mike - if any of you want to explore this, DM me. I think we could build something really useful for this community.

TL;DR: Fava is an excellent backend API. Stop trying to use it as a client-facing UI. Build a simple presentation layer on top of it, and you get the best of both worlds - Beancount’s power for you, modern UX for clients.

5

Wow, I’m so grateful for these thoughtful responses. This conversation is exactly what I needed.

What I’m Taking Away

Bob - Your PostgreSQL/Airtable analogy crystallized something for me. I’ve been trying to make Fava do something it was never designed to do (be client-facing), when what I really need is to accept Fava as my professional tool and build a separate presentation layer.

Mike - Your Git/GitHub comparison is perfect. And honestly, your Python report generator solution is probably the most immediately actionable approach for me. I don’t have the frontend development skills that Fred has, but I can probably manage Python scripting. Would definitely appreciate seeing your code if you’re willing to share.

Fred - The fact that you built a full custom dashboard for personal use is inspiring. And your ROI calculation makes a compelling case. I’m not sure I’m ready to dive into React development, but you’ve convinced me that treating Fava as an API is the right mental model.

My Immediate Action Plan

I’m going to try a phased approach:

Phase 1 (Next 2 Weeks):

  • Stick with Fava for my internal workflow (this is working perfectly)
  • Implement Mike’s approach: Python scripts to generate PDF reports
  • Start emailing monthly reports to clients on a schedule
  • Stop trying to give clients direct Fava access

Phase 2 (Next 3 Months):

  • Learn basic web development (probably start with simple Flask app)
  • Experiment with querying Beancount data programmatically
  • Build a simple read-only web page showing key metrics
  • Test with 1-2 friendly clients

Phase 3 (Long-term):

  • If Phase 2 works, gradually expand the custom portal
  • Maybe collaborate with others in this community on a shared solution
  • Possibly contribute to or sponsor an open source “Fava-Client” project

The Bigger Picture

I think what this conversation has revealed is that there are actually three distinct user personas in the plain text accounting ecosystem:

  1. Power Users (Us): We use Fava daily, love the query syntax, want maximum control. Fava is perfect for us.

  2. Technical Clients: Some clients can handle Fava with training - probably engineers, data analysts, etc. These folks might appreciate direct Fava access.

  3. Non-Technical Clients: Most small business owners. They need simplified dashboards, mobile access, guided workflows. They should never see Fava.

The mistake I was making was trying to force Persona 3 to use a tool designed for Persona 1.

To the Community

Is there interest in a collaborative project to build a “Fava-Client” or “Beancount Portal” tool? It seems like several of us are independently solving the same problem. Maybe we could:

  • Create a shared repo
  • Develop a simple, mobile-friendly client portal template
  • Make it easy for bookkeepers/CPAs to deploy
  • Keep it open source so the community benefits

Fred, if you’re serious about sharing your frontend code, I think that could be an amazing starting point. Mike, your Python reports could be another component. I could contribute accounting best practices and CPA compliance considerations.

Anyone interested in collaborating on this?

Final thought: I’m no longer frustrated about Fava’s limitations. Instead, I’m excited about the possibility of building something that complements Fava perfectly - a client-facing layer that makes Beancount accessible to everyone while preserving all the power and precision we love about plain text accounting.

Thank you all for helping me reframe this problem!