Scope 1, 2, and 3 Emissions Tracking in Your Accounting System: ESG Went Mandatory in 2026 and Small Businesses Got Zero Guidance

accountant_alice · April 5, 2026, 12:03am

I had three separate clients ask me about “carbon reporting” this quarter. Three. A year ago, zero. Something shifted and I’ve been researching what’s actually required—and what small businesses are supposed to do about it.

The Regulatory Landscape (What Actually Changed)

Let me lay out the facts, because there’s a lot of confusion:

California SB 253 requires companies with over $1 billion in annual revenue to report Scope 1 and 2 greenhouse gas emissions starting with 2025 data (filed in 2026). Scope 3 follows in 2027.
EU CSRD expanded to listed SMEs as of January 2026, with an opt-out available until January 2028. The “double materiality” standard means reporting both how sustainability risks affect your company AND your company’s impact on society.
SEC climate disclosure rule remains in legal limbo after the administration change, but Large Accelerated Filers were originally facing March 2026 deadlines.

Now, most small businesses reading this aren’t $1 billion companies or EU-listed SMEs. But here’s the catch that my clients are bumping into: supply chain pressure flows downhill. If your largest customer is subject to Scope 3 requirements, that means reporting their supply chain emissions—which includes your business. I’ve already seen RFPs from larger companies that now include a “sustainability data” section asking vendors to estimate their carbon footprint.

The Practical Problem: How Do You Actually Track This?

I looked into the tooling landscape and it’s… not great for small businesses:

Specialized carbon accounting platforms (Persefoni, Sweep, Greenly) start around EUR 3,000/year and scale to EUR 80,000+. Way out of budget for my clients with $200K-$2M revenue.
Free SME calculators (like Normative’s SME Climate Hub tool) give rough estimates, but they don’t integrate with your actual books. You get a ballpark number, not auditable data.
Spreadsheets are where everyone defaults. And we all know how that ends—errors, no version control, no audit trail.

Could Beancount Handle This?

This is what I’ve been thinking about for the last few weeks. Beancount’s metadata system is remarkably well-suited for tracking non-financial data alongside transactions:

2026-04-01 * "Pacific Gas and Electric" "Monthly electricity"
  Expenses:Utilities:Electricity    450.00 USD
  Assets:Checking
  ; kwh: 2800
  ; co2_kg: 560
  ; scope: 2
  ; emission_source: "EPA eGRID 2025 CAMX subregion"

2026-04-02 * "United Airlines" "Client meeting travel SFO-ORD"
  Expenses:Travel:Flights    1200.00 USD
  Assets:Credit-Card:Amex
  ; miles: 1846
  ; co2_kg: 428
  ; scope: 3
  ; emission_source: "DEFRA 2025 domestic flight emission factor"

The appeal is obvious: your financial records and environmental records live in the same system, version-controlled, auditable, queryable. No separate spreadsheet to maintain. No data synchronization issues between your “books” and your “carbon tracker.”

Open Questions I’m Wrestling With

Metadata vs. commodity approach. Should emissions be metadata on transactions (as above), or tracked as a separate commodity? You could theoretically post 560 CO2_KG to an Emissions:Scope2:Electricity account. That would enable balance assertions and let you “close” annual emissions the same way you close revenue. But it also adds complexity.
Emission factor sourcing. EPA publishes eGRID for US electricity, DEFRA publishes transport factors, but there’s no unified database. Factors change every year. Who maintains this? Could a Beancount plugin auto-populate emission metadata based on transaction categories?
Scope 3 is a nightmare. Supplier emissions, employee commuting, customer product usage… the data barely exists for Fortune 500 companies, let alone a 10-person business. Is “best available estimate” defensible, or does it create liability?
Timing question. Am I getting ahead of myself building this for small business clients right now? Or will the firms that start tracking early have a competitive advantage when RFPs universally require sustainability data in 2-3 years?

What I’d Love to Hear From This Community

Has anyone incorporated non-financial metrics (carbon, water usage, waste) into their Beancount ledger? What schema did you land on?
For bookkeepers managing multiple clients: are YOUR clients asking about ESG yet, or is this still “enterprise company problems”?
Would a Beancount emission-factor plugin be useful—something that reads expense transactions, looks up EPA/DEFRA factors, and auto-generates CO2 metadata?
Is this the kind of thing where plain text accounting could genuinely outperform commercial tools for small businesses, or am I projecting my love of Beancount onto a problem that needs dedicated software?

Genuinely curious where the community stands on this. My instinct says ESG tracking in Beancount is a natural fit—but my CPA training says “don’t build what you can buy.” The problem is, there’s nothing to buy at a reasonable price point for small businesses.

finance_fred · April 5, 2026, 12:04am

Alice, you just described what I’ve been building in my personal ledger for the last two months. Let me share where I’ve landed.

The Commodity Approach Works Better Than Metadata

I tried metadata first (like your examples) and ran into a wall: you can’t easily aggregate metadata across transactions in BQL without a custom plugin. So I switched to treating CO2 as a commodity:

2026-04-01 * "PG&E" "Monthly electricity"
  Expenses:Utilities:Electricity    450.00 USD
  Emissions:Scope2:Electricity      560 CO2KG
  Assets:Checking                  -450.00 USD
  Equity:Emissions                 -560 CO2KG

This gives you real double-entry for emissions. You can run bean-query and get total emissions by scope, by category, by month—just like you would with financial data. You can even do balance assertions:

2026-12-31 balance Emissions:Scope2:Electricity  6,720 CO2KG

The tradeoff is verbosity—every transaction that has emissions gets an extra two lines. But as someone who tracks every $3 coffee purchase for FIRE purposes, I’m not afraid of detailed records.

My Household Carbon Dashboard

I built a simple Python script that reads my Beancount ledger and generates a monthly carbon report. Here’s what I’m tracking:

Scope 1 (direct): Natural gas heating (~2,400 kg CO2/year)
Scope 2 (electricity): ~6,700 kg CO2/year (California grid is relatively clean)
Scope 3 (indirect): Flights, Amazon deliveries, food (estimated) ~4,500 kg CO2/year

Total household: ~13,600 kg CO2/year. The US average household is ~48,000 kg. So I’m at about 28% of average, which feels good but also shows how much is structural (heating, electricity) vs. behavioral (flights, shopping).

The FIRE + ESG Connection Nobody’s Talking About

Here’s what I find fascinating: the FIRE lifestyle is inherently low-carbon. When you optimize for savings rate, you naturally reduce consumption. I spend less, so I emit less. My FIRE spreadsheet and my carbon spreadsheet tell the same story from different angles.

For Beancount, this means one ledger can serve double duty: track your path to financial independence AND quantify your environmental impact. That’s not overengineering—that’s data-driven living.

On the Plugin Idea

I’d absolutely contribute to an emission-factor plugin. The architecture could be straightforward:

Maintain a YAML file mapping expense categories to emission factors (updated annually from EPA/DEFRA data)
Plugin reads transactions, matches against the mapping, auto-generates CO2 commodity postings
User overrides for specific transactions where they have better data (like actual kWh from utility bill)

The hardest part isn’t the code—it’s maintaining the emission factor database. Maybe we could pull from the GHGP emission factor hub programmatically?

Definitely not just you being a data nerd, Alice. This is a real need. I’d bet within 3 years, every small business will need some form of carbon tracking, and Beancount will be better positioned than any $80K/year SaaS platform.

helpful_veteran · April 5, 2026, 12:04am

Great thread. I want to offer a slightly different perspective as someone who’s been using Beancount for 4+ years and has watched many “Beancount can do EVERYTHING” ideas come and go.

Start Simple, Don’t Overengineer

Alice, your instinct to explore this is right. But I’d pump the brakes on building a full emission tracking system before you have a clear use case. I’ve seen this pattern before—Beancount users get excited about the flexibility of metadata and commodities, build elaborate tracking systems, then abandon them after 3 months because the data entry burden is too high.

Ask yourself: who is the consumer of this data? If it’s just you satisfying curiosity, metadata on a few key categories (electricity, flights, gas) is plenty. If it’s a client responding to an RFP, you need something more structured. If it’s a regulatory filing… honestly, you probably need commercial software with attestation features.

What I Actually Do

I track two things:

Electricity consumption in metadata (; kwh: 2800) because I have solar panels and it helps me calculate ROI on the solar investment. This is financial data that happens to also be environmental.
Car mileage in metadata (; miles: 142) because I have rental properties and need to track business vs. personal miles for tax deductions. Again, financial first, environmental second.

I don’t try to calculate CO2 from these because the emission factors are jurisdiction-specific, change annually, and I don’t trust my own calculations for anything that might face scrutiny. If a client needed actual carbon reporting, I’d hire someone who does this professionally.

The Real Question: Liability

Alice, you touched on this with Scope 3 liability, but I think it goes deeper. If you build a Beancount-based carbon tracker for a client, and they use those numbers in an RFP or regulatory filing, and the numbers are wrong because you used the wrong emission factor or missed a category… who’s liable?

This isn’t like financial accounting where we have GAAP and centuries of precedent. ESG reporting standards are fragmented (GRI, SASB, TCFD, now ISSB trying to unify them), methodologies differ wildly, and “materiality” is defined differently in every framework.

My advice: track what’s useful for your own decision-making. Don’t promise clients “Beancount-powered ESG reporting” until the standards stabilize.

That Said…

Fred’s commodity approach is clever. If you’re going to do this, treating CO2 as a commodity is more “Beancount-native” than metadata. Metadata is hard to query in aggregate; commodities play nicely with BQL and Fava’s built-in reports.

Just… start with one category (electricity is easiest since you get actual kWh from utility bills) and expand slowly. Don’t try to boil the ocean on day one.

bookkeeper_bob · April 5, 2026, 12:04am

I’m going to bring the client-facing reality check here.

None of My 20+ Clients Have Asked About This. Yet.

Alice, you mentioned three clients asking this quarter—that’s notable. I manage books for restaurants, landscaping companies, a small gym chain, a few e-commerce businesses. ESG? Carbon tracking? Not on their radar. They’re worried about cash flow, payroll taxes, and whether their QuickBooks reconciliation is done before the bank statement closes.

But here’s what IS happening: two of my restaurant clients got questionnaires from their food distributors. Not “carbon questionnaires”—procurement questionnaires that included a few questions about energy usage, waste management, and sourcing practices. They came to me confused. “Bob, do we need to fill this out? What do we put?”

I helped them estimate energy usage from their utility bills and waste volume from their hauler invoices. Took about an hour per client. No Beancount involved—just back-of-napkin math from existing records.

The Practical Gap

Here’s what I think is missing from this conversation: most small businesses don’t know their own utility consumption. They pay the electric bill and file the receipt. They don’t read the kWh. They don’t know their natural gas therms. They definitely don’t know their fleet mileage by vehicle.

Before we talk about emission factor databases and Beancount plugins, the first problem is data collection. You need to:

Actually read your utility bills and record consumption (kWh, therms, gallons)
Track vehicle mileage if you have fleet vehicles
Estimate waste volume (most businesses have no idea)

For my clients on Beancount, I could start adding metadata to utility expense transactions. That’s low effort: when I import the bank CSV, add the consumption data from the utility bill PDF. Five minutes per month per client. Not a big ask.

Where I See the Value

Honestly? The biggest value isn’t regulatory compliance. It’s cost savings. When I showed one restaurant client that their electricity was 40% higher than comparable restaurants (because their walk-in freezer was running inefficiently), they got it fixed and saved $200/month. The carbon data was incidental—the kWh tracking drove a real business decision.

If we frame Beancount ESG tracking as “track your resource consumption to find waste and save money, and oh by the way you’ll have carbon data ready when someone asks,” that sells much better to small business owners than “you need to prepare for mandatory Scope 3 reporting.”

On the Plugin Idea

I’d use a simple one. Something that takes ; kwh: 2800 on an electricity transaction and auto-calculates ; co2_kg: 560 based on the client’s utility region. That’s useful. Anything more complex and I’d be spending more time configuring the plugin than just doing the math myself.

Keep it simple. Start with electricity and natural gas. Those cover Scope 1 and 2 for most small businesses. Scope 3 can wait until someone actually asks for it.

accountant_alice · April 5, 2026, 12:04am

Really appreciate these three perspectives—each of you highlighted something I was circling but hadn’t articulated.

Fred: The commodity approach is elegant. I think you’re right that it’s more query-friendly than metadata for aggregation. The Equity:Emissions balancing entry is a nice pattern—treats your “carbon budget” like a financial budget. I’m going to prototype this with one client who’s already asked.

Mike (helpful_veteran): Your liability point is the one keeping me up at night. You’re absolutely right—if I provide “Beancount-powered carbon numbers” and a client puts them in a regulatory filing, I need E&O insurance that covers environmental consulting, not just accounting services. That’s a real constraint. For now, I’m positioning this as “internal tracking for decision-making,” not “compliance-ready reporting.”

Bob: Your cost savings framing is brilliant. “Track consumption to find waste” is a conversation every small business owner understands. “Prepare for mandatory ESG reporting” makes their eyes glaze over. And your point about data collection being the real bottleneck is dead on. You can’t track what you don’t measure, and most businesses don’t measure consumption—just cost.

My Revised Approach

Based on this conversation, here’s what I’m going to do:

Start with one client who explicitly asked about carbon tracking
Track electricity and natural gas only (Scope 1 and 2)—Bob’s right that Scope 3 can wait
Use Fred’s commodity approach (CO2KG as a commodity) for this client
Use metadata approach (; kwh:) for my other clients where I’m just enriching utility transactions for cost analysis
Frame it as cost optimization that also produces carbon data—not as “ESG compliance”
Do NOT offer this as a formal service until I understand the liability implications—Mike’s point about professional responsibility is too important to brush aside

If this works well after 6 months, I’ll write up the methodology and share it here. Maybe by then the standards will have stabilized enough that we can talk about a proper plugin.

Thanks for the reality check, everyone. This is exactly why I post here before going down a rabbit hole.