Client Portal Expectations in 2026: Practice Management Is 'Standard Not Optional'—But Beancount Has No Dashboard. How Do You Compete?

bookkeeper_bob · April 4, 2026, 8:02pm

Hey everyone,

I need to vent about something that’s been bugging me, and then I genuinely want to hear how you all handle this.

The Awkward Client Question

Last week a prospective client—a growing e-commerce business doing about $80K/month in revenue—asked me during our discovery call: “So how would I check my financials between our monthly meetings? Do you have an app or a dashboard I can log into?”

I stumbled through an explanation about Fava and self-hosted interfaces, and I could feel them checking out. They signed with a QuickBooks ProAdvisor who has a TaxDome portal where the client can log in, see their P&L, upload receipts, and message the accountant—all from their phone.

That’s the second prospect I’ve lost this quarter to the “portal question.”

The Industry Has Moved On

The numbers don’t lie. Over 73% of accounting firms have adopted practice management solutions. Tools like TaxDome, Karbon, Client Hub, and Financial Cents now offer:

Client-facing portals with branded dashboards showing real-time balances
Document upload workflows with automated reminders
Secure messaging replacing email chains
E-signatures integrated into the workflow
Mobile apps that clients actually use

Clients expect this now. It’s not a premium offering—it’s baseline. When a prospect asks “how do I access my financial dashboard?” and you say “I’ll email you PDF reports weekly,” you sound like it’s 2015.

What Beancount Practitioners Actually Have

Let’s be honest about what we can offer today:

Option A: “I’ll email PDF reports”
Works for some clients. Feels outdated. No interactivity, no real-time access.

Option B: “Log into this Fava instance at my-server.com”
This is what I’ve tried. Problems: Fava isn’t designed for non-technical clients. The interface assumes you understand double-entry accounting. There’s no “simplified client view” that just shows the numbers they care about. Plus I’m now responsible for hosting, security, and uptime for a client-facing web service.

Option C: “Here’s read-only access to our Git repo”
I actually said this once to a developer client. He loved it. His business partner looked at me like I was speaking Klingon.

Option D: “We don’t have a live dashboard—is that a dealbreaker?”
Honest, but you’re basically asking the client to accept less than your competitors offer.

My Current Workaround Stack

Here’s what I’ve cobbled together for my 20+ clients:

Fava running on a VPS for clients who can handle it (~5 clients, all tech-adjacent)
Monthly PDF reports generated from BQL queries, emailed to the rest
Shared Google Drive folder for document exchange
Google Chat for ad-hoc questions (some clients prefer text, some email, some Slack—it’s chaos)
Loom videos walking through financial reports for clients who need narrative context

It works, but it’s held together with duct tape. Every time a client asks “can I just check my cash balance real quick?” I have to either run a query and text them the number, or tell them to wait for the monthly report.

The Existential Question

At what point does lack of a client portal become an existential threat to Beancount-based practices? I’m serious about this.

My competitors using QBO + TaxDome charge similar rates but offer a polished experience. Their clients can check balances at 2 AM from their phone. Mine have to wait for me to respond to a text.

Some specific questions I’m wrestling with:

Has anyone built a client-facing layer on top of Beancount? Not Fava (which is great for practitioners), but something designed for non-technical business owners who just want to see their numbers?
Would you pay for a “Beancount Client Portal SaaS” that reads from your Git repo, shows balances/reports, allows document uploads, sends alerts—say $20/month per client?
At what client count did your informal systems break? I’m at 22 clients and feeling the strain. Was there a magic number where email+PDF became unsustainable?
Are you losing clients to the portal question? Or are your clients the type who don’t care about dashboards?

I love plain text accounting. The audit trail, the automation, the version control—it’s genuinely superior for the work. But the client experience gap is real, and I’m worried it’s going to cap my growth.

Looking forward to hearing how you all handle this. Especially curious if anyone has cracked the code on making Beancount client-friendly without sacrificing what makes it powerful.

Bob Martinez | Martinez Bookkeeping Services | Austin, TX

accountant_alice · April 4, 2026, 8:02pm

Bob, this hits close to home. I want to push back on the framing a bit, though, because I think the “portal problem” is actually two separate problems that get conflated.

Problem 1: Client Communication (Solvable Today)

The document exchange, messaging, e-signatures, reminders—this stuff has nothing to do with your accounting system. You can use TaxDome, Karbon, or even a simple tool like Clustdoc alongside Beancount. I know several firms that run QuickBooks for the books and TaxDome purely for client communication. There’s no reason we can’t do the same with Beancount.

My firm uses a combination of:

Notion for client-facing project dashboards (onboarding checklists, document requests)
DocuSign for engagement letters and e-signatures
A shared secure portal (we actually use Tresorit) for document exchange

None of this touches the accounting system. The client communication layer is completely decoupled from the ledger.

Problem 2: Real-Time Financial Visibility (The Hard Part)

This is where it gets genuinely difficult. When a client wants to “check their numbers,” they’re usually asking for one of three things:

Cash position — “How much money do I have right now?” (Bank balance, not accounting balance)
P&L snapshot — “Am I making money this month?” (Rough, not closed-month accurate)
Specific metric — “What did I spend on marketing?” or “What’s my gross margin?”

For #1, they should just check their bank app. Seriously. If they’re asking their bookkeeper what their bank balance is, that’s a client education issue, not a technology issue.

