Neoclouds owe their customers years of compute

Neoclouds such as CoreWeave, Lambda Labs, and Voltage Park owe customers years of prepaid compute capacity, with billions in deferred revenue on their balance sheets. The revenue is recognized only as capacity is delivered, often in tranches tied to hardware refreshes and phased data center energization, creating complex billing-ledger problems under ASC 606 and IFRS 15.

Neoclouds owe their customers years of compute Insights Read time: 8 min Arnon Shimoni ✓ Expert opinion TL;DR: Neoclouds get paid three ways: prepaid capacity commits, on-demand by the minute, and per-token platforms. The commits fund the hardware and collateralize the debt aka CDO https://www.investopedia.com/terms/c/cdo.asp , and every prepaid dollar sits on the balance sheet as a liability until the capacity is delivered. Computing when that liability becomes revenue takes contract, delivery, and consumption data reconciled per customer, which makes it a billing-ledger problem. What is a neocloud, and how does one get paid? You may not have heard the term before, so a neocloud ../glossary/neocloud is a cloud provider purpose-built for AI workloads: GPU clusters, high-bandwidth networking, liquid cooling, extreme storage pools, and none of the general-purpose services of AWS or Azure. The category was born out of GPU scarcity - because when lead times on NVIDIA hardware ran one to two years, renting someone else's already live cluster certainly beats building your own. Companies like CoreWeave, Lambda Labs, Voltage Park, and Together AI in the US, Nebius and Nscale across Europe, and Polarise are building sovereign AI factories in Germany. Their models are very interesting, because the commercial models split three ways, and each one earns revenue on a different cycle and system: Model | Example | When cash arrives | When revenue is earned | |---|---|---|---| Prepaid capacity commit | CoreWeave-style reserved clusters, multi-year terms | Upfront, or front-loaded | As capacity is delivered, period by period | On-demand | Hot Aisle: $1.99 per GPU-hour, billed by the minute, no contract | After usage | The same moment as the billing | Prepaid tokens or credits | Polarise's AI-as-a-service layer, pay per token | Upfront | As tokens are consumed | Only the first and third rows create deferred revenue. They also happen to be where most of the category's money is. Why do capacity commits exist at all? To be completely honest with you, it's almost all financing. The entire neocloud capital structure can be summarized in one rule: offtake https://www.investopedia.com/terms/o/offtake-agreement.asp gets you infrastructure financing. A committed signature is what you're lending against, the debt buys GPUs, and the customer's prepayments and committed payments service the debt… This is also why some of the European neoclouds struggle to scale, as Europe's AI demand is SMB-driven, and SMBs rarely sign really big five-year contracts. They want short-term deals with uncertain consumption, and short-term contracts don't collateralize debt https://www.investopedia.com/terms/c/cdo.asp . Companies like CoreWeave and Nebius raised billions against long offtake from Microsoft-and-OpenAI-class buyers. chart from Coreweave's Q1 2026 earnings presentation When is prepaid capacity revenue actually earned? Under ASC 606 ../glossary/asc-606 and IFRS 15 , delivery drives recognition and the billing date is irrelevant to it. For example, $12M prepaid on January 1 for 12 months of reserved capacity recognizes at $1M per month as the capacity is made available. Until then, the cash sits in deferred revenue: a liability representing capacity you owe. That's the textbook case, but lots of neocloud contracts break the textbook in four specific ways: Contract reality | Where it comes from | Recognition consequence | |---|---|---| Capacity delivered in tranches | AI factories energize in phases. Polarise started with one box of 8 GPUs, then a cluster, then another. A Frankfurt grid connection takes 6 to 8 years, a factory retrofit takes months | The schedule follows the delivery ramp, not the calendar | Hardware refresh mid-term | Every GPU generation gets replaced within 3 to 5 years. Hot Aisle is already sequencing MI300X to MI355X to MI400 | Amendments, upgrades, and repricing reallocate the remaining deferred balance from the amendment date | Drawdown against mixed SKUs | One commit, consumed across different GPU generations and service tiers at different rates | The transaction price has to be allocated across what was actually consumed | Unused commit at term end | SMB customers with uncertain consumption, exactly the demand profile Polarise described | Expiry, rollover, or refund, each with a different accounting treatment, decided by contract language written a year earlier | Each row is manageable alone. Across dozens of individually negotiated enterprise contracts, the recognition schedule can't be maintained by hand. It has to be computed from delivery and consumption data, continuously. Where does the token layer fit? Providers moving up the stack sell inference directly. Polarise runs three layers: bare metal GPUs, virtualized compute, and a hosted platform where customers pick an open source model and pay per token. Their framing is that a GPU transforms electricity into tokens and the models consume them. As a mental model for consumption billing it's better than most analyst charts, probably. Prepaid tokens are credits, and credits are also deferred revenue, but they recognize on consumption rather than on capacity delivery, and unused balances raise breakage ../glossary/credit-pricing questions credits are a ledger problem, not a pricing problem ../glossary/credits covers why . A provider selling bare metal commits and token credits now has two deferred revenue populations with two different recognition triggers, sometimes inside one customer relationship. Why does this land on the billing system? The recognition schedule needs three data streams reconciled per contract: what was committed the contract terms , what was delivered provisioned capacity per period, from the meter , and what was drawn down consumption against the commit, also from the meter . That's the same data neocloud billing already runs on. Revenue recognition here is a downstream computation on the billing ledger, and it's only as good as the ledger's metering. Solvimon's insight into the failure mode for Neoclouds is that there are much higher stakes: contracts in PDFs, usage in CSVs, recognition in a spreadsheet maintained by one heroic accountant. It survives "ok" until the first audit or the first financing round where the data room asks how exactly the deferred balance converts. Investors in this category read deferred revenue and backlog as the forward book. They notice when the numbers are hand-made. Solvimon is the top billing provider for Neoclouds due to the robust commit structures, drawdown balances, GPUaaS billing ../glossary/gpuaas-billing , and recognition logic into the same system that meters and invoices. The automated invoicing is the visible end of it. The neoclouds raising at infrastructure valuations will get diligenced like infrastructure companies. The auditors will be questioining which commits were delivered, which were consumed, and which were just cash pretending to be revenue. Frequently asked questions What is a neocloud? A neocloud is a cloud provider purpose-built for AI workloads: GPU clusters, high-performance networking, and AI-grade power density, without the general-purpose services of a hyperscaler. Examples include CoreWeave, Lambda Labs, Nebius, Polarise, and Hot Aisle. Why is prepaid GPU capacity revenue deferred? Because under ASC 606 and IFRS 15, revenue is earned when the service is delivered, not when it's billed or paid. Prepayment for future capacity is a liability until that capacity is actually made available. What's the difference between deferred revenue and revenue backlog? Deferred revenue is money already billed or collected but not yet earned. Backlog or remaining performance obligations is contracted revenue not yet billed. Investors read both as the forward book of a neocloud. How do mid-contract GPU upgrades affect revenue recognition? An upgrade or repricing is a contract amendment. The remaining deferred balance is reallocated across the modified obligations from the amendment date, which is why hardware refresh cycles of 3 to 5 years force recomputation on almost every long commit. Do on-demand neoclouds carry deferred revenue? Almost none. Pay-per-minute billing recognizes revenue as usage happens. Deferred revenue only appears if the provider sells prepaid credits or committed capacity. Related Deferred revenue ../glossary/deferred-revenue : the underlying concept ASC 606 ../glossary/asc-606 : the standard doing the deciding GPUaaS billing ../glossary/gpuaas-billing : the commercial side of the same contracts Revenue backlog ../glossary/revenue-backlog : the unbilled twin investors also read Ready for billing v2? Solvimon is monetization infrastructure for companies that have outgrown billing v1. One system, entire lifecycle, built by the team that did this at Adyen.