Managing Multiple Clients with Beancount: Repository Structures & Context-Switching Tips?

[newbie_accountant]

Hi everyone! I’m relatively new to both Beancount and professional bookkeeping, but I’m already starting to see organizational challenges that I’d love advice on.

I just picked up my 6th client this month (exciting!), and I’m trying to figure out the right way to organize my Beancount setup before I get too deep and have to reorganize everything later. I’ve read that bookkeepers hit breaking points around 15 clients and 30 clients where they need to change their whole workflow, so I want to get ahead of that curve.

My Current (Probably Naive) Setup

Right now I have one Git repository with subfolders for each client:

my-bookkeeping/
├── client-cafe/
│   ├── main.beancount
│   ├── data/
│   └── receipts/
├── client-retail/
│   ├── main.beancount
│   ├── data/
│   └── receipts/
├── client-consulting/
├── client-salon/
├── client-restaurant/
├── client-landscaping/
└── shared-importers/
    ├── chase.py
    ├── square.py
    └── quickbooks_export.py

This seemed logical when I started, but I’m already noticing some issues:

Problems I’m experiencing:

1. Git operations are getting slower as the repo grows
2. When I run git status, I see changes across all clients - makes it hard to focus
3. I’m paranoid about accidentally committing Client A’s data to Client B’s folder
4. Context switching between clients feels mentally exhausting
5. Each client has slightly different needs but I’m not sure how to customize without breaking my “standard” approach

Questions for Experienced Folks

1. Repository organization:

• Should I split this into separate repos per client now, or wait until it becomes a real problem?
• What are the pros/cons of monorepo vs separate repos?
• How do you handle shared code (importers, reports) if you use separate repos?

2. Standardization vs customization:

• How much should I try to standardize across clients?
• What things SHOULD be customized per client vs standardized?
• Do you use templates for different industry types?

3. Context switching:

• I read that context switching can cost 40% of productive time - any tips to minimize this?
• How do you mentally “switch” between clients without losing focus?
• Do you batch similar work across clients, or finish one client completely before moving to the next?

4. Workflow efficiency:

• What tools or practices help you scale beyond 10-15 clients?
• At what point did you need to invest in serious automation?
• Any mistakes you made early on that I should avoid?

My Concerns Going Forward

I’m hearing that:

• With good automation, you can handle 30-50 clients per full-time bookkeeper
• Without systems, that drops to 10-15 clients max
• Most people hit a wall around 15 clients if they haven’t organized well

I want to build the right habits NOW while I’m still small, rather than hitting that wall and having to reorganize 15+ client repos in a panic.

What I’ve Learned So Far

Even with just 6 clients, I’ve noticed:

• Naming consistency matters: I now use YYYY-MM-DD-description for all files
• Documentation is essential: Each client folder has a README with account structures and quirks
• Git commit messages help: Writing “Feb 2026 reconciliation - found duplicate charge” is way better than “update”

But I know I’m just scratching the surface here.

Would Love Your Advice

For those of you managing 10+ clients, or who have been doing this for years:

• What repository structure do you use?
• What would you tell your past self when you had 5-10 clients?
• What organizational mistakes did you make that I can avoid?

Thanks in advance for any guidance! This community has been incredibly helpful as I learn both Beancount and professional bookkeeping.

(Also, if anyone has example repository structures or templates they’re willing to share, I’d be super grateful!)

[bookkeeper_bob]

Sarah, great question! I manage 20+ clients now and went through exactly what you’re experiencing.

My Repository Evolution

I started with a monorepo like yours, hit the exact same issues around 8 clients, and switched to separate repos per client. Here’s why:

Separate repos won:

• No risk of accidentally mixing client data
• Git operations stay fast - each repo is small
• git status only shows one client at a time = better focus
• Each client can have different Git histories without conflicts
• Easier to archive old clients or share specific repos with accountants

How I handle shared code:

~/bookkeeping/
├── _shared/
│   ├── importers/
│   │   ├── chase.py
│   │   ├── square.py
│   │   └── quickbooks_export.py
│   ├── reports/
│   │   ├── monthly_summary.py
│   │   └── tax_report.py
│   └── templates/
│       ├── restaurant.beancount
│       ├── retail.beancount
│       └── consulting.beancount
├── clients/
│   ├── cafe-downtown/  [git repo]
│   ├── retail-boutique/  [git repo]
│   ├── consulting-firm/  [git repo]
│   └── ...

Each client repo symlinks to ~/bookkeeping/_shared/importers so I maintain importers in one place but each client has its own isolated repo.

