AI spending has a habit of starting small. An ecommerce team adds an AI customer-support assistant, merchandising experiments with generated product imagery, search gets smarter, personalization improves, and someone starts testing an internal forecasting model. At first, most of those costs look like ordinary technology expenses.
Then usage grows. A successful AI feature begins running continuously rather than occasionally, engineering wants dedicated capacity, models need more memory, and the business signs a longer infrastructure agreement to make capacity more predictable. Suddenly AI infrastructure costs are large enough for the CFO to ask a reasonable question: is this capex or opex, and what does it mean for our cash flow?
The answer is rarely as simple as “buying hardware is capex and everything else is opex.” For ecommerce businesses, I think the better approach is to separate three questions that overlap but are not interchangeable:
This guide explains how I would work through them before approving a material AI infrastructure commitment.
I would not begin an AI infrastructure review by opening the chart of accounts. I would start with the workload forecast and the cash-flow forecast.
Ecommerce businesses already have unusual demands on cash. Inventory is often purchased before related sale occurs, marketing spend usually precedes the revenue it is supposed to generate, and seasonal peaks can require additional inventory, advertising, fulfillment capacity, and labor at roughly the same time. EcomBalance’s guide to operating cash flow explains why a profitable business can still run into problems when cash is tied up in inventory, receivables, marketing, or growth investments.
The same principle applies to AI. A usage-based AI service rises and falls with activity, dedicated infrastructure creates a recurring contractual commitment, hardware ownership requires a substantial upfront payment, and implementation creates costs before the system produces measurable financial returns.
So the useful question is not just “Is this capex or opex?” but “What does this decision do to our cash position during a normal month, a peak month, and a bad month?” That is a question an ecommerce operator can actually manage.
One mistake in technology budgeting is grouping every AI-related invoice under a single heading such as “AI,” “software,” or “technology.” That makes the reporting less useful as spending grows, so I would separate AI infrastructure costs into four buckets.
| Cost bucket | Typical examples | Main finance question |
| Variable AI usage | Model inference, temporary compute, usage-based services | How closely does cost move with customer activity? |
| Committed infrastructure | Reserved capacity, dedicated systems, infrastructure leases | How much cash remains fixed if demand falls? |
| Owned infrastructure | Purchased servers and supporting equipment | What is the upfront cash requirement and asset treatment? |
| Implementation and software | Integration, internal development, deployment work | Which costs need separate accounting analysis? |
This separation immediately tells management more. You can see how much AI spending is variable versus committed, distinguish implementation from ongoing operation, and compare infrastructure costs with the revenue or savings the underlying AI application is meant to support.
Suppose an ecommerce brand launches an AI shopping assistant. Nobody knows how heavily shoppers will use it. Conversion impact is still being measured. The product team changes models and workflows regularly. At this stage, flexibility has economic value.
If customer activity doubles, variable infrastructure costs may rise. But if shoppers barely use the feature, spending can also fall without leaving the business committed to a large amount of unused capacity.
Finance should track at least three metrics from the start:
The rule that follows is simple: do not make a long infrastructure commitment based on a short usage spike. Black Friday is not an annual average.
The calculation changes when AI becomes part of normal operations. Imagine that the same business now runs AI search, recommendations, support, and internal merchandising workloads every day. Infrastructure consumption no longer disappears between experiments, and the finance team now has enough data to ask whether predictable capacity could make sense.
This is the point where I would stop comparing options on a single headline rate. Instead, I would put both models on the same footing and compare:
Even that is only the beginning, because the two quotes rarely cover the same thing. One provider may supply compute and leave everything else to the customer. Another may bundle physical operations, networking, workload management, and other supporting responsibilities into a single agreement. Those are not economically identical offers, even when the accelerator count matches.
CambridgeNexus (CNEX), a Boston-based operator that leases full NVIDIA GB300 NVL72 racks on a bare-metal basis, sits at the bundled end of that spectrum. It owns and operates the racks, and its agreements cover power, cooling, networking, compute, orchestration, compliance, and workload planning. That scale is well beyond most ecommerce businesses, but the structure illustrates the point.
For a CFO, the interesting question is not the hardware itself. It is how much of the operating environment sits inside the same commercial relationship, and how much is quietly handed back to your own team.
So before comparing a bundled infrastructure contract with a bare compute quote, normalize what each option includes. The lower number is not automatically the cheaper one.
Rack-scale AI carries costs that are easy to miss if finance looks only at accelerator capacity. Power, cooling, networking, facilities, and day-to-day operations all sit alongside the compute itself in the total cost of running the workload, and they do not disappear just because a quote leaves them out. If a proposal makes the accelerator look inexpensive by handing those responsibilities back to the buyer, the CFO’s job is to price them and put them back into the comparison before deciding which option is cheaper.
An ecommerce company could also buy the equipment outright, and this is the clearest illustration of why cash movement and accounting expense should not be confused. The business may write a large cheque when the hardware is acquired, but that does not mean the full amount becomes an expense in the same period. Owned equipment generally goes through an asset and depreciation analysis under the applicable accounting and tax rules, and the cash impact and the reported expense can land in very different places.
I would not build an AI hardware business case around an assumed tax deduction, such as accelerated depreciation, without the tax adviser confirming that the specific equipment and circumstances qualify. The accounting question is only one part of the ownership decision, though. I would also want answers to a set of operating questions:
Accounting can tell you how an asset is reported. It cannot tell you whether buying it was a good decision. A heavily utilized system and an idle one can receive identical accounting treatment while producing very different business results, and the second set of questions above is what separates them.
AI projects create costs before the infrastructure reaches steady-state operation. A business might pay employees or outside specialists to:
I would not automatically put every dollar into an implementation-expense bucket. Accounting guidance can distinguish between different phases and types of software-related work.
Under FASB’s ASU 2018-15, for example, a company that incurs implementation costs in a hosting arrangement that is a service contract has to evaluate those costs under internal-use software guidance (ASC 350-40), rather than assuming everything hits expense immediately. Costs in the preliminary and post-implementation stages are generally expensed; certain application-development-stage costs are capitalized and amortized over the term of the arrangement.
This is why the accounting team should be involved during the project, not only once the invoices arrive. Reconstructing several months of engineering work after launch is far harder than documenting what the team is doing while the project is underway.
This is the accounting misconception I would be most careful about. People often use “opex” as shorthand for leasing or subscribing and “capex” as shorthand for buying. That is fine in an informal planning conversation, but it can be wrong from a financial-reporting perspective. Under ASC Topic 842, the question is not what the vendor calls the arrangement but whether it conveys the right to control an identified asset for a period of time. If it does, the lessee generally records a right-of-use asset and a corresponding liability on the balance sheet, even for what everyone in the room has been calling an operating expense. An agreement for dedicated racks, like the model described in Section 2, may well contain a lease even if the invoice reads like a service subscription.
That means finance needs to review the actual agreement rather than the pitch deck. Questions to work through include:
Do not let the vendor’s commercial terminology answer an accounting question. Have the controller, CPA, or auditor review the contract.
Consider a hypothetical ecommerce business running three AI initiatives at once. Each of them have different demand patterns, and each pattern points toward a different financial model.
The business uses an AI assistant to answer common customer questions, and usage broadly follows order and support volume. That makes it relatively easy to treat as a variable operating workload for management-planning purposes: when orders rise, so does the bill, and when they fall, so does the bill.
The metric I would track is AI cost per resolved ticket, not cost per model request. If the assistant makes five model calls before it resolves one customer issue, counting each call tells management very little about the business result. Counting resolved tickets tells them what they are actually paying for.
The merchandising team generates product descriptions, campaign assets, and imagery. Usage comes in bursts, with heavy activity around catalogue updates or campaigns and very little the following week.
I would be cautious about using this workload to justify a large fixed infrastructure commitment. Peak demand can look impressive on a dashboard while average utilization stays low, and it is the average that a fixed monthly payment has to be measured against.
AI research and recommendations now run across most meaningful shopping sessions. Demand rises and falls with traffic, but there is a persistent baseline that never goes to zero, and this is where infrastructure planning gets more interesting.
The business has historical traffic data and knows its seasonal patterns. It can measure the infrastructure cost of each personalized session and estimate demand several months ahead. In other words, it finally has enough information to compare flexible and committed capacity on the merits rather than on instict.
None of this means Project C automatically needs dedicated infrastructure. It means the shape of the workload, not the enthusiasm around it, should determine the financial model.
If I were reviewing a proposed AI infrastructure commitment with an ecommerce founder, I would build the model in four steps.
Start with every cost required to keep the AI workload operating.
| Cash-flow item | How I would calculate it |
| Contracted infrastructure | Monthly payment from the proposed agreement |
| Variable or overflow capacity | Forecast usage above committed capacity × expected unit cost |
| Storage and data movement | Forecast storage/network consumption × provider rate |
| AI software and tooling | Monthly subscriptions and model-related software |
| Infrastructure labor | Loaded monthly cost of employees allocated to infrastructure operation |
| Implementation | Project schedule × planned implementation spend |
| Security/compliance | Incremental tooling, audit, or consulting cost caused by the deployment |
| Contingency | Explicit reserve for uncertain variable costs |
| Total AI cash requirement | Sum of all items above |
Notice that the infrastructure quote is only the first row. If one provider requires more internal engineering work than another, labor belongs in the comparison.
I would never present management with one single forecast. Use at least three:
Downside case: adoption is slower than expected.
Base case: current usage trends continue.
Upside case: the AI feature succeeds faster than forecast.
Here is a simplified hypothetical example. Assume an ecommerce business is comparing a variable infrastructure model with a fixed dedicated arrangement.
For illustration only:
| Scenario | AI-assisted sessions | Variable infrastructure equivalent | Fixed commitment | Difference before other costs |
| Downside | 320,000 | $19,200 | $30,000 | Fixed is $10,800 higher |
| Base | 500,000 | $30,000 | $30,000 | Break-even |
| Upside | 800,000 | $48,000 | $30,000 | Fixed is $18,000 lower |
These are not market prices. They are deliberately simple numbers showing how to structure the decision. The useful number is the break-even volume.
Monthly fixed infrastructure commitment ÷ variable cost per unit = break-even usage
Using the hypothetical numbers above:
$30,000 ÷ $0.06 = 500,000 AI-assisted sessions per month
Now finance has something operational to monitor. If the business consistently runs above break-even, a committed model deserves closer analysis. If usage sits well below it, flexibility still has financial value. Either way, this is much more useful than arguing abstractly about whether dedicated infrastructure is “cheaper.”
Lastly, put the infrastructure forecast beside the normal ecommerce cash calendar.
| Period | Ecommerce cash pressure | AI planning question |
| Normal trading month | Normal inventory and marketing spend | Does base AI utilization justify the commitment? |
| Product launch | Higher marketing and content activity | Will AI usage rise temporarily or permanently? |
| Black Friday / holiday peak | Inventory, advertising, fulfillment, and support all increase | Do we need temporary headroom or permanent capacity? |
| Post-holiday period | Revenue may normalize while bills remain due | Can the business comfortably carry fixed AI commitments? |
That last row is the one I care about most. The worst time to discover that an AI infrastructure contract is too aggressive is after the holiday peak, when revenue has normalized but inventory, advertising, and infrastructure obligations still consume cash.
Once the break-even model works, I would extend it into a full 12-month schedule. Every row from the Step 1 table (committed infrastructure, variable infrastructure, storage and networking, AI software, implementation, infrastructure labor, and security/compliance) goes across twelve columns, and then four rows are added underneath:
The cumulative line is the one a single-month comparison cannot show you. It reveals how deep the program goes before revenue or savings catch up, and how long that takes.
Then set the schedule beside the company’s inventory purchasing plan and marketing calendar. That is where an apparently attractive infrastructure agreement can look very different. A contract may make sense on annual economics while creating unnecessary liquidity pressure in the wrong quarter, and ecommerce CFOs need to care about both.
Once AI spending becomes material, I would stop treating it as one IT bill and connect each workload to an economic unit the business already cares about. For example:
The phrase “approved asset” is important. If an AI image system creates 20 images and the marketing team uses one, cost per generated image can make the economics look much better than they really are. Finance should measure the output the company actually values.
Each of these is a sign the information gap should be closed before the contract is signed
The positive case is the mirror image of those five signs. I would take a dedicated or leased infrastructure model seriously when all of the following are true at the same time:
At that stage the conversation should move beyond a simple price comparison and on to what the provider actually takes responsibility for, what stays with your team, how expansion works, and how much capacity headroom you are intentionally paying for. Those questions matter more than squeezing a few percentage points out of the headline rate, and they belong on the pre-signature checklist below.
Before approving a material AI infrastructure agreement, I would want written answers to these questions:
If the team cannot answer these, the fix is not to ask the infrastructure provider for a discount. Close the information gap first.
EcomBalance is a monthly bookkeeping service specialized for eCommerce companies selling on Amazon, Shopify, eBay, Etsy, WooCommerce, & other eCommerce channels.
We take monthly bookkeeping off your plate and deliver you your financial statements by the 15th or 20th of each month.
You’ll have your Profit and Loss Statement, Balance Sheet, and Cash Flow Statement ready for analysis each month so you and your business partners can make better business decisions.
Interested in learning more? Schedule a call with our CEO, Nathan Hirsch.
And here’s some free resources:
Capex versus opex is an important AI infrastructure question, but it should not be the first question ecommerce CFOs ask.
The most expensive AI infrastructure mistake is not necessarily paying too much for compute. It is committing to a financial model that does not match how the business actually uses AI.
They can require different treatment depending on what the company buys and how the agreement is structured. Purchased equipment, service contracts, leases, internal software development, and implementation work can all require different analysis. The invoice description is not enough to determine the accounting treatment.
No. FASB Topic 842 requires companies to determine whether an arrangement conveys control over the use of an identified asset. The accounting team should review the actual contract rather than relying on the vendor’s description of the commercial model.
Once AI demand is persistent, measurable, commercially important, and predictable enough to support a longer commitment. The break-even calculation should be based on normal utilization, not a short seasonal spike.
Yes, once the amount becomes material. Separating variable infrastructure, committed infrastructure, implementation, AI software, and internal operating labor makes it much easier to see why costs are moving.
Use a metric tied to a business result. That might be infrastructure cost per resolved support ticket, personalized session, approved product asset, search-assisted order, or completed automated workflow. Cost per compute hour matters to engineering. The CFO also needs to know what the compute produces.
Huge thanks to CNEX for collaborating on this post!