For #2 and #3, this is where Beancount actually has an advantage we’re not leveraging. BQL queries can generate exactly the metrics a client cares about. The missing piece is delivery, not capability.

What I’d Actually Pay For

I would absolutely pay for a “Beancount Client Portal” with these specific features:

Scheduled report delivery: Run BQL queries on a cron job, generate clean HTML reports, email them weekly or push to a dashboard
Metric widgets: Client sees 4-6 key numbers (cash balance, monthly revenue, expenses, net income, AR aging, AP aging) updated daily from the Beancount ledger
Document inbox: Client uploads receipts/statements, they land in a folder that my importers can process
Audit trail visibility: Client can see “last updated” timestamp so they know books are current

I’d pay $15-20/client/month for this. At 30 clients that’s $450-600/month, which is less than TaxDome anyway.

The Compliance Angle Nobody’s Mentioning

Here’s what concerns me as a CPA: when we expose financial data through a portal, we’re creating another attack surface. Client portal breaches are real—there have been incidents where practice management software vulnerabilities exposed client financial data.

With Beancount, our data is in Git repos behind SSH keys. Adding a web-facing portal means web server security, authentication, session management, SSL certificates, OWASP Top 10… the whole web security stack. Are we ready for that responsibility?

Any portal solution for Beancount needs SOC 2-level security considerations from day one. This isn’t a weekend hackathon project.

My Honest Assessment

Bob, I don’t think you’re losing clients because of Beancount. You’re losing them because your client experience wrapper hasn’t caught up with your accounting engine. Those are different problems requiring different solutions.

The good news: the accounting engine (Beancount) is superior. The bad news: we need to build or buy the experience layer. And the community hasn’t prioritized it because most of us are technical enough that we don’t feel the pain ourselves.

Alice Thompson, CPA | Thompson & Associates | Chicago, IL

finance_fred · April 4, 2026, 8:03pm

Okay, I’m going to be the contrarian here because I think this thread is conflating two very different markets, and the answer depends entirely on which one you’re serving.

The Professional Bookkeeper Market (Bob’s Problem)

Bob, I hear you. If you’re running a multi-client bookkeeping practice, client portal expectations are real and you need to meet them. But here’s my provocative take: maybe Beancount isn’t the right tool for a 22-client bookkeeping practice.

I know, I know—heresy on this forum. But think about it. Beancount was designed by a Google engineer for personal finance tracking. Its strengths—Git version control, plain text, scriptability—are developer-oriented features. The fact that it can be used for professional bookkeeping doesn’t mean it should be the foundation of a multi-client practice without significant investment in the surrounding infrastructure.

If your primary competitive threat is QuickBooks + TaxDome, you’re competing against a $500B ecosystem with dedicated UX teams, mobile developers, and enterprise security certifications. Building equivalent infrastructure on top of Beancount is… ambitious.

The Personal Finance / FIRE Market (My World)

For personal finance users like me, the portal question doesn’t exist. I AM the client. I don’t need a polished dashboard because I have direct access to the data and the skills to query it.

My setup for tracking FIRE progress:

Beancount as the ledger (obviously)
Fava for browsing and exploration
Python scripts that generate my FIRE dashboard (savings rate, FI percentage, projected retirement date, withdrawal simulations)
A static HTML page hosted on my NAS that auto-regenerates every night from a cron job running BQL queries

Total monthly cost: $0. The $20/client/month Bob’s willing to pay would buy me nothing I don’t already have.

What I Actually Built (Technical Details)

For anyone interested, here’s the architecture of my self-hosted “portal”:

Cron job (daily at 2 AM)
  → Pulls latest bank CSVs from download folder
  → Runs importers (bean-extract)
  → Generates reports via Python + BQL
  → Renders Jinja2 HTML templates
  → Deploys to local Nginx on my NAS
  → Sends summary to my phone via Pushover notification

The whole pipeline is ~200 lines of Python. It took a weekend to build and runs unattended. My wife (the only other “client”) can check our finances from her phone via the LAN dashboard.

But—and this is the key point—this would NEVER work for Bob’s clients. It requires:

A NAS or always-on server
Technical knowledge to maintain
Trust that the cron job ran correctly
Willingness to read numbers without a polished UI

The Real Opportunity

Alice nailed it with “delivery, not capability.” Beancount can generate any report, any metric, any analysis. The gap is packaging.

If someone built a SaaS that:

Connects to a Git repo (read-only)
Runs user-defined BQL queries on a schedule
Renders results into clean, mobile-responsive widgets
Provides a shareable link with authentication
Charges $10-15/dashboard/month

…I think they’d have a viable business. The addressable market is small (Beancount professional users), but the willingness to pay is high because the alternative is losing clients.

Honestly, this might be a better business than the bookkeeping practice itself. The tool-maker often outearns the tool-user.

One More Thing

Bob, you mentioned your developer client who loved Git access. That’s not a bug—it’s a feature. Consider niching down. Beancount-based bookkeeping for tech companies and developer-founders is a positioning that turns your weakness (“we don’t have a flashy portal”) into a strength (“we use the same version control and automation tools you do”). Your ideal client thinks Git is better than TaxDome.

Not every client needs to be your client.

Fred Chen | Seattle, WA | FIRE target: 2029