tedpower

So cool! Chris is a wizard.

Hey HN, we're YC S22 — let us know if you have any questions or feedback!

Thanks Ashwin. And if anyone has questions about working with Stripe BaaS, happy to chat about that as well — it's been great!

Thanks for the question!

So the way that Bend works, we take a transaction, and then match it with the best available 'emissions factor'. So, for example, if you purchase something at Starbucks, we match that transaction to the Starbucks specific emissions factor: https://bend.green/starbucks

Over 65% of total market cap is now covered by this sustainability data, and we aggregate that data, and use it to estimate the emissions for each transaction.

Of course there is a very long tail. So if you buy a coffee at a small coffee shop, we likely don't have that merchant-specific data. In those cases, we fall back to "Merchant Category Code" (MCC) emissions factors.

And finally, in some cases we have SKU-level data. E.g. we have an Amazon Business integration where we get the actual specific item data.

Long story short is we have surprisingly high merchant coverage — well north of 60%. We have pretty limited SKU-level coverage today, but expanding. And then we always have an MCC fallback. The larger the merchant, the more likely we are to have good data for them (we're trying to grow coverage for mid market and smaller businesses with Bend).

This means that you can get a pretty detailed, totally automated sense of your emissions hotspots.

More info here: https://usebend.com/how-it-works

Thanks :)

Hi HN, let us know if you have any questions!

haha indeed — but actually, this is kind of the point — purchasing carbon removal credits is just like any other business purchase, but with a negative emissions factor. When you purchase carbon removal credits on Bend, it shows up as just another transaction, but with negative CO2e.

Thanks, ya, fair points — as orgs level-up and get more sophisticated, you might start to use Bend as the first pass, identifying hot-spots, and then doing deeper dives on the specific 'SKUs' that are being purchased.

ya, that's right, good point. For complete GHGP inventory reporting, customers need to estimate employee commuting separately (and we're happy to help with that; it's usually a pretty straightforward calculation, though gathering the employee info takes some doing).

Setting the GHGP aside, my own personal opinion about how we interpret GHGP data is that it's important to make a clear distinction between upstream emissions and downstream emissions. For example, 'use of sold products' (Category 11) is also not something you can determine from spend data. But I'd argue that 'use of sold products' is a very different thing than upstream emissions (even though they're all lumped under Scope 3).

Commuting is a less clear-cut case, but I think of commuting (that is paid for by employees) as more of a downstream emissions category.

We wrote up some notes on this here: https://bend.green/faq/downstream-emissions

We treat payroll as zero emissions. The responsibility boundary of a company doesn't include the personal consumption decisions of employees. The spend-based approach makes this pretty straightforward — if the company is buying, those are company emissions. If an individual is buying, those are individual emissions.

Hi! Ya we only use full GHGP inventory data. Honestly, the hardest data to gather is clean transaction data! The Brex API returns relatively clean data. Other banks and financial institutions, via Plaid, often have pretty messy merchant and category info. If I had a magic wand, it's actually the spend data I'd focus on — super clean, itemized transaction data would be amazing.

We picked a price that opens up the addressable market beyond late stage and public companies.

As startups, you have an unfair advantage — it’s much easier to build good carbon habits early, vs. retooling your business after having already invested large amounts of capital in carbon-intensive practices and depreciating assets.

We do offer enterprise pricing for API access for larger customers.

Hey, good questions! You know your stuff.

Re: do you have any concerns that your users might shortcut the work to produce high quality estimates of their Scope 3 emissions when you have made it so easy to get lower quality estimates?

> I think the high order bit here is that 99%+ of companies don't measure their emissions at all. This is for a good reason — measuring your emissions historically has been quite labor-intensive. Even for large companies, there is always a 'long tail' of 'Scope 3 goods and services' transactions that are hard to measure. Our goal is to create a scalable solution so that a much larger share of companies are able to participate.

Re: your grocery store example —

> This is a fair point. Our main belief is that realtime, actionable data trumps perfectly attributed data, if perfectly attributed data requires a bottoms-up manual model. The advantage of the spend-based approach is that (1) it's realtime, and (2) it aligns incentives at the company level. The holy grail, however, would be itemized spend data (level 3 data), where you could factor in the emissions of your specific line-items. Unfortunately, that data is nearly impossible to get (yet). Maybe that's Bend 2.0 :)