Standardization Strategy

After trial and error, here’s what I standardize:

Always standardized:

• File naming: YYYY-MM-DD-description.beancount
• Top-level account structure: Assets, Liabilities, Income, Expenses, Equity
• Importer scripts from shared folder
• Monthly reconciliation process
• Commit message format

Customized per client:

• Sub-account structures - a restaurant needs Expenses:COGS:Food but a consultant doesn’t
• Report templates - restaurants want inventory reports, consultants want billable hours
• Bank connections - different institutions
• Reconciliation frequency - weekly for high-volume, monthly for others

Industry templates:
Yes! I have starter templates for:

• Restaurants - COGS tracking, tip allocation
• Retail - inventory, sales tax
• Consulting - billable hours, project tracking
• Service businesses - recurring revenue

The template gives them 80% of the structure, then I customize the remaining 20%.

Context Switching Tips

This was my biggest challenge. What helped:

1. Time blocking: I work on one client for minimum 90 minutes before switching. Context switching is mentally expensive - don’t do it every 30 minutes.

2. Client README: Every repo has a README with:

   • Account quirks like “They use personal card for business sometimes”
   • Reconciliation day - 15th of month for Client A, 1st for Client B
   • Special rules like “Don’t categorize Stripe fees separately, client wants net revenue”

3. Batch similar work: Monday = all bank reconciliations. Tuesday = all receipt processing. Wednesday = all reporting. This reduces cognitive load.

4. Clear workspace: I close all Fava tabs, terminals, and editors before switching clients. Fresh start = fewer mistakes.

When to Automate

I started serious automation around 12 clients when manual work became unsustainable:

• Automated bank imports that run nightly
• Auto-categorization for recurring transactions
• Template-based monthly reports
• Git commit hooks to prevent common mistakes

Early mistakes I made:

1. Waited too long to split into separate repos - reorganizing 10 client repos was painful
2. Didn’t document client quirks - relied on memory which was a big mistake
3. Tried to over-standardize - some clients genuinely need custom structures
4. Didn’t invest in automation early enough

You’re at 6 clients and already thinking about this - that’s perfect timing. Split into separate repos now before you have to migrate 15 clients.

Hope this helps! Happy to share my template structure if you want specifics.

[helpful_veteran]

Sarah, I love that you’re asking this question at 6 clients! So many people wait until they’re drowning.

I don’t manage clients professionally - I track my own finances and rental properties - but I’ve helped a lot of folks in this community with multi-entity Beancount setups, and the patterns are similar.

What I’ve Learned from Helping Others

The number one mistake I see people make: premature optimization.

You have 6 clients. Bob has 20+. Claire works with practices at all scales. Their advice is gold - but don’t let “what works at 30 clients” paralyze you from starting at 6.

Start simple:

• Separate repos per client? Yes
• Basic shared importers? Yes
• Standard file naming? Yes
• Document the weird stuff? Yes

But don’t build:

• Complex automation frameworks? Not yet
• Elaborate reporting pipelines? Not yet
• Perfect industry templates? Not yet

Build those when you feel the pain of not having them. Right now, you’re feeling the pain of monorepo slowness and git confusion. So fix that. But don’t solve problems you don’t have yet.

The Beauty of Plain Text

One thing I love about Beancount for multi-client work: you can literally grep across all your clients.

With separate repos, you can still do:

cd ~/bookkeeping/clients
grep -r "Expenses:Advertising" */main.beancount

And see how you categorized advertising across all clients. This is harder with QuickBooks or proprietary formats.

Plain text = greppable, diffable, version-controllable. You picked the right tool.

Repository Organization That Scales

I’ve seen folks successfully use:

Option 1: Flat structure - Bob’s approach

~/bookkeeping/
├── _shared/
├── client-a/
├── client-b/
└── client-c/

Simple, works great for 5-30 clients.

Option 2: Grouped by industry

~/bookkeeping/
├── _shared/
├── restaurants/
│   ├── cafe-downtown/
│   └── restaurant-uptown/
├── retail/
│   ├── boutique-a/
│   └── shop-b/
└── consulting/
    └── firm-c/

Nice if you specialize in 2-3 industries.

Option 3: Grouped by engagement type

~/bookkeeping/
├── _shared/
├── monthly-clients/
├── quarterly-clients/
└── tax-only-clients/

Useful if your service tiers differ significantly.

All of these work. Pick one, stick with it for 6 months, adjust if it’s not working.

Start Simple, Iterate

Here’s what I’d do if I were you:

This weekend:

1. Create ~/bookkeeping/_shared/ for importers and templates
2. Convert your monorepo into 6 separate repos
3. Write a 1-page README for each client with their quirks

This month:
4. Document your process - doesn’t have to be perfect
5. Set up basic git hooks to prevent accidental commits to wrong repo

This quarter:
6. Build your first industry template based on real client needs
7. Automate one repetitive task

Next quarter:
8. Review what’s working, what’s not
9. Adjust

You’ll figure out what you need as you grow. Don’t over-engineer at 6 clients.

Why You’re Already Ahead

You wrote:

“I now use YYYY-MM-DD-description for all files”
“Each client folder has a README with account structures and quirks”
“Writing good Git commit messages”

This is excellent. You’re building good habits. Most people never do this.

The fact that you’re thinking about systems at 6 clients means you’ll probably handle 30 clients better than most people handle 10.

Keep asking questions. Document what works. Don’t be afraid to reorganize when you hit real pain points - not imagined future problems.

You’ve got this.

[accountant_alice]

Sarah, this is such a thoughtful question - you’re ahead of the curve by thinking about systems at 6 clients instead of waiting until 20!

Bob gave excellent tactical advice. I want to add some thoughts from my CPA practice perspective.

The Real Cost of Context Switching

Research shows context switching can cost 40% of productive time, and you’re already feeling this. But it’s not just about time - it’s about mental energy.

The goal isn’t to eliminate context switching - that’s impossible - but to make it intentional rather than reactive.

Client Segmentation Approach

Instead of treating all 6 clients the same, I recommend segmenting by service level:

Tier 1 - High-touch clients - 20% of clients, 50% of revenue:

• Custom everything
• Weekly check-ins
• Real-time reporting
• These clients justify custom workflows

Tier 2 - Standard clients - 60% of clients, 40% of revenue:

• Standardized templates
• Monthly reconciliation
• Quarterly reviews
• These fit the template approach Bob described

Tier 3 - Low-touch clients - 20% of clients, 10% of revenue:

• Maximum automation
• Minimal customization
• Should take under 2 hours per month each

This segmentation helps you decide: “Does this client justify a custom workflow, or should I nudge them toward my standard process?”

The Automation Investment Timeline

Based on what I’ve seen across the profession:

1-10 clients: Manual workflows are fine. Focus on building consistent habits.

10-20 clients: Invest in automation for repeated tasks. Templates, importers, standard reports.

20-30 clients: You need workflow automation or an assistant. Can’t scale further without help.

30-50 clients: Requires serious infrastructure - automated data collection, batch processing, possibly offshore support.

You’re at 6, so you’re in the “build consistent habits” phase. The separate-repo-per-client approach Bob described is exactly right for this stage.

What I Wish I’d Known Earlier

When I had 5-10 clients, I wish I’d known:

1. Client onboarding is your leverage point: A good onboarding process with templates, clear expectations, and automated data collection saves 20+ hours per client over a year.

2. Documentation prevents burnout: When you’re tired or interrupted, documentation is your backup brain. README files, process checklists, quirk lists - all worth it.

3. Not all clients are equal: Some are a joy to work with and pay well. Others are exhausting. As you grow, you can be selective - but only if you track which clients energize vs drain you.

4. Better systems deserve better pricing: As you build templates and automation, you’re delivering better service more efficiently. That’s worth more, not less.

Repository Structure Recommendation

For your current stage - 6 clients growing to 10-15:

• Separate git repos per client using Bob’s approach
• Shared _templates/ and _shared/ directory
• Industry-specific starter templates
• Standard naming conventions across all clients
• Crucially: Document your standards in a BOOKKEEPING_PLAYBOOK.md in _shared/

This playbook becomes your operations manual. When you hire help later, it’s their training guide.

Time-Blocking by Work Type

I time-block by type of work, not by client:

Monday AM: All bank reconciliations for all clients
Monday PM: Receipt processing and categorization for all clients
Tuesday AM: Client-specific review - one at a time, 90-minute blocks
Wednesday AM: Reporting and client communication

This batching means I’m in “reconciliation mode” for 3 hours straight rather than jumping between clients every hour. Much less cognitive load.

Your Next Steps

At 6 clients, I’d recommend:

1. Split into separate repos this month before it gets harder
2. Create your first 2-3 industry templates
3. Document your current process even if it’s rough
4. Set up basic automation for bank imports
5. Block time by work type, not by client

You’re building a sustainable practice, not just serving 6 clients. That mindset will serve you well.

Feel free to reach out if questions come up as you scale!