On Thursday afternoon, September 10, Oracle reported the first quarter of its 2027 fiscal year, the three months that ended August 31. The number at the top of the release was $664 billion: the company's remaining performance obligations, up $209 billion from a year earlier, after more than $30 billion of new AI cloud contracts in the quarter alone.1 A few pages further on, the same release reported that Oracle spent $28.5 billion on capital equipment in those three months and that its free cash flow was negative $5.4 billion.1 Both numbers are correct. They answer different questions.
The first number is a backlog: a ledger of promises to pay, sorted by when the revenue should arrive. The second belongs to the funding: the cash that has to be spent on buildings, power and chips before most of those promises can be kept, and the question of whose cash it is. A backlog tells you who has agreed to pay, how much and roughly when. It does not tell you who funds the build. For a company selling capacity it has not yet built, that second question decides who carries the risk if the promises and the capacity drift apart.
My argument is that anyone reading a large backlog should read the funding beside it, and that Oracle's quarter is a clear case, because the answer to "who funds the build" changed in a way the backlog itself does not show. This is not a claim that the $664 billion is soft. It is signed contracts, measured under an accounting standard and disclosed in an audited company's filings. Nor is it a claim that Oracle has promised more than it can deliver, or a view on its shares. The claim is narrower: the backlog is one column of a ledger, and the other column is printed somewhere else.
The backlog records who has promised to pay, and when.
The cash flow statement records who paid first for the capacity behind it.
What the backlog records
Remaining performance obligations, or RPO, is a field defined by the American revenue standard issued in 2014 as ASU 2014-09 and known as ASC 606. The standard asks a company to disclose how much of the price in its signed contracts it has not yet earned, and to explain when it expects to earn it, either in time bands or in words.4 Oracle's own definition is broad: RPO is contracted revenue not yet recognized, and it includes deferred revenue, invoices sent but not yet paid or earned, and amounts still to be billed.3
Oracle uses time bands. Of the $664 billion, it expects to recognize about 13 percent as revenue in the next twelve months, 37 percent in the two years after that, 34 percent in the two years after those, and the rest later.2 In dollars, that is roughly $86 billion in the coming year, about half of the total within three years, and about $106 billion more than five years out. For scale, Oracle's revenue over the past four quarters was $71.8 billion, so the backlog is a little over nine years of it.1
Notice what the field contains: a price, a customer's commitment and a schedule. Notice what it does not contain. There is no column for what it will cost to deliver the service, and none for who pays that cost before the revenue arrives. For a software subscription, that missing column hardly matters, because the product already exists. For capacity that has not been built, it is most of the story.
The other column
An earlier dispatch, Signed before it is booked, looked at the commitments that companies building AI owe: leases signed but not yet begun and purchase commitments, about $3 trillion across nine companies, Oracle among them. It ended on the point that a commitment to pay and a commitment to be paid are not mirror images. This is the other half of that ledger. Oracle's own side is large and dated: as of August 31 it had $288 billion of data center lease commitments not yet on its balance sheet, mostly starting between now and fiscal 2029 and running fifteen to nineteen years.2
The economist Hyman Minsky gave the cleanest description of what a reader is looking at here. In a short 1992 paper he wrote that every business carries two schedules: its liabilities set a time series of payments it has already committed to make, while its assets generate "a time series of conjectured cash receipts."5 The word that matters is conjectured. Oracle's lease payments have dates. Its backlog has dates too, but whether each promise becomes cash depends on the customer paying and on Oracle delivering capacity in time. Minsky's question was always which schedule pays for which, and what fills the gap while the first runs ahead of the second.
He also sorted businesses by how they fill that gap: hedge units, which can meet all their commitments from their own cash flows; speculative units, which must roll over debt; and Ponzi units, which must borrow or sell assets just to pay interest. He noted that more equity in the funding makes the safe category more likely.5 I use his frame here only for its questions, not to put Oracle in one of his boxes. The filings cannot support that kind of verdict, and it is not my place to give one.
A new row in the table
The most interesting line in Oracle's release is in a table near the back, where the company reconciles its capital spending to what it calls its net cash outlay. One row is labeled customer prepayments with a significant financing component for capital expenditures. For the first three quarters of fiscal 2026 it was empty. In the fourth quarter it was $4.6 billion. In the quarter just reported it was $11.4 billion, about 40 percent of the quarter's capital spending.1 In the two fiscal years before that, Oracle had received none at all.3
A prepayment is a customer paying for service well before it is delivered. Under ASC 606, when the gap between payment and delivery is large enough to give one side a real benefit of financing, the contract is treated as containing a loan, and any interest is reported separately from revenue.4 Oracle says it records the effects in deferred revenue and that the interest so far has been immaterial.2
Follow one of those dollars through the filings and it turns up in four places. It is operating cash: of the quarter's record $23.1 billion of operating cash flow, $11.4 billion was this line. It is a liability: total deferred revenue, which is service owed to customers who have already paid, doubled in the quarter, from $15.4 billion to $30.8 billion.2 It is inside the backlog, because Oracle's RPO includes deferred revenue. And it is subtracted from capital spending in Oracle's non-GAAP net cash outlay, which, with a smaller financing item, is how $28.5 billion of spending becomes $18.0 billion.1 Take the prepayments out, purely as an illustration, and operating cash would have been about $11.7 billion against $28.5 billion of spending. Prepayments are real cash under the accounting rules, so that is not a truer free cash flow. It only shows how much of the quarter's cash came from customers paying ahead.
Figure 2 puts the two columns side by side. Over the year the backlog grew by about half, and the share due within twelve months rose from 10 percent to 13 as the first contracts started to be delivered. Quarterly capital spending more than tripled. Until May of this year, all of it was Oracle's to fund. Since then, a growing share has come from the customers who will use the capacity.
Who funds the build, four ways
The release made a careful claim about the new contracts: given how they were structured, they add nothing to Oracle's plans to raise capital.1 On the call that evening, the chief financial officer, Hilary Maxson, said most of the quarter's new contracts came as prepayments or as customers bringing their own hardware, and that the new backlog would not reach capital spending or revenue until fiscal 2028 or later.7 When an analyst, Mark Moerdler of Bernstein, pressed on whether that meant the contracts needed no new capital spending, the co-chief executive Clay Magouyrk drew the line exactly: the equipment still has to be bought. "We said it does not require additional cash from Oracle."7
He then described three ways that happens. Suppliers can be paid through financing arrangements timed to match what customers pay Oracle. A customer can pay for the hardware itself and use Oracle to run it. Or a customer that has raised money of its own can pay Oracle up front.7 The quarter shows a fourth: Oracle's shareholders. Under an at-the-market program set up in February, Oracle sold 141 million new shares in the quarter for net proceeds of $19.9 billion, which is most of why its stockholders' equity rose from $43.1 billion to $67.2 billion.21
Each of these puts the cost of capacity in a different place, and with it the risk of capacity that goes unused. Supplier financing leaves the risk with Oracle but shifts its timing. Customer-owned hardware moves both the cost and the risk to the customer. A prepayment moves the cash to Oracle early but leaves it owing the service, recorded as a liability. New shares spread the risk across Oracle's owners. None of this shows in the $664 billion. Two contracts with identical RPO can sit on opposite sides of this list.
Oracle names the risk plainly in its annual report. If it overestimates demand, or a key customer cannot pay or perform, it could be locked into years of data center commitments, spending and financing without the revenue that was meant to cover them. And, it adds, the terms of its long data center leases typically do not line up with the length and pricing of its customer contracts.3 That mismatch is the gap between the two columns, in the company's own words.
Objections, considered
The backlog is signed contracts, not a wish. Agreed, and nothing here suggests otherwise. The standard asks for a price and a timetable, and Oracle provides both. What the standard does not measure is a customer's ability to pay over many years, or the seller's ability to build in time. Oracle's own risk factor names both. That is a limit on what the field records, not a doubt about the figure.
Prepayments answer the question. A customer paying in advance is the safest funding there is. This is the strongest objection, and it is mostly right. The answer to "who funds the build" really did change this quarter, and in the direction Minsky associated with safety: more of the money came from customers and from equity, not from debt. Two limits remain. A prepayment is not a gift; it is service owed, now $30.8 billion of deferred revenue in total. And the customers able to prepay billions are few, so the funding now depends in part on their own access to capital. That is a change worth noticing, not a warning.
This is the August dispatch again. It is the other side of it. That piece was about what companies owe and where it sits in the filings. This one is about what customers owe a seller of capacity, and who pays for the gap between signing and delivery. Negative free cash flow during a buildout is normal; the question is only whose cash fills it.
A backlog tells you who has promised to pay; the cash flow statement tells you who paid to build.
Before you quote the next backlog
- Ask how fast it converts. Read the time bands, not the total. A backlog nine years of revenue deep means something different if a third of it arrives next year than if an eighth does.
- Ask who funded the build. Look for prepayments, customer-owned hardware, supplier financing and new shares, and see which ones moved this quarter.
- Ask what each side owes if the other stops. A prepaid contract leaves the seller owing service; a lease leaves it owing rent. Neither appears in the backlog.
- Read the liabilities beside the promises. Deferred revenue, leases not yet begun and purchase commitments are the other column. They sit in the notes, a few pages from the headline.
Back to the receipt. The gold lines are the promises: $664 billion, scheduled over years, a little more of it due soon than a year ago. The blue lines are what it took to keep the first of them this quarter: $28.5 billion of equipment, paid for partly by operating cash, partly by customers paying ahead and partly by new shareholders. The backlog is the larger number. The funding is the one that changed.