The Cash Gap in GPU Contracts

When I read IREN's arrangements with Microsoft and Dell, I care less about the difference between the two headline values than about when the money changes hands. IREN agreed to supply roughly $9.7 billion of cloud services to Microsoft, using approximately $5.8 billion of equipment from Dell. The customer commitment helps explain why IREN would buy the machines. What I want to understand is how it pays for them before it collects years of service revenue.

My work on contract-level forecasts and investor reports at AUTOCRYPT informs how I approach this. I read the GPU agreements as a cash schedule, following what the operator owes at each stage and what it can expect to receive. The November 2025 disclosure gives enough information to explore that timing, although it does not reveal every actual cash movement.

The payment terms

The provision I am watching most closely is how Dell's payment deadline, which starts at shipment, lines up with Microsoft's tranche payments. Dell's equipment installments were due within 30 days of shipment. Microsoft would make a 20% prepayment before delivery of each applicable tranche, or portion of the service, with later payments offsetting the advance after the tranche's 24th calendar month.

That advance helps finance the equipment, but I cannot treat 20% of the full service value as cash available at signing. The arithmetic gives $1.94 billion, but the contract applies the payment tranche by tranche. To know what was available for each Dell installment, I would need the actual payment dates. And because the advance is offset later, it brings collection forward rather than adding money to the contract.

For the same reason, I would not treat the $3.9 billion difference between service value and equipment cost as profit. It leaves out facilities and operating costs, and it compares years of expected collections with bills due much sooner. My concern is whether the money is there when IREN has to spend it.

I have organized the delivery around the events that change that cash position:

This is as far as the disclosed schedule takes me. Estimating IREN's actual cash balance would require the dates and amounts of its transactions, including costs the contract summary does not fully provide.

When customer acceptance slips

The scenario I most want to test is a delay in customer acceptance after the equipment has shipped. If the supplier still has to be paid on the original date while the customer's payment moves back, the operator has to fund a longer interval, even though the headline contract value could stay unchanged.

A small thought experiment helps me separate that funding problem from profitability. Suppose an operator owes 100 for equipment and has 30 in cash plus a customer advance of 20. It must find another 50 for that payment alone. Now delay a scheduled customer receipt of 10 while operating payments of 2 continue each month. The extra months have to be financed even though the customer still owes the same total. These amounts are illustrative, not estimates of IREN's accounts.

For a real comparison, I would calculate the cash balance at each date and the additional financing needed to keep it above a chosen minimum. The largest shortfall is the peak financing requirement. I track that measure alongside total cost because the cheaper procurement offer could still create the larger funding problem before delivery.

Comparing procurement arrangements

If I were comparing ways to buy GPU capacity, I would start with what happens when delivery or demand disappoints. A fixed reservation might secure the machines I need but leave me obliged to pay for unused capacity. Flexible purchasing could reduce that exposure, but then I would have to establish whether supply would be available when the customer needed it.

I would read those choices together with the advance, supplier deadlines and acceptance provisions. An early customer payment may cover part of the equipment bill. A later supplier deadline may shorten the period that needs financing. Delay credits can add another cost if the service is late. It is their combined effect that determines how much money the operator needs, and for how long.

The hard case is weak demand arriving at the same time as delayed acceptance. I would apply that same scenario to each procurement option, check whether it can still deliver the required service, and compare both total cost and peak additional funding. Assuming on-time delivery for one option and a delay for another would tell me little about the contracts themselves.

Horizon 1 acceptance

IREN's August 2026 announcement that Microsoft accepted Horizon 1 adds a concrete delivery event to these notes. It covers the first 50-megawatt IT tranche. I can now place that acceptance beside the earlier contract terms. Completion of the remaining three tranches and collection of the full contract value are still unresolved.

For the rest of the delivery, I am following the interval between IREN paying Dell and collecting from Microsoft. Knowing that the service has a buyer is valuable. To understand how IREN finances it, I still need the calendar.

Information cutoff: October 5, 2026. The numerical illustration explains payment timing; it does not estimate the company's monthly cash balances.