Git-Based Financial Collaboration: What Software Engineers Got Right

Git-Based Financial Collaboration: What Software Engineers Got Right

About six months ago, I was explaining my Beancount workflow to a colleague who’s a senior backend engineer. When I mentioned I track everything in plain text files, he immediately asked: “Are you using Git?” I wasn’t. That conversation changed everything.

The Aha Moment

Software engineers have been collaborating on code for decades using version control systems like Git. They’ve solved problems that accountants and bookkeepers still struggle with daily:

  • “Who changed this and when?”
  • “Can we undo that mistake from last month?”
  • “How do we review changes before they go live?”
  • “What did our system look like exactly one year ago?”

It turns out these aren’t just software problems—they’re financial tracking problems too.

What Git Brings to Beancount

After six months of treating my financial data like source code, here’s what I’ve learned:

1. Complete Audit Trail (Git Log & Blame)

Every single change is tracked automatically. Added a transaction? Git knows. Fixed a typo in an account name? Git knows. Deleted something by accident? Git can recover it.

The git log command shows me every modification I’ve ever made:

commit a3f8d92
Author: finance_fred
Date: Tue Mar 11 2026
  
  Add grocery receipt - Trader Joe's $127.48

And git blame answers “who entered this transaction?” instantly—critical during tax season when I’m questioning a categorization from eight months ago.

2. Collaboration via Pull Requests

This is where it gets really interesting. In software development, engineers don’t push code directly to production. They open a “pull request”—a proposal that others review before it’s accepted.

I now use the same workflow for my finances. When I batch-import bank statements, I don’t commit directly to my main branch. I create a pull request, review the changes in GitHub’s diff view, and only then merge. It’s like having a second set of eyes on your books, even if that second set is your future self.

For teams (like an accountant + client, or family finances), this is transformative. One person proposes transactions, another reviews and approves. Built-in peer review for bookkeeping.

3. Branch Protection Rules

Git lets you set rules like “require approval from one other person before merging” or “must pass automated tests before accepting changes.” For regulated industries or businesses that need dual control, this is exactly what compliance officers dream about.

4. Balance Assertions as Continuous Testing

Software engineers write tests to verify their code works correctly. Beancount’s balance assertions do the same thing for finances:

2026-03-01 balance Assets:Checking  5,432.18 USD

If my transactions don’t add up to that exact balance, Beancount throws an error—just like a failing unit test. When I run bean-check (ideally in a pre-commit Git hook), I know immediately if something’s wrong. No more discovering discrepancies months later during reconciliation.

5. Transparency & “Showing Your Work”

Remember math class when teachers wanted you to show your work? Git does that automatically. Every change has context:

  • What changed (the diff)
  • Who changed it (author)
  • When (timestamp)
  • Why (commit message)

This transparency is powerful. For businesses, it means auditors can trace every transaction’s lifecycle. For personal finance, it means understanding how you arrived at your current net worth, not just the final number.

A Real-World Example: Monthly Close

Here’s my current workflow for month-end:

  1. Branch: Create march-2026-close branch
  2. Import: Add all bank/credit card transactions for the month
  3. Review: Use git diff main to see every new transaction
  4. Assertions: Add balance assertions for end-of-month statements
  5. Test: Run bean-check to verify everything balances
  6. Pull Request: Open PR from march-2026-closemain
  7. Review: Look at GitHub’s side-by-side diff, check categorizations
  8. Merge: Accept PR, monthly close is done
  9. Tag: Create git tag 2026-03 for this month’s snapshot

If I ever need to see my financial state from exactly March 2026, I just check out that tag. Time machine for finances.

Compared to Traditional Accounting Software

QuickBooks and similar platforms have “audit logs,” but they’re limited:

  • Can’t easily see side-by-side diffs of changes
  • No branching/experimentation without affecting production data
  • Manual “version control” through backups with timestamps
  • Can’t collaborate via review workflows (just shared access with permissions)
  • Reverting changes is manual and error-prone

Git gives you all of this for free, because plain text + version control is a solved problem in software engineering.

Getting Started (Technical Walkthrough)

For Beancount users new to Git:

  1. Initialize: git init in your Beancount directory
  2. First commit: git add . then git commit -m "Initial Beancount ledger"
  3. Daily commits: After adding transactions, git commit -m "Add groceries, gas, utilities"
  4. View history: git log --oneline shows your financial history
  5. See changes: git diff shows uncommitted changes
  6. Undo mistakes: git checkout -- file.beancount discards uncommitted changes

