Ema Raises $77M to Challenge Enterprise Software Budgets

Ema’s September 23, 2026 funding announcement disclosed a $77M Series B led by Creaegis, with Accel, S32 and Prosus increasing their investments and total capital raised reaching $140 million. The Mountain View startup plans to expand its enterprise agent platform, which coordinates HR, IT and finance work across applications customers already use.

According to TechCrunch’s financing report, the round consisted entirely of primary equity, with no debt or secondary share sale; Ema did not disclose its current valuation or annualized revenue run rate, while reported bookings exceeded $150 million across multiyear contracts. Bookings cover contracted value over more than a year and cannot be read as annual recurring revenue. The financing is established, but it does not establish how much existing software or service spending customers have eliminated.

Why the agents compete for software budgets

Ema is selling completed work rather than another place for employees to ask questions. In its HR, IT and finance product outline, the company describes an onboarding request that coordinates payroll, identity, device and email actions, and says it charges for completed work, such as onboarding or a resolved ticket, instead of software seats or model tokens. That pricing puts the cost of an agent beside the cost of processing the same request through existing tools and service teams.

The distinction is between answering an employee and carrying a request to its authorized end. An answer may spare someone a search; a completed onboarding or service request may also remove handoffs between teams and applications. That is the opening behind the headline’s budget claim. It does not mean Ema has already replaced the systems that hold payroll records, manage identities or log tickets. Its proposed workflow depends on access to those systems while it performs tasks across them.

Service spending is part of the same pitch. If an agent can configure a routine workflow or resolve a request inside connected applications, some work previously assigned to an implementation or support team could move to the platform. The commercial consequence depends on the customer’s contracts and staffing, however. A faster process is evidence of operational value; a smaller software or services bill requires a separate, documented change in spending.

Execution still stops at approval boundaries

Finance makes the limits of autonomous work concrete. Ema’s accounts payable workflow description covers invoice intake, matching against purchase orders and receipts, investigation of exceptions, approval routing and updates to existing systems; it also calls for policy thresholds, audit records and human review of sensitive payment changes. This describes the process the platform is intended to handle, not an independently measured result from a named finance customer.

In that design, an agent could collect the records needed to explain a mismatch and send the case to the appropriate approver. It would still wait where policy reserves the decision for a person. The useful boundary is therefore more precise than a choice between full automation and a chatbot: gathering context, applying a permitted rule and writing back an approved change are different from authorizing an exception.

The same distinction applies outside finance. A routine IT request may be resolved through established permissions, while an elevated access grant requires approval. Routing the latter request with its context can reduce coordination work, but the human decision remains part of the process. Counts of requests handled should not be treated as counts of tasks completed without intervention.

Named deployments reach beyond pilots

There are named deployments behind Ema’s production claim. SiliconANGLE’s report describes a Wipro assistant serving more than 240,000 employees in 65 countries and handling about 2.9 million queries a year across roughly 100 workflows, as well as a Hitachi deployment connected to more than 20 enterprise systems. Those accounts support the conclusion that the product is being used beyond a small trial, while their volumes and performance claims remain vendor and customer reported rather than independently audited.

The measures answer different questions. Employees covered indicate potential reach; queries indicate use; connected systems show integration work. None, by itself, shows how often an agent completed a process without escalation. A query answered at the start of a workflow and a change made at its end should not be counted as equivalent evidence of autonomous execution.

Nor do the deployments settle the software replacement claim. The integrations show that Ema can work alongside existing applications. They do not reveal which products a customer has cancelled, which services contract it has reduced or whether a workflow has simply acquired a new coordination layer. Production adoption and budget displacement are related possibilities, but the available figures establish different things.

What the round leaves open

Ema now has fresh equity to pursue a larger market for agents that perform work across enterprise systems. Its pricing model makes completed tasks the unit it wants customers to buy, and the named deployments give that proposition a production setting. The evidence is narrower on outcomes: public accounts do not provide independently verified completion and escalation rates across customers or a documented tally of software and service spending displaced.

The current story is therefore a confirmed financing round backing an agent platform with substantial reported use, not a measured transfer of enterprise software budgets. Customer-verified completion data, approval rates and changes to underlying contracts would show whether the work Ema coordinates is also replacing the spending its agents compete for.