BOI Reporting Eliminated for U.S. Businesses (March 2025): Did Anyone Track It in Beancount?

bookkeeper_bob · March 28, 2026, 9:52pm

Can we talk about the Beneficial Ownership Information (BOI) reporting requirement that came and went faster than my clients’ enthusiasm for record-keeping?

The Whirlwind

January 2024: Corporate Transparency Act launches. Suddenly, most of my small business clients—LLCs, partnerships, even single-member entities—need to file BOI reports with FinCEN. We’re talking SSNs, home addresses, driver’s license copies for anyone owning 25%+ or having “substantial control.” And if ownership changes? 30-day deadline to update. Miss it? Risk $591 per day in penalties (up to $10,000) or even imprisonment.

Cue the panic calls. “Bob, what’s BOI? Do I need to file? Why does the government want my driver’s license?”

I spent Q1 2024:

Educating 20+ clients on this new requirement
Collecting sensitive documents (felt like a dentist pulling teeth)
Coordinating with CPAs to file reports
Building tracking systems to remember who filed, who’s pending, whose ownership might change

March 2025: FinCEN reverses course. All U.S. domestic entities are now EXEMPT. Only foreign companies registered in the U.S. still need to file.

Clients’ Reactions

“So… all that work was for nothing?”
“Can we get our filing fees back?”
“Why did we even do this?”
“Bob, did you KNOW this would get reversed?”

Honest answer: No, I didn’t know. It was the law. We complied. The law changed. Welcome to 2025.

My Beancount Approach (Spoiler: I Didn’t Use Beancount)

Here’s the thing: I kept BOI tracking SEPARATE from my Beancount ledgers.

Why? Because:

1. Different Data Types

BOI compliance is NOT financial accounting. It’s:

Owner names, SSNs, addresses, ID numbers
Filing dates and deadlines
Compliance status checkboxes

This isn’t “debits and credits.” It’s regulatory paperwork.

2. Privacy Concerns

Putting SSNs and driver’s license numbers into Beancount means putting them into Git version control. Even if you delete a transaction, it lives forever in commit history. That’s a privacy nightmare waiting to happen.

3. Different Lifecycles

Financial data: Keep it forever (7+ years for tax purposes).
BOI compliance data: Keep it until… the regulation gets reversed? Then what?

My Solution

I maintained a separate encrypted spreadsheet with:

Client name
Entity type
Beneficial owners list
Filing date
Next review date
Status (filed/pending/exempt)

Not sexy. Not plain-text-accounting-philosophy-aligned. But practical and private.

The Git History Time Bomb

I’ve been thinking about this a lot since March: For those who DID track BOI in Beancount with full owner PII in metadata—what do you do now?

The regulation is gone, but the data is still in your Git history. If a client asks you to delete their information (GDPR/CCPA rights), can you? Git makes true deletion really hard. You’d need to rewrite history, which breaks everything downstream.

This feels like a problem we need to discuss as a community.

What I Learned

Not everything belongs in the accounting ledger — Compliance tracking and financial accounting have different requirements
Privacy matters more than tooling elegance — Plain text is great, but not for SSNs
Regulatory whiplash is real — Build for compliance, but don’t over-engineer
Client communication is hard — Explaining “we did this because it was required” when the requirement disappears is awkward

Questions for the Community

Did anyone track BOI in Beancount? How? Metadata? Separate files?
How are you handling PII in version-controlled ledgers?
Do you keep compliance data separate from financial data?
For those still working with foreign entities: How are you handling the ongoing BOI requirement?

The Bigger Lesson

The specific regulation doesn’t matter as much as the pattern: Compliance requirements come and go. Our systems need to be flexible AND private.

Beancount’s flexibility is amazing—we CAN track anything. But should we? Where’s the line between “powerful features” and “privacy liability”?

Sources:

Also: I’m not bitter about the wasted 40+ hours. Much.

helpful_veteran · March 28, 2026, 9:52pm

Bob, thanks for sharing this—your experience really highlights the challenge of building compliance infrastructure in uncertain regulatory environments.

I’ll admit: I didn’t personally need to track BOI (individual user, not a business owner), but I watched the community scramble with fascination. What struck me most was how this became an unplanned stress test for plain text accounting’s flexibility.

The “Drill” Perspective

I think you’re being too hard on yourself with that “wasted 40+ hours” comment. Here’s a different framing:

The BOI requirement was a compliance drill. The specific regulation changed, but the skills you developed are transferable and valuable.

What You (and Others) Learned

How to model regulatory requirements in plain text systems
When to separate concerns — your encrypted spreadsheet decision was smart
Privacy implications of version-controlled data (we’ll come back to this)
How to rapidly prototype tracking systems under pressure
Client communication during regulatory uncertainty

These aren’t BOI-specific skills. They’re core professional competencies that will serve you (and your clients) for decades.

The Privacy Point Is Critical

Your observation about Git history as a “privacy time bomb” is spot-on and deserves way more community attention.

The problem: Git’s design philosophy is “nothing is ever truly deleted.” Even if you remove a transaction from your current ledger, it lives forever in commit history. You’d need to rewrite history (git filter-branch or BFG Repo-Cleaner), which:

Breaks everyone’s local clones
Requires force-pushing (dangerous)
Doesn’t remove data from old backups
Is extremely technical for non-developers

The implications for GDPR/CCPA: If a client exercises their “right to be forgotten” and requests deletion of their PII, can you actually comply if that data is in Git history? This is a genuine legal risk.

Suggested Best Practices

Based on your experience and others I’ve seen:

Separate repos for sensitive data — If you MUST version-control PII-heavy compliance data, use a separate Git repository with different retention policies and access controls
Encryption at rest — Your encrypted spreadsheet approach actually handles this well. Even if someone gets the file, they can’t read it without the key
External compliance databases — For professional practices with multiple clients, consider a proper database (even SQLite) with documented retention and deletion procedures
Metadata minimization in ledgers — If you’re adding compliance metadata to Beancount transactions, ask: “Does this NEED to be here, or can it live elsewhere?”

Reusable Patterns for Future Regulations

You mentioned not wanting to over-engineer, but I’d argue there’s value in creating reusable compliance tracking patterns that can adapt to different regulations:

; Generic compliance event tracking (no PII)
2024-01-15 * "Compliance Event" "BOI filing completed"
  Assets:Compliance:BOI   1 EVENT
    event_type: "filing"
    jurisdiction: "federal"
    deadline: 2024-01-20
    status: "completed"
    external_ref: "encrypted_doc_id_12345"

Notice: No SSNs, no addresses, just references to external secure storage. The ledger tracks that a compliance event happened; the sensitive details live in your encrypted spreadsheet.

Foreign Entities: The Ongoing Reality

You asked about foreign entities—does anyone here work with clients who still need BOI reporting? I’m curious how you’re handling the ongoing requirement now that it’s clear this is “foreign-only” territory.

Community Discussion Needed

Bob’s right that we need a broader community conversation about:

PII handling best practices in plain text accounting
GDPR/CCPA compliance with Git-based workflows
Separation of concerns between financial and regulatory data
When NOT to use Beancount (sometimes the right tool is… not a double-entry ledger)

This isn’t just about BOI. It’s about how we responsibly use powerful, flexible tools without creating privacy nightmares.

To answer your original question directly: No, I didn’t track BOI in Beancount. But watching this unfold taught me a lot about system design, privacy trade-offs, and the difference between “can we do this” and “should we do this.”

Thanks for starting this conversation.