For collaboration, push to GitHub (private repository!) and use pull requests.

The Numbers Don’t Lie

Since adopting Git:

  • 40% faster monthly close (automated checks, clear review process)
  • Zero reconciliation errors (balance assertions catch mistakes immediately)
  • 100% audit trail (every change logged automatically)
  • Unlimited experimentation (branches let me test account restructuring without risk)

The Bottom Line

Software engineers figured out collaborative, transparent, auditable data management decades ago. The tools they built (Git, version control, code review) work perfectly for financial data—especially when your financial data is plain text.

If you’re using Beancount and not using Git, you’re missing out on one of the most powerful aspects of the plain-text accounting workflow.

Who else is treating their finances like source code? What’s your Git workflow? Any tips for advanced users or folks just getting started?


Tracking every dollar toward FI/RE in Seattle. Beancount + Git + Python automation enthusiast. Happy to share workflows and learn from the community.

This is EXACTLY why Beancount clicked for me as a DevOps engineer! When I first heard about “plain text accounting,” I was skeptical—it sounded like regression back to the 1980s. But then I realized: we already solved this problem in software development.

The Git Connection Made Everything Click

I’ve been using Git professionally for 5 years. The muscle memory is already there:

  • Making changes? → git diff to review
  • Committing work? → Write a clear commit message
  • Need to undo? → git revert or git reset
  • Collaborating? → Pull requests

Applying those exact same workflows to my personal finances felt natural. It’s like speaking a language I already know fluently.

My Real-World Usage

I’m currently using Git branches to experiment with different account structures. Right now I have:

  • main - my production financial data
  • experiment/budget-categories - testing a new expense categorization scheme
  • experiment/investment-tracking - trying different ways to model my portfolio

On the experiment branches, I can restructure everything, run reports, see how it looks—without touching my actual books. If I like it, I merge. If not, I delete the branch. Zero risk experimentation.

Compare that to my old spreadsheet workflow: Budget_v2_FINAL_REALLY_FINAL_USE_THIS_ONE.xlsx. I’m sure nobody here has ever done that… right? :sweat_smile:

My Burning Question: Merge Conflicts?

One thing I’m curious about: How do you handle merge conflicts when multiple people edit the same Beancount file?

In my day job, merge conflicts happen when two developers edit the same lines of code. With Beancount, if my partner and I both add transactions to the same date range, does Git freak out?

I’m currently solo on my finances, so I haven’t hit this yet. But I’m thinking about setting up a shared repo with my partner for household expenses. Anyone doing this successfully?

Commit Message Best Practices?

For code, we have conventions like:

feat: Add user authentication
fix: Resolve memory leak in parser
chore: Update dependencies

What do people use for Beancount commits? I’ve been doing:

Add transactions: groceries, gas, utilities (2026-03-10 to 2026-03-12)
Balance assertion: checking account (2026-03-13)
Fix: Correct categorization of Amazon purchase (should be Books not General)

Is there a better pattern? I feel like my commit messages are too verbose.

The Spreadsheet Comparison

You mentioned Budget_v2_FINAL_REALLY_FINAL.xlsx in spirit, and oh man, I lived that nightmare for three years:

Old workflow:

  • Make changes in Excel
  • Save as new filename with version number or date
  • Forget which version is current
  • Open four versions to find the “right” data
  • Accidentally reference old version in a formula
  • Cry

Git workflow:

  • Make changes
  • git commit -m "Add March rent payment"
  • Done. One file. Complete history. Time machine.

The difference is night and day.

Using git diff for Monthly Review

One workflow I’ve found incredibly useful: at the end of each month, I run:

git diff 2026-02..2026-03

This shows me every single transaction I added during March, side-by-side with February’s state. It’s like a built-in month-over-month comparison tool.

I can quickly scan:

  • Did I forget to record anything?
  • Are there any duplicates?
  • Do the categories look right?

It’s faster than any report I could generate in Excel or QuickBooks.

To Anyone on the Fence

If you’re a developer or DevOps person who’s used to Git, Beancount + Git is a superpower. You’re not learning new concepts—you’re applying skills you already have to a new domain.

And if you’re an accountant or bookkeeper who’s never used Git? I won’t lie, there’s a learning curve. But the investment pays off immediately in audit trails, collaboration, and peace of mind.


DevOps engineer by day, personal finance enthusiast by night. Currently migrating from spreadsheet chaos to Beancount serenity. Portland, OR.

Been using Git + Beancount for 4 years now. I can’t imagine going back to any other workflow. This thread is bringing back memories of my own migration journey—and answering some great questions!

My Migration Story: From GnuCash Skeptic to Git Convert

I came from GnuCash, which is a solid traditional accounting app. When a friend suggested plain text + Git, I thought they were joking. “You want me to track finances in… text files? With a command-line tool from 1995?”

But I gave it a shot during tax season 2022, and within a month I was completely converted. Here’s why:

GnuCash: If I made a mistake in January and discovered it in March, I had to manually trace back through the GUI, find the transaction, fix it, and hope I didn’t miss anything related.

Beancount + Git: git log --grep="Verizon" shows me every transaction mentioning Verizon. git blame expenses.beancount shows who entered what. git revert a3f8d92 undoes a specific change cleanly.

The transparency and control are addictive once you experience them.

Practical Workflow Tips (From 4 Years of Experience)

Here’s what I’ve learned works well:

Daily Commits

Keep them simple and consistent:

git commit -m "Add groceries receipt - Whole Foods"
git commit -m "Pay electric bill - March 2026"
git commit -m "Record freelance payment from Client ABC"

Don’t overthink it. The commit message is searchable context. Future you will thank present you.

Monthly Reconciliation Tags

At month-end, after I’ve reconciled everything and verified balance assertions pass, I tag the commit:

git tag 2026-03-reconciled
git push origin 2026-03-reconciled

This creates a permanent snapshot of my books for that month. If I ever need to see my exact financial state from March 2026 (for taxes, audits, historical analysis), I just:

git checkout 2026-03-reconciled

Time machine.

Annual Branches for Tax Year Rollover

At the start of each year, I create a branch:

git checkout -b tax-year-2026

Throughout the year, I work on that branch. At year-end, I merge it back to main and create a tag: 2026-tax-year-final.

This gives me a clean separation of tax years, which is helpful when the IRS comes asking about 2023 while I’m focused on 2026.

Pre-Commit Hooks: Automated Testing

This is where it gets powerful. I have a .git/hooks/pre-commit script that runs bean-check automatically:

#!/bin/bash
bean-check main.beancount
if [ $? -ne 0 ]; then
  echo "❌ Balance assertions failed. Fix errors before committing."
  exit 1
fi

Now I cannot commit if my books don’t balance. It’s like continuous integration for finances—every commit is verified to be correct.

Addressing the Merge Conflict Question

@finance_fred asked about merge conflicts with multiple people editing the same file. Great question!

Good news: Merge conflicts are rare with Beancount because transactions are mostly append-only.

If you and your partner both add transactions to the same file on the same day, Git will usually auto-merge them successfully because you’re adding different lines (different transactions).

Conflicts happen when:

  • Both people edit the exact same transaction (same line)
  • Both people change an account name or opening balance
  • Both people add balance assertions for the same account on the same date

My workflow with my spouse:

  • We each have our own branch: mike-transactions and spouse-transactions
  • We add our own transactions throughout the week
  • On Sundays, we merge both branches into main and review together
  • Conflicts are rare (maybe 1-2 times per year), and when they happen, they’re easy to resolve manually

Pro tip: Use separate files for separate people’s transactions (mike.beancount and spouse.beancount), then include them both in your main file:

include "mike.beancount"
include "spouse.beancount"

This eliminates merge conflicts entirely because you’re never editing the same file.

Start Simple, Don’t Over-Engineer

One mistake I see new Beancount + Git users make: over-engineering the workflow from day one.

They set up elaborate branching strategies, complex commit message conventions, automated CI/CD pipelines… and then they burn out before they even have a month of data.

My advice: Start with just this:

  1. git init in your Beancount directory
  2. Add transactions
  3. git commit -m "Brief description"
  4. Repeat daily

That’s it. The value is immediate: version control, undo capability, searchable history.

After a few months, when you’re comfortable, then add:

  • Monthly tags
  • Balance assertion checks in pre-commit hooks
  • Collaboration workflows
  • Branch strategies

Build complexity gradually as you discover what you actually need.

The Balance Assertions = Continuous Testing Analogy

This is such a powerful mental model. In software, we write tests to verify code behavior:

assert add(2, 2) == 4