Re: re-accounting historical emissions —

> Yes! We use the emissions 'factor' that most closely matches the transaction date. So for example, if you bought a Starbucks coffee in 2020, we would use the 2020 Starbucks factor, and if you bought a Starbucks in 2021, we would use the 2021 Starbucks factor. If Starbucks is late to publish their 2022 report, we would recalculate the emissions when the info is updated. For our category fallbacks, we also take currency / region into consideration.

Happy to chat more, either with you or the WRI folks! Thanks for the questions.

Unfortunately 'spend less' is not by itself a viable strategy for most growing companies. Companies need to invest in their growth. But companies can instead shift their spend from higher 'carbon intensity' goods and services to lower carbon intensity goods and services. E.g. if you need to buy a vehicle, buy an electric vehicle. Or if you need to rent office space, rent well-insulated efficient office space. Or if you need cloud hosting, select the greenest cloud and the greenest region. Or if you need to meet with a prospective customer, maybe do it over Zoom vs. getting on a plane. We try to help you prioritize that list of lower-carbon options.

Ya, the Greenhouse Gas Protocol — https://ghgprotocol.org/ — is the universally accepted way for companies to measure their emissions. It's been around for about a decade.

That being said, the Greenhouse Gas Protocol reporting has been pretty inconsistent in the past. Companies cherry-pick and leave out important info, or define their 'reporting boundary' in inconsistent ways. One of our goals is to help 'debug' these inconsistencies.

Lucas Joppa from Microsoft laid this out quite well here: https://www.ted.com/talks/lucas_joppa_how_to_fix_the_bugs_in...

Ya totally! Another way to think about it — in climate lingo, there are 3 types of emissions: First there are Scope 1 emissions, which are the emissions from burning fossil fuels directly (gas in your car, natural gas for your stove, etc.). Then there are Scope 2 emissions, which are from energy (you buy electricity from utilities, and those utilities use some percentage of non-renewable generation, like coal or natural gas). And finally Scope 3 is everything else — all the goods and services you buy, upstream and downstream.

But I think the point you guys are making, is that actually everything is Scope 1 emissions plus some number of hops. So if you buy gas, that's 0 hops. If you buy energy from your utility, and they use natural gas, that's 1 hop. If you buy an ice cream that was made in a factory powered by natural gas, that's 2 hops. And if you buy that ice cream with a cone, purchased by the ice cream shop, that was manufactured in a factory ... etc.

The problem is, consumers are often the ones who apply the pressure to address climate (don't wait for the fossil fuel companies to take this on themselves). And so we need to trace back all those upstream emissions, all the way back to those Scope 1 emissions, to really size the impact, and align incentives to decarbonize.

Historically, climate programs only focused on Scope 1 and Scope 2 emissions. But that only addresses maybe 20% of emissions for most companies. This is why it's critical to consider the impact of all the goods and services your company purchases.

+1!

Ya I hear you, our goal is to combat greenwashing in a few ways. We cover total emissions (vs. cherry-picking categories of emissions). We incentivize companies to take action today (vs. vague 2040 or 2050 goals). And to the degree that carbon credits are part of your strategy, we push for very high cost-per-tCO2e removal credits ($100 / tCO2e) vs. low quality $5-$10 cost-per-tCO2e avoidance credits.

Ya good point — our approach is always spend-based, so the way we'd calculate cloud spend is your AWS / GCP bill * the AWS / Google carbon intensity (what we call a 'factor'). It is true that some data center regions use cleaner energy vs. others. We consider the spend-based approach, at a minimum, a good first pass. The greener the cloud you use, the lower the emissions. And then you can further optimize within your cloud provider.

Another note — most cloud emissions only factor in the energy footprint ('scope 2' in technical greenhouse gas inventory terms). We believe this significantly undercounts emissions, because it ignores the capital expenditure of building the facility, buying all the machines, etc. The great thing about the spend-based approach is all this overhead is factored in. (BTW, Google Cloud Platform just started to layer in some of this 'scope 3' operational overhead data, but I believe AWS still ignores it, significantly undercounting emissions).

PlanetScale is an awesome DB that handles sharding and size-balancing — plus they have an incredible free tier. https://planetscale.com/

Rust is a memory-safe systems programming language that has earned the title of most beloved language on StackOverflow’s annual developer survey for the past six years running. https://www.rust-lang.org/

These two technologies seemed like a match made in heaven. The best in database technology with an unbeatably fast and secure access layer. There was just one problem…

…no one had ever done it before. Until now! Let us know if you have any questions :)

We use Bank of America, but I'm particularly interested in people's impressions of Ramp and Divvy

Until we have 'common sense' AI (which is still probably quite a ways off), design can help expose the syntax that AI can understand. Here are some thoughts on that: https://medium.com/@tedp/how-design-can-help-bridge-the-ai-g...

I jotted down some thoughts about slack bots, NLP, and blending UI affordances into conversational interfaces in this Medium post

Abacus (YC W14) is eliminating expense reports. Submit expenses in realtime, and get paid out directly to your bank account via ACH. It's the fastest way to manage and pay your expenses.

It's spooooky how easy it is to use (happy halloween yall)

Agree that there needs to trust here, we're thinking about adding a setting where you can set auto-approval limits, so that any expense under $x get approved without any approval.

Next time you're compiling an expense report or waiting to get reimbursed, think about how things might be different with something like Abacus ;)

I'm not sure what you mean by the second step 'later you go over all the bills and receipts again and try to match them with what you approved earlier'

With Abacus, the payments are automatic. We also sync directly with your accounting software. We automatically create a bill (with the expense info) and the bill payment (from your companies connected bank, which gets auto-debited) so there's no reconciliation. The two cancel each other out, it's totally on auto-pilot.

Also, with corporate cards, you're still required by the IRS to save receipts for expenses over $75, so there's still a reconciliation process. We're building the ability to import your card expenses straight into Abacus, so you can add the note, receipt etc. all in the same place.

If managers only want to log in and approve stuff in batch they're still welcome to do that with Abacus. But we've found that people quickly adapt to the faster flow —

What we've found is:

1. Managers like the transparency of knowing how their employees are spending money. Many managers today actually have to nag their team to get their expenses in before they close the books. This more up-to-date information about how money is getting spent can often be helpful to the manager.

2. Approving expenses in Abacus is stupidly easy, and it shows that you love your employees. Companies (especially in tech) compete so hard to make employees happy (snacks, benefits, etc.) and Abacus is one of the easiest ways to make your employees happier. Rather than treating employees 'guilty until proven innocent' and making them wait months to get paid back for their legitimate business expenses, Abacus lets you easily reimburse your employees, which you're going to do anyway. Win win

3. It's actually a time saver. Abacus syncs directly with your bookkeeping software (time-saver) and we automatically categorize expenses, based on the vendor info we pull from foursquare (time-saver). We've also built the conversation directly into Abacus, so you can comment on any expense that needs further clarification, rather then trying to hunt someone down over email about some confusing expense from 2 months ago (time-saver). The net effect is a much tighter, faster feedback loop.

Hey Michael, yup this still requires manager approval. Our manager approval is just about the easiest thing imaginable — managers get a push notification when there are new expenses, and they can swipe across the expense to approve them (like Mailbox App). The majority of expenses on Abacus are approved within 24 hours.

Sometimes managers worry that these notifications will get annoying (we worried about that too). What we've found is that managers actually like the transparency of knowing what their team is up to, and it's a great opportunity to send a little love to your employees by getting back to them quickly. It also takes just a few seconds / day. You can turn off the notifications, but most people don't.

Yea — we're trying to avoid the bajillion separate fields you have to enter, typical of Oracle or Concur. We try to do some smart things — for example if you're at a place (gas station, restaurant, etc.) you can select the place from our 'nearby' list with one tap, and then we're working on using that location data to automatically categorize the transaction, put it on a map, etc.

I hear you on not wanting to grant your employer access to all your card data. Your employer will only be able to see the transactions that you pass through to them as business expenses.

Your bank account information never touches Abacus's servers. http://support.abacus.com/hc/en-us/articles/200792470-Is-Aba...