I’ve been running a bookkeeping practice for 10 years now, and I want to share something that completely changed my business: the fractional accounting model combined with Beancount’s plain-text approach. ## My Journey: From 3 Clients to 20+ When I started Martinez Bookkeeping Services, I worked with 2-3 small businesses full-time. Traditional model: dive deep into each client, know every transaction, be available 24/7. The problem? Revenue ceiling and constant context switching between QuickBooks Online logins. Then I discovered two things: (1) the fractional accounting revolution happening industry-wide, and (2) Beancount’s git-based workflow that actually scales for multi-client practices. ## The Fractional Accounting Revolution The numbers are real, folks. According to CPA Practice Advisor, fractional accounting is growing 15-20% annually. A single practitioner can now serve 3-5 clients at $6,000-$10,000 per client monthly. That’s $300K-$500K annual revenue potential—but only if you have systems that don’t break under the load. Small businesses WANT fractional. They need CPA-level expertise but can’t afford (or don’t need) a full-time controller. Enter people like us: serve 5-10 clients part-time instead of 1-2 full-time. But here’s the catch: QuickBooks × 20 doesn’t scale. Different interfaces, different shortcuts, different chart of accounts chaos, login fatigue. I needed something better. ## My Plain-Text Workflow Structure After two years of refinement, here’s what actually works: Multi-Repo Strategy: One git repository per client. Complete separation. No cross-contamination risk. Client A’s books live in client-a-books/, Client B in client-b-books/. Clean boundaries. Standardized Templates: I built a base chart of accounts for service businesses, retail, and restaurants. New client onboarding? Clone the template repo, customize account names, done. What used to take 8 hours now takes 2. Client Onboarding Checklist: - Week 1: Initial meeting, collect bank logins, entity documents - Week 2: Set up git repo from template, configure importers - Week 3: Historical data import, balance assertions, training call - Week 4: First month-end close together Naming Conventions: Every client follows the same structure: client-name-books/ ├── main.beancount ├── accounts.beancount ├── imports/ ├── documents/ └── reports/ Automation Boundaries: - Centralize: Bank importers, PDF parsers, common Python scripts (I maintain a shared beancount-tools repo) - Customize: Account structures, reports, client-specific rules ## Time-Blocking Saved My Sanity With 20 clients, context-switching kills productivity. Here’s my weekly structure: - Monday/Wednesday: Clients A-H (service businesses) - Tuesday/Thursday: Clients I-P (retail/restaurants) - Friday: Month-end closes, catchup, admin Git branch naming helps mental switching: client-a/march-2026, client-b/march-2026. When I checkout a branch, my brain knows which client I’m in. ## Challenges I’ve Solved Scope Creep: Learned this the hard way. Now I use fixed monthly engagement letters that clearly define: monthly reconciliation, one advisory call, quarterly reports, email support (2 business day response). Anything beyond that? Change order process. Cross-Contamination: Separate repos prevent accidentally committing Client A’s data to Client B’s repo. I’ve never had this happen with git, but had it happen twice with QuickBooks file mix-ups years ago. Efficiency via DRY Principle: My bank importers, PDF parsers, and common scripts live in a central repo. Each client repo includes this as a git submodule. Update the importer once, all 20 clients benefit. ## What I’m Curious About I know many of you are either running fractional practices or thinking about it. Some questions: 1. How do YOU structure multi-client Beancount workflows? Different from mine? 2. What breaks when you scale from 3 to 10 clients? I hit walls at 5 and 15 clients. 3. Standardization vs customization balance? How much do you templatize vs keep unique? 4. Multi-state sales tax tracking? Still figuring out elegant solutions here. The fractional model is the future of accounting. Plain-text + git gives us competitive advantages that QuickBooks firms simply can’t match. Let’s share what’s working. What’s your experience been?
Bob, this is excellent. Your multi-repo approach mirrors what I learned at Deloitte, except we had a whole infrastructure team managing it. The fact that you’ve built this solo for your practice is impressive. ## Validation from Big Four → Small Practice Experience I spent my first 5 years at a Big Four firm where standardization was gospel. Every client had the same workpaper structure, same review process, same everything. When I started Thompson & Associates, I initially thought, “Small practice = freedom from templates!” Wrong. Small practices need EVEN MORE standardization because we don’t have armies of staff to catch mistakes or redundant systems to provide backup. ## Legal & Compliance Considerations Since you’re asking about scaling, let me add the professional compliance perspective: Engagement Letters Are Non-Negotiable: Your scope definition is exactly right. I’ve seen CPAs get into E&O insurance nightmares because engagement letters said “bookkeeping services” without defining: frequency, deliverables, response times, or exclusions. My engagement letter for fractional Beancount work explicitly states: - Monthly reconciliation and balance assertions - One 30-minute advisory call per month (additional calls billed at $250/hour) - Quarterly management reports (P&L, balance sheet, cash flow) - Email support with 2 business day SLA - Explicitly EXCLUDES: tax preparation, audit representation, payroll processing, daily transaction support Professional Liability Insurance: My E&O carrier (CAMICO) actually LOVES that I have documented, standardized processes. During my last renewal, the underwriter asked about my quality control procedures. I showed them: git commit logs (audit trail), balance assertion history (error detection), templated engagement letters (scope clarity). Premium went DOWN. State Board Regulations: Depending on your state, there may be restrictions on serving too many clients simultaneously or requirements for peer review at certain client counts. In Illinois, I’m subject to peer review every 3 years. Beancount’s plain-text approach makes peer review SO much easier—reviewer can literally grep through my files. ## The Advisory Services Opportunity Here’s where fractional + Beancount becomes a revenue goldmine: Client Advisory Services (CAS). According to the 2024 AICPA CAS Benchmark Survey, CAS practices are growing at 15-17% annually. Clients don’t just want compliance—they want strategic guidance. With Beancount, I can run scenario analyses in MINUTES that would take hours in QuickBooks: - “What if we hire two more people?” - “Should we take this loan or bootstrap?” - “What’s our breakeven if material costs increase 15%?” Python + Beancount = instant scenario modeling. I charge 2-3x my hourly compliance rate for advisory work. Pricing Model: - Compliance (bookkeeping, reconciliation): $150-200/hour or $2,500/month fixed - Advisory (forecasting, scenario planning, KPI dashboards): $300-350/hour or $5,000-8,000/month retainer Fractional clients are PERFECT for advisory upsells because they already trust you with their books. ## Template Sharing Bob, I’ve built an engagement letter template specifically for fractional Beancount work. It defines scope, deliverables, exclusions, IP ownership (who owns the Beancount files?), and data security responsibilities. If there’s interest from the community, I’m happy to share a sanitized version. We should be helping each other build sustainable, compliant practices—not reinventing these documents from scratch. Question for you: How do you handle multi-state clients? I have three clients with nexus in 4+ states, and state-specific reporting is still my biggest Beancount challenge. Any clever solutions for sales tax tracking across jurisdictions?
Bob and Alice, I’m not a professional accountant (just a FIRE enthusiast who tracks everything obsessively), but I LOVE the data-driven approach here. Let me share some efficiency metrics from my own multi-account tracking setup—the principles scale to your multi-client scenarios. ## The Numbers Don’t Lie: Standardization ROI I track my own finances plus my parents’ finances, my sister’s small business books, and two rental properties. That’s effectively 5 “clients.” Here’s my before/after data: Before standardization (Year 1): - Time per month across all accounts: ~40 hours - Balance assertion failures: 8-12 per month - Late reconciliations: 30% of the time - Mental stress level: HIGH After templates + automation (Year 2): - Time per month: ~15 hours (62.5% reduction) - Balance assertion failures: 1-2 per month - Late reconciliations: 0% - Mental stress level: LOW The difference? Standardized importers, shared Python utilities, and consistent account structures. ## Technical Implementation Details Since you asked about structuring multi-client workflows, here’s my technical setup: Central “beancount-tools” Repository: beancount-tools/ ├── importers/ │ ├── chase_checking.py │ ├── amex_credit.py │ ├── schwab_investment.py │ └── generic_csv.py ├── plugins/ │ ├── categorization_hints.py │ └── duplicate_detection.py └── reports/ ├── cash_flow.py ├── net_worth.py └── tax_summary.py Per-Client Repos Use Git Submodules: Each client repo includes beancount-tools as a submodule: client-a-books/ ├── beancount-tools/ (submodule) ├── main.beancount ├── accounts.beancount └── Makefile Makefile Standardization: Every client has the same Makefile commands: make import # Run importers make check # Balance assertions make reports # Generate monthly reports make close # Month-end close workflow This means muscle memory works across ALL clients. I don’t have to remember “Client A uses this script, Client B uses that one.” ## The Automation Hierarchy That Actually Works Alice mentioned advisory vs compliance. I think about automation the same way: Always Automate (100% trust): - Bank CSV imports (deterministic, well-structured) - PDF parsing for invoices (OCR + validation) - Transaction matching (duplicates, transfers) Automate with Review (AI-assisted, human-verified): - Transaction categorization (I use a simple ML model trained on historical data, but I ALWAYS review suggestions) - Payee normalization (“Amazon.com Identify an Amazon Charge - Amazon Customer Service” → “Amazon”) - Anomaly detection (flag transactions >2 std deviations from category average) Never Automate (requires judgment): - Client advisory decisions - Tax strategy conversations - Unusual transaction investigation - First-time account reconciliation The key insight: automation isn’t binary. It’s a spectrum from “full automation” to “automation-assisted” to “fully manual.” ## Metrics That Matter for Scaling If you’re scaling from 3 to 20 clients, track these KPIs: 1. Time per client per month (Target: <3 hours for routine clients) 2. Error rate (Balance assertion failures / total assertions) 3. Client satisfaction (NPS surveys quarterly) 4. Revenue per hour (Total revenue / total time spent) 5. Automation coverage (% of transactions auto-categorized correctly) I built a simple Python dashboard that pulls these metrics from my Beancount files and git logs. Seeing the numbers improve month-over-month is incredibly motivating. Question for Bob: What’s your time-per-client benchmark? You mentioned 20 clients—how many hours per week does that actually consume? I’m curious about the real-world capacity limits. For Alice: Do you track ROI on advisory services separately? I’d love to see data on “hours spent on advisory” vs “incremental revenue from advisory” to understand the margin difference you mentioned.
This thread is fantastic. Bob, your journey from chaos to structure is exactly what many people need to hear. Fred’s metrics are inspiring. Alice’s compliance perspective is critical. Let me add some hard-earned lessons from my own scaling experience. ## My Scaling Journey (And Almost Burning Out) I’m not a professional accountant—I manage my own finances, two rental properties, and help 8 family members/friends with their Beancount setups (all pro bono, because I’m apparently a glutton for punishment). Here’s the embarrassing truth: I almost burned out when I hit client #5. Why? Because I tried to over-engineer BEFORE I had enough data to know what needed engineering. I built elaborate templates, created custom plugins, wrote documentation for workflows I’d never actually tested at scale. Premature optimization is real, folks. ## The “Start Simple” Philosophy I Wish I’d Followed Lesson 1: Don’t Build Templates Until You Have 3+ Clients When I started helping people, I immediately created “the perfect Beancount starter template.” Spent 40 hours on it. Know what happened? Every single person needed different customizations. My template was useless. Better approach (which Bob discovered naturally): 1. Set up your first 3 clients manually 2. Notice what’s identical vs what’s unique 3. Extract commonalities into templates 4. Keep iterating Let real patterns emerge. Don’t invent them. Lesson 2: Copy-Paste is OK Initially Fred’s git submodule approach is elegant, but you don’t need that until you’re managing 5+ entities. For your first few clients, it’s TOTALLY FINE to copy-paste your importer scripts between repos. Once you’ve copy-pasted the same fix 3 times, THEN abstract it into a shared module. I see newcomers stress about “doing it the right way” from day one. There is no right way. There’s only “what works for you today” and “what needs to scale tomorrow.” ## Client Psychology: The Invisible Standardization Bob, I love your template approach. But here’s a client management insight: clients often WANT to feel special. What I learned: Standardize invisibly, customize visibly. - Backend (invisible to clients): Same importers, same scripts, same Makefile commands - Frontend (visible to clients): Custom account names, industry-specific reports, personalized dashboards Example: I have a rental property template. But each property owner gets account names like “Income:RentalProperty:123-Main-Street” (not “Income:Rental:Property1”). They see THEIR address. They feel custom. The workflow is templated. This psychological distinction matters. Clients are paying for personalized service, even if 80% of the infrastructure is standardized. ## Red Flags: When to Fire a Client Nobody talks about this, but fractional work has boundaries. Here are my “fire the client” red flags: 1. Texts at 9 PM expecting immediate responses: Your fractional service hours are defined in the engagement letter. Enforce them. 2. “Can you just look at this quickly?” = scope creep’s favorite phrase. Every “quick question” is billable or leads to burnout. 3. Clients who don’t respect your fractional boundaries: If they treat you like full-time staff, they should pay full-time rates. 4. Chronic late document providers: If they don’t send you bank statements until day 28 of the month, they’re not respecting your close timeline. I fired two “clients” (family members, so extra awkward) last year because they violated boundaries repeatedly. My mental health improved immediately. Your capacity for 20 clients depends on having 20 GOOD clients. ## Encouragement for Anyone Thinking About This Bob’s post shows that fractional + Beancount is not just viable—it’s a competitive ADVANTAGE. The accounting industry is shifting toward fractional models whether we like it or not. Small businesses can’t afford full-time controllers but desperately need financial guidance. That’s YOUR opportunity. Plain text + git gives you: - Auditability: Every change tracked - Portability: No vendor lock-in - Collaboration: Real version control - Scalability: Templates and automation QuickBooks firms can’t match this. You’re ahead of the curve. To newcomers: Start with one client. Get good at their workflow. Add client #2. Notice what’s different. By client #3, you’ll see patterns. Then templatize. To Bob: Seriously impressive that you’re at 20 clients. That’s inspiration, not aspiration—it’s achievable with systems. Thank you for sharing. Question: What do you do when a client’s industry is completely new to you? Do you turn them down, or do you charge for the learning curve? I’ve struggled with “I’ve never done nonprofit accounting before” situations.
Bob, Alice, Fred, Mike—this is the most valuable thread I’ve read in months. As a tax-focused practitioner, I want to add the seasonal perspective on fractional work. ## Fractional Model + Tax Season = Perfect Match I run a fractional practice that’s heavily weighted toward tax prep and planning. My client load fluctuates: - Jan-Apr (tax season): 15-20 active clients, 60+ hours/week - May-Dec (advisory season): 5-8 ongoing clients, 20-30 hours/week Fractional work is PERFECT for this seasonality because clients understand they’re getting my focused attention during their critical periods, not year-round overhead. ## Industry-Specific Templates Are Your Competitive Edge Bob mentioned service, retail, and restaurant templates. Let me add the tax practitioner’s perspective on industry specialization: Real Estate Investors (Schedule E): - Account structure for multiple properties - Depreciation tracking per property - Passive loss limitation calculations - 1031 exchange tracking E-Commerce Sellers (COGS + Sales Tax Nightmare): - Inventory valuation (FIFO, specific ID, average cost) - Multi-state sales tax nexus tracking - Amazon/Shopify fee categorization - Returns and allowances handling Freelancers/Consultants (Schedule C + QBI): - Business expense categorization (home office, mileage, equipment) - Qualified Business Income deduction tracking - Estimated tax payment scheduling - Self-employment tax calculations Each industry gets a base template. New client intake: I ask 5 questions (industry, entity type, states of operation, revenue size, special circumstances), then I select the appropriate template. What used to take me 6-8 hours of account setup now takes 2 hours. ## Onboarding Efficiency That Scales My onboarding process (refined over 3 tax seasons): Week 1: Client Questionnaire - Entity type, EIN, state registrations - Bank accounts and credit cards - Industry-specific questions (rental properties? Inventory? Contractors?) - Historical data availability Week 2: Template Selection + Setup - Clone appropriate industry template - Customize account names - Configure importers for their banks - Set up git repo (I host private GitLab for clients who don’t want to manage it) Week 3: Data Import + Training - Import 12 months of historical transactions - Balance assertions for all accounts - 1-hour Zoom training: “Here’s Fava, here’s how to review transactions” - Record training for future reference Week 4: First Close Together - Month-end close while client watches - Review process together - Answer questions - Set ongoing schedule Total time investment: 8-10 hours for complex clients, 4-6 hours for straightforward ones. Compare to QuickBooks setup: 12-16 hours minimum, with more ongoing support needed. ## Seasonal Workflow: Tax Season vs Advisory Season Jan-Apr (Tax Season Focus): - Heavy transaction processing (prior year cleanup) - Tax return preparation - Extension filing for complex returns - Light bookkeeping for new transactions May-Dec (Advisory + Planning Focus): - Quarterly estimated tax calculations - Tax planning calls (“Should you buy equipment before year-end?”) - Entity structure optimization - Retirement contribution planning - Scenario modeling for major decisions Fractional model allows this flexibility. Traditional CPA firms struggle with utilization gaps between tax seasons. I use May-Dec for advisory work that’s actually MORE profitable per hour than compliance. ## Multi-State Sales Tax: Bob’s Question You asked about multi-state clients. Here’s my approach: Account Structure: Liabilities:SalesTax:California Liabilities:SalesTax:Texas Liabilities:SalesTax:NewYork Expenses:SalesTax:California (for exempt/excluded sales tracking) Transaction Metadata: I use transaction tags for nexus tracking: 2026-03-01 * "Widget Sale" #california-nexus Income:Sales:California -500.00 USD Liabilities:SalesTax:California -41.25 USD ; 8.25% rate Assets:Checking 541.25 USD Quarterly Reports: Custom Beancount query extracts sales by state, calculates tax collected, generates filing worksheets. Not automated (states have too many exceptions), but templated so each quarter is consistent. Is it perfect? No. Does it beat multi-state sales tax plugins for QuickBooks? Absolutely. ## Questions for Bob 1. Multi-state clients: How are you handling sales tax tracking? Any clever Beancount queries or scripts? 2. Industry templates: Do you charge more for industries you’re less familiar with (to account for learning curve), or do you turn down clients outside your expertise areas? 3. Tax season surge: With 20 clients, how do you handle tax season when everyone needs attention simultaneously? For the Community: Anyone else running fractional practices with seasonal fluctuations? How do you manage capacity planning and cash flow between busy and quiet periods? This thread is gold. Thank you all for sharing so openly.