In Beancount, we write balance assertions to verify financial state:

2026-03-14 balance Assets:Checking 3,247.91 USD

If the assertion fails, something is wrong with my data entry—just like a failing test means something is wrong with my code.

I add balance assertions:

  • Daily for high-activity accounts (checking)
  • Weekly for credit cards
  • Monthly for everything else (savings, investments, etc.)

This catches errors immediately rather than discovering them months later during tax prep.

Real-World Impact: The Numbers

Since adopting Git + Beancount in 2022:

  • Zero data loss incidents (compared to 3 corrupted GnuCash files in prior years)
  • 100% audit trail for every transaction (IRS audit in 2024 was smooth)
  • 50% faster monthly close (automated checks, no manual reconciliation hunting)
  • Collaboration with spouse went from “email spreadsheets” to “pull requests” (marriage saved? :grinning_face_with_smiling_eyes:)

To Anyone Hesitant About the Learning Curve

I get it. Git can feel intimidating if you’re not a developer. The command line is scary. Plain text seems primitive.

But here’s the thing: you don’t need to master Git to get value from it. Even if you only use:

  • git add .
  • git commit -m "message"
  • git log

…you’re getting 80% of the benefit. The rest is gravy.

And there are GUI tools (GitKraken, GitHub Desktop, SourceTree) if the command line isn’t your thing.

The investment pays off immediately. The first time you accidentally delete a transaction and recover it with git checkout, you’ll be hooked.


Using Beancount + Git for personal and rental property finances since 2022. Happy to answer questions! San Francisco, CA.

From a CPA perspective, the Git audit trail is superior to traditional accounting software in every measurable way. This isn’t just convenient—it’s a compliance game-changer.

The Professional Accountant’s Audit Trail Requirements

As a CPA, I’m bound by professional standards and regulatory requirements. When I maintain client books or my own firm’s financials, I need to demonstrate:

  1. Transaction Integrity: Proof that entries haven’t been tampered with
  2. Complete History: Every change, who made it, when, and why
  3. Revertibility: Ability to reconstruct books as they existed at any historical point
  4. Dual Control: For certain regulated industries, evidence of review/approval
  5. Auditability: Clear trail for IRS, external auditors, or compliance officers

Traditional accounting software claims to provide this. Git actually delivers it.

Real Client Example: IRS Audit Success Story

Last year, one of my clients faced an IRS audit for tax year 2023. The agent requested documentation showing the state of their books on specific dates throughout the year (quarterly snapshots).

With QuickBooks (previous client workflow):

  • We had quarterly backup files saved manually
  • Agent asked “how do I know these weren’t modified after the fact?”
  • We had to provide server logs, timestamps, certifications
  • Time-consuming and stressful

With Beancount + Git (current workflow):

  • git checkout 2023-Q1-final → exact state from March 31, 2023
  • git log showed commit history with cryptographic hashes proving no tampering
  • Agent was satisfied within minutes
  • We looked incredibly professional and organized

The IRS agent actually said: “This is the cleanest audit trail I’ve seen from a small business. Most people can’t even find their receipts.”

Compliance Advantages of Git Over QuickBooks

1. Immutable Audit Trail

Git commits are cryptographically hashed. If you change anything in historical data, the hash changes—making tampering immediately obvious.

QuickBooks lets you edit historical transactions and marks them as “modified,” but there’s no cryptographic proof of integrity.

2. Complete Transaction Lifecycle

With git log and git blame, I can show:

  • Original entry: “Added invoice #1234 - $5,000”
  • First correction: “Fixed invoice #1234 amount - should be $5,500”
  • Categorization change: “Recategorized invoice #1234 to Consulting Revenue”

Every step, with timestamp and author. This is exactly what auditors want to see.

3. Branch Protection for Dual Control

For clients in regulated industries (finance, healthcare, government contractors), I set up branch protection rules:

main branch: Requires approval from 1 other person

This enforces segregation of duties. Bookkeeper enters transactions → Controller reviews and approves → Merges to main.

We can prove to auditors that no single person had unilateral control over financial records. This is a compliance requirement in many industries, and Git implements it natively.

Balance Assertions: The Accountant’s Best Friend

The software engineering analogy to “unit tests” is spot-on. Balance assertions prevent the most common bookkeeping errors:

Common Mistakes Balance Assertions Catch:

  • Forgot to record a deposit: Bank statement shows $10K balance, Beancount shows $8K → ERROR
  • Entered duplicate expense: Beancount balance is $500 less than it should be → ERROR
  • Miscategorized transfer as income: Checking balance assertion fails → ERROR
  • Typo in transaction amount: $1,250 entered as $12,500 → ERROR (if assertion runs before month-end)

I require all clients to include balance assertions with every bank statement they process. It’s like a monthly audit checkpoint.

Professional Tip: Tag Your Reconciliations

After month-end reconciliation, I don’t just commit—I tag:

git tag 2026-03-reconciled-certified -m "March 2026 reconciliation complete. All balance assertions pass. Reviewed by Alice Thompson, CPA"

This creates a certified snapshot that I can reference for:

  • Tax returns
  • Financial statement preparation
  • Audit responses
  • Variance analysis (“What changed between March and April?”)

Git Tags as Financial Statement Versions

In traditional accounting, we manually version financial statements:

  • 2025_BalanceSheet_Draft1.pdf
  • 2025_BalanceSheet_Draft2_RevByPartner.pdf
  • 2025_BalanceSheet_FINAL.pdf
  • 2025_BalanceSheet_FINAL_REVISED.pdf (we’ve all been there…)

With Git:

git tag 2025-financials-draft1
git tag 2025-financials-draft2  
git tag 2025-financials-FINAL

Each tag points to the exact ledger state that generated those financials. No ambiguity, no lost versions, no “wait which file did we send to the bank?”

Security & Privacy: Keeping Client Data Safe

One concern I hear from CPAs: “Isn’t putting financial data on GitHub risky?”

Use PRIVATE repositories. GitHub/GitLab have enterprise security:

  • Encrypted at rest and in transit
  • Two-factor authentication required
  • Audit logs of who accessed what
  • SOC 2 compliance
  • GDPR-compliant data handling

For ultra-sensitive clients, I use:

  • Self-hosted GitLab (on our own encrypted servers)
  • Git repos on encrypted local drives only (no remote)

The key insight: Local plain text + Git is MORE secure than cloud accounting SaaS because:

  • No vendor has access to your data
  • No risk of vendor data breach affecting hundreds of clients
  • You control encryption, access, backups
  • Smaller attack surface (local files vs. internet-facing database)

Addressing the Learning Curve: Is It Worth It for CPAs?

I won’t sugarcoat it: There’s a learning curve. Git wasn’t designed for accountants, and the terminology can be confusing initially.

But here’s the ROI:

  • Month-end close time: Reduced 40% (automated checks, no manual reconciliation)
  • Client communication: Reduced 50% (they can see changes via pull requests)
  • Audit prep time: Reduced 70% (instant historical snapshots)
  • Data loss incidents: Zero (compared to multiple QuickBooks corruption incidents)

For a CPA billing $200-400/hour, saving 10 hours per month = $2K-4K/month in recovered billable time. Learning Git takes maybe 20 hours total. The break-even is immediate.

The Regulatory Landscape is Shifting

AICPA and other accounting bodies are starting to recognize version-controlled financial data as a best practice, especially for:

  • SOX compliance (Sarbanes-Oxley)
  • GDPR data lineage requirements
  • State data privacy laws (CCPA in California, etc.)

Git natively provides:

  • Data lineage (who changed what when)
  • Right to deletion (remove PII from history if required)
  • Export capability (data portability requirements)
  • Retention policies (tags for required retention periods)

I genuinely believe that within 5 years, Git-based accounting will be standard practice for any CPA serving clients in regulated industries.

My Workflow for Client Collaboration

Here’s how I work with clients using Beancount + Git:

  1. Initial Setup: Create private GitHub repo for client
  2. Grant Access: Client gets read-only access (can see, can’t change)
  3. My Work: I enter transactions on a branch (alice-entries)
  4. Pull Request: I open PR with summary: “March 2026 bookkeeping - 45 transactions”
  5. Client Review: Client reviews PR, asks questions, approves
  6. Merge: I merge to main, creating permanent record
  7. Monthly Report: Auto-generate PDF from Beancount queries, email to client

Clients LOVE the transparency. They can see exactly what I’m doing, line by line. No black box. No “trust me, your books are correct.”

Call to Action for Fellow CPAs

If you’re a CPA still using traditional software, I challenge you to try this workflow for just one client. Pick a small, tech-savvy client who won’t panic at the idea of “plain text.”

Track your time for 3 months:

  • How long does month-end take?
  • How many client questions do you field?
  • How much time do you spend on reconciliation?

Then compare to your traditional workflow. I’m confident you’ll see measurable improvements.

And when the next audit comes around, you’ll feel like a superhero when you git checkout 2023-Q2 and hand the auditor a perfect snapshot in 30 seconds.


CPA with 15 years experience. Converted all 12 of my firm’s clients to Beancount + Git workflows. Zero regrets. Chicago, IL.

As a bookkeeper serving 20+ small business clients, I use Git collaboration workflows with 8 of them now. It’s transformed how I work with clients—more transparency, less back-and-forth, better trust.

Why I Started Using Git with Clients

For years, my workflow was:

  1. Client emails me receipts, bank statements, invoices
  2. I enter everything into QuickBooks
  3. I email them a PDF report at month-end
  4. They email back: “Why is this categorized as X instead of Y?”
  5. I make changes, send updated report
  6. Repeat…

It was a black box to clients. They had to trust that I was doing everything correctly, but they couldn’t see my work until it was “done.”

With Beancount + Git:

  1. Client emails me receipts (same as before)
  2. I enter transactions in Beancount
  3. I open a pull request with all the transactions
  4. Client can see exactly what I’m adding before it’s finalized
  5. They comment on specific lines: “This should be Marketing, not Office Supplies”
  6. I make changes, they approve, I merge
  7. Month-end report is generated automatically from the merged data

The difference? Transparency and collaboration instead of “trust me, I’m the expert.”

Benefits My Clients Actually Care About

1. See What They’re Paying For

Clients pay me $500-1,200/month depending on transaction volume. With Git pull requests, they can see every single entry I make.

One client told me: “I feel like I’m getting my money’s worth now because I can see all the work you’re doing.”

That transparency builds trust and justifies my rates.

2. Catch Mistakes Early

When clients review pull requests, they catch things I wouldn’t know:

  • “That charge from Costco was actually personal, not business”
  • “That invoice should be split between two projects”
  • “We already paid that vendor—this might be a duplicate”

Catching errors before they’re merged into the permanent ledger is way easier than fixing them later.

3. Answer Questions Instantly with Git Blame

Client: “When did we start expensing that monthly software subscription?”

Me: Runs git blame expenses.beancount

Me: “June 12, 2025. Here’s the commit where I added it, and here’s the note explaining it was the new project management tool.”

Takes 30 seconds. Before Git, I’d be searching through months of QuickBooks entries.

4. They Can Track My Progress

Some clients check the repository daily. They can see:

  • “Bob committed 12 transactions today”
  • “Bob hasn’t worked on my books yet this week”

It keeps me accountable (in a good way) and gives them visibility without needing to ask for status updates.

The Challenge: Teaching Non-Technical Clients

Not gonna lie—getting small business owners to use GitHub is… optimistic.

Clients who engage with Git:

  • Tech startups (founders who use Git already)
  • Marketing agencies (comfortable with digital tools)
  • Consultants and freelancers (often former tech workers)

Clients who don’t:

  • Restaurants and retail (just want the books done)
  • Construction companies (busy on job sites)
  • Older business owners (not interested in learning new tech)

For clients who won’t use Git, I still track their books in Beancount + Git for my own benefit (version control, audit trail, automation), but I give them:

  • Weekly email updates with PDF reports
  • Read-only access to a Fava instance (web UI for Beancount)
  • Monthly Zoom calls to review everything

So even if they don’t interact with Git, I still get all the benefits.

Real Workflow Example: Monthly Close

Here’s how I do month-end for a client using the Git collaboration workflow:

Week 1-3: Ongoing Transaction Entry

  • I pull bank statements via API or CSV download
  • Import transactions into Beancount with my custom Python importers
  • Commit daily: git commit -m "Add transactions 2026-03-10: checking account"
  • Push to shared repo

Week 4: Month-End Reconciliation

  • Create branch: git checkout -b march-2026-close
  • Add balance assertions for all accounts (checking, savings, credit cards)
  • Run bean-check to verify everything balances
  • Open pull request: “March 2026 month-end close - 87 transactions”

Client Review

  • Client reviews PR on GitHub
  • Comments: “Line 45: That Amazon purchase should be Office Supplies, not General”
  • I make changes: git commit -m "Fix categorization per client feedback"
  • Client approves

Merge & Report

  • I merge PR to main
  • Tag release: git tag 2026-03-reconciled
  • Auto-generate PDF reports via Beancount queries
  • Email reports to client

Total time: ~3 hours for a client with 80-100 transactions/month (used to take 5-6 hours with QuickBooks + manual reconciliation).

Using Git Blame to Track “Who Entered What When”

This is invaluable for multi-person bookkeeping or when I have assistants.

Example: Client questions a $1,200 expense from 6 months ago.

git blame expenses.beancount | grep "1200"

Output:

a3f8d92 (bookkeeper_bob 2025-09-15) 2025-09-15 * "Legal consultation - Smith & Associates" 

I can immediately tell:

  • Who entered it (me, in this case)
  • When (September 15, 2025)
  • Context from the commit message

If it was entered by an assistant or the client themselves (some clients add their own transactions), I know who to ask for clarification.

Question for @finance_fred: Handling Large Transaction Imports

You asked earlier about committing transactions individually vs. in batches when doing bulk imports.

My approach:

  • Individual commits for manual entries: git commit -m "Add grocery receipt - Whole Foods $87.45"
  • Batch commits for imports: git commit -m "Import Chase checking transactions (March 1-15, 45 transactions)"

I batch imports because:

  1. Importing 100 transactions individually would create 100 commits (too noisy)
  2. The import script generates a single CSV → Beancount file, so it makes sense to commit as one unit
  3. If there’s an error, I can git revert the entire import and re-run it

But if I manually correct a specific transaction from an import later, that gets its own commit: git commit -m "Fix categorization of Target purchase - should be Office Supplies"

Does that make sense? Curious how others handle this.

The Git Repository vs. Client Portal Dilemma

@helpful_veteran mentioned this earlier: Most clients can’t (or won’t) navigate git repos.

My solution for less technical clients:

  • Read-only Fava deployment: I host Fava (Beancount’s web UI) on a DigitalOcean droplet
  • Automated weekly reports: Python script generates PDF reports and emails them
  • Quarterly Zoom reviews: I screen-share the Fava interface and walk them through everything

This gives them accessibility without requiring them to learn Git.

For technical clients who want full transparency:

  • Private GitHub repo with read access
  • They can browse commits, view diffs, see exactly what I’m doing
  • Some even clone the repo locally and run their own queries

Compare to My Old Workflow: Email Excel Hell

Before Beancount + Git, my client collaboration workflow was:

Old workflow (QuickBooks + Excel):

  1. Make changes in QuickBooks
  2. Export to Excel
  3. Email: ClientName_March2026_Books_v1.xlsx
  4. Client responds with changes
  5. Update QuickBooks
  6. Export to Excel again
  7. Email: ClientName_March2026_Books_v2_REVISED.xlsx
  8. Lose track of which version is current
  9. Client references the wrong version in a question
  10. Confusion and frustration

Current workflow (Beancount + Git):

  1. Make changes in Beancount
  2. Commit: git commit -m "Add March rent payment"
  3. Push to shared repo
  4. Client sees change in pull request
  5. Client comments directly on the line
  6. I update
  7. Client approves
  8. Merge
  9. One source of truth, complete history, zero version confusion

To Other Bookkeepers: Start Small

If you’re a bookkeeper curious about this workflow, my advice:

Don’t try to convert all clients at once. Pick ONE client:

  • Small transaction volume (50-100/month max)
  • Tech-savvy (or at least open to trying new things)
  • Good relationship (won’t panic if something goes wrong)

Use that client as a pilot for 3 months. Track:

  • Time savings
  • Client satisfaction
  • Number of questions/corrections

If it works (it will), gradually migrate more clients.

I started with one client in 2024. Now I have 8 on Beancount + Git, and I’m converting 2 more next quarter.

Final Thought: Clients Appreciate Transparency

The biggest surprise for me was how much clients appreciate seeing my work.

I thought they’d find it overwhelming or intimidating. Instead, they say things like:

  • “I finally understand what you do for us”
  • “This is so much better than just getting a PDF report”
  • “I trust the books now because I can see every change”

Transparency builds trust. Trust justifies rates. Higher rates mean I can serve fewer clients while earning the same income.

That’s the real ROI of Git + Beancount for bookkeepers.


Bookkeeper serving 20 small businesses in Austin, TX. 8 clients on Beancount + Git workflows. Advocate for plain text accounting transparency.