Announcing Stedi’s $50 million Series C

Two years ago, we announced the launch of our clearinghouse. Seven months ago, we announced our Series B funding. Today, I’m thrilled to announce Stedi’s $50 million Series C, led by Addition with participation from Stripe, Ribbit, USV, First Round, BoxGroup, and Bloomberg Beta, along with angel investors including Tobi Lutke, Charlie Songhurst, Guillermo Rauch, Karim Atiyeh, Max Mullen, and more. This latest round brings our total funding to $142 million.

We’ve grown enormously over the past year. This month, Stedi was named one of Ramp’s fastest-growing vendors – across all categories, not just healthcare – for the second time in ten months; we’re the first non-AI company to make the list in five months. Our number of paying customers has increased by 6x year over year, and our number of billed transactions has increased by over 7x. We’re now processing more than a billion claims and eligibility transactions annually – to frame this on a relative basis, we processed more transactions in February alone than we did in the first half of 2025 combined.

We’ve done all this while offering a level of support that (allegedly) doesn’t scale. We offer dedicated Slack and Teams channels to every customer and now have over 1,500 shared channels. Over the past 12 months, our median support ticket response time has decreased from 18.3 minutes to just 6.7 minutes, all while handling a 6.4x increase in support volume – with 100% of tickets answered by humans.

Our customers send us thousands and thousands of questions and suggestions every month, day and night, and the learnings we get from this firehose of real-time feedback are the engine that turns our business. It is this process that has made us the fastest-growing clearinghouse by a wide margin.

This new round of funding allows us to expand our product footprint even more quickly. As we look to the year ahead, it’s worth taking a step back to explain the clearinghouse market and how Stedi is fundamentally different from the legacy clearinghouse incumbents that have processed these transactions historically.

The clearinghouse landscape

Stedi is a healthcare clearinghouse. Clearinghouses sit in between two key parties in the healthcare ecosystem: providers – entities delivering medical care, such as doctors and hospitals – and payers – the commercial and government insurers that pay for care, such as UnitedHealthcare, Cigna, and Medicare.

Clearinghouses process the standardized insurance-related transactions that were mandated by HIPAA’s Administrative Simplification requirements, including eligibility checks, claims, electronic payments, and more. There are thousands of payers and millions of providers in the United States, and it isn’t feasible for either side to maintain connectivity to such a broad network of trading partners, nor is it realistic for them to keep track of the ever-changing transaction requirements across the network.

Healthcare clearinghouses have existed for decades, and the legacy clearinghouse incumbents all share a common set of challenges.

The need for electronic claims clearinghouses arose after the enactment of HIPAA in 1996, which means that the legacy clearinghouses were built before widespread adoption of the internet. Their infrastructure and IT systems are built with outmoded security rather than today’s cloud-native, defense-in-depth practices. Their on-prem systems struggle under the load of modern internet-scale traffic – even more so now in the world of AI agents that work far beyond human speeds – and many are only partway through years-long attempts to migrate into the cloud.

The challenging state of legacy clearinghouses today is largely the result of decades of M&A. After dozens of mergers, they have sprawling catalogs of products that share a common brand name but are siloed in practice – the products are underpinned by technology stacks that have never been harmonized or modernized. The clearinghouses have private equity ownership that changes every 3-5 years, and those owners allocate as little as 5% of revenue to R&D. Much of the R&D spend goes to attempting to integrate the M&A portfolio, leaving little investment for the core transaction engines that make clearinghouses valuable.

Customers experience all of this as a consistent set of frustrations. The product functionality today is the same as it was ten years ago, at best. In many cases, it’s degrading over time. Support cases go unsolved or even unanswered as the people who built the systems are long gone, and the support teams – often offshored to save on support costs – don’t have the context to answer questions about the long tail of transaction issues that make up the bulk of RCM frustrations. And after several decades of price decreases in the clearinghouse market, prices are now actually starting to increase as the legacy incumbents test their pricing power after years of consolidating competitors.

Perhaps most importantly, though, is that the fundamental architecture of the legacy clearinghouses is incompatible with an RCM ecosystem that is rapidly being modernized by AI workflows.

Agents need APIs

AI agents are designed to interact with applications programmatically via application programming interfaces – APIs. Modern applications are built API-first, which means that virtually any action that can be taken by a human through a user interface can also be taken by a machine via an application programming interface. When an agent needs to post a Slack message, it uses Slack’s API; when it needs to connect to a bank account, it uses Plaid’s API; when it needs to send an email, it uses Resend’s API. One can imagine how painful it would be for an agent to reliably perform any of these tasks at scale if the only option were to open a web browser and attempt a set of nondeterministic actions.

Unfortunately, incumbent clearinghouses – like most enterprise software platforms from several decades ago – offer only the most basic functionality via API, and those APIs are sparsely documented second-class citizens that are gated behind cumbersome sales processes. Because of the difficulty in introducing modern APIs into a preexisting platform, an API-native experience will never be a reality for legacy incumbents. Instead, they offer two primary interaction modalities: X12 EDI transactions (such as claims and eligibility checks) exchanged over SFTP and SOAP, and users taking actions in a web browser (such as viewing transaction history or submitting ERA enrollments).

Today’s AI agents aren’t designed to exchange arcane formats like X12 over early web protocols like SFTP and SOAP, and so when they interact with legacy clearinghouses, they’re relegated to accessing the portal via the web browser using a process called RPA (robotic process automation) – more commonly known as ’portal scraping’ – where the AI agent logs in as a human user and attempts to mimic the actions that a human would take. Portal scraping is notoriously brittle, slow, and expensive.

Yet with legacy clearinghouses, this is even worse: in addition to not offering APIs outside of only the most basic functionality, they actively work to block bots from using the portal and often charge exorbitant fees to remove these restrictions. As a result, customers attempting to use legacy clearinghouses for agentic workflows are in a constant game of cat-and-mouse as their legitimate usage patterns are clamped down upon – all while trying to keep up with small breaking changes in the web portal interfaces that cause workflows to stop working.

What makes healthcare transactions uniquely automatable

For as many challenges as the US healthcare industry has, it also has a tremendous amount of standardization and interconnectivity that makes it an almost unparalleled opportunity for automation and efficiency.

When HIPAA mandated support for electronic eligibility checks, claims, and claim payments, it chose the ubiquitous X12 EDI standard – the very same transaction standard used in the retail, logistics, and manufacturing industries that run the global supply chain. But unlike these other industries that have voluntarily adopted X12 with virtually no constraints or common requirements, HIPAA went several steps further by mandating prescriptive, comprehensive transaction schemas that must be followed by all parties in the healthcare ecosystem, with few exceptions – the ‘payer-specific differences’ that are commonly cited as problematic in healthcare are trivial compared to the heterogeneity seen outside of healthcare.

Within the transactions themselves, there are rich, standardized code sets and identifiers that further constrain variability in transactions. There are mandatory, standardized clinical, billing, and entity vocabularies embedded throughout these transactions: CPT and HCPCS for medical procedures and services, ICD-10-CM and ICD-10-PCS for diagnoses and inpatient procedures, NDC for drugs, DRGs and revenue codes for institutional reimbursement context, taxonomy codes and NPIs for provider identification, TINs and payer identifiers for trading party routing, as well as place-of-service, modifier, claim adjustment reason, and remittance remark codes for adjudication semantics.

Together, these transaction schemas, code sets, and identifiers sharply limit ambiguity and make healthcare EDI far more semantically constrained than X12 usage in all other industries. These predictable, deterministic constraints make it possible for machines to handle transactions programmatically – far beyond what is possible outside of healthcare.

But equally important is the existence of clearinghouses as a universally adopted pattern across the payer and provider landscape. Payers have allowed clearinghouses to provide a single connection point for interacting with the fragmented payer landscape, which drastically reduces the integration burden on both sides. Providers can connect once to a clearinghouse and get connectivity to virtually every payer in the country.

When you consider these two qualities – a rich, standardized set of transactions that are deterministically validatable with an instantly-accessible transactional network – it becomes clear that the healthcare industry has already successfully implemented the most difficult and most improbable requirements for a massively automated, reliable, low-cost transactional system.

The way things ought to be

Clearinghouse transactions ought to be a commodity – as cheap and reliable as running water.

For transactions to be cheap and reliable, they need to be automated, and in today’s software-driven world, for something to be automatable, it has to be programmable – that is, accessible and controllable by both traditional software and AI agents. It is based on this premise that we’ve built our platform, and it’s why we call Stedi the only programmable clearinghouse.

And for a transactional platform to be programmable, it needs to be both accessible and validatable programmatically. In other words, external systems must be able to access the platform using machine protocols, and they must be able to get fast feedback on the validity of the payloads that they submit.

We designed Stedi from the ground up to be 100% accessible via API, which means that every action available through the user interface or X12 is also available programmatically using our API. Stedi allows a much deeper level of integration compared to legacy clearinghouses. Beyond just the standard transactional integrations like eligibility checks, insurance discovery, claims, claim status, acknowledgments, attachments, ERAs, and more, we have complete API coverage for common operational needs such as syncing our payer list and processing transaction enrollments. And our MCP server allows customers that are building agentic functionality to accelerate development using the same infrastructure that powers Stedi’s own agent.

While Stedi is built to be API-first, it’s certainly not API-only. We have a rich web portal that offers the same functionality as our APIs, as well as traditional X12-based transaction functionality over SFTP and CAQH CORE SOAP protocols. No matter the method used to exchange transactions with Stedi – JSON API, web UI, or raw X12 file transfer – everything flows through the same modern infrastructure and robust validation checks in our backend. There are no cost differences between our various submission methods – customers pay the same price regardless of the protocol.

For providers that are looking for turn-key integrations, Stedi apps allow them to instantly integrate with our platform partners that include EHRs, RCM systems, patient intake platforms, and more. Providers using these platforms can easily configure their Stedi app for seamless connectivity between both systems.

We’ve invested heavily in transaction validation, too – what the industry calls edits. In today’s world of cloud computing, there’s no reason why edits should be subject to batch delays and take hours to complete – validations such as claims edits should be instant. Like everything else in our stack, we’ve built our edits engine from scratch, and we return all edits instantly via our API and within seconds over SFTP.

We fingerprint, categorize, and triage every single claim rejection and denial that comes through our clearinghouse and build edits or repairs to prevent them from happening again. We do the same for eligibility checks – many common problems can be detected prior to submission to the payer, and we monitor for those too. When customers flag new preventable issues that they notice, we can typically ship an automated repair or instant rejection within hours or days.

Looking ahead

There are dozens of other parallel workstreams that we’re advancing forward. We have the fastest-growing network of direct payer integrations – with hundreds of new direct payer connections in flight at any point and more being added every day – and we work closely with payers to proactively build out new claims edits, improve eligibility check responses, streamline enrollment processes, and more. We’re shipping support for new transaction types and doubling down on functionality for existing ones, and we have major new platform expansions that will be launching over the coming months.

This latest round of funding allows us to continue to accelerate development across our platform and to continue to serve customers with a first-rate support experience. One key to that is continuing to build a world-class team – to that end, we are hiring for dozens of roles across engineering, product, design, operations, GTM, and more. If building for the world of agentic RCM sounds exciting to you, get in touch.