How to Analyse and Forecast Multi-Cloud Spend with DeepSeek

The short answer: Export the billing detail from each cloud, normalise it to a common shape — date, account, service, resource, tag, quantity, cost, currency — and ask DeepSeek to explain the variance between two periods rather than to summarise the total. It handles Chinese-language Alibaba Cloud exports natively, which is usually the blocking step. It cannot fix untagged resources, and untagged resources are why most of these analyses fail.

The question arrives from finance every quarter and it is always the same one. Cloud cost is up thirty per cent. Why?

In a single-cloud shop this is answerable in an afternoon with the provider's own tools. In the estate this article is about — a Mainland China workload on Alibaba Cloud, something on AWS or Azure for the rest of the region, two legal entities, two currencies — nobody can answer it, and the honest reason is not incompetence. It is that there is no place where the three bills exist side by side in comparable units.

So the answer becomes "cloud is expensive," a number gets forecast by adding a percentage to last quarter, and the actual drivers stay invisible for another three months.

This is a good use for a language model, and DeepSeek in particular, for a mundane reason: Alibaba Cloud billing exports frequently arrive with Chinese product and field names, and the model that reads those natively removes the step where a finance team gives up.

Why a Multi-Cloud Bill Is Unreadable by Design

Not conspiracy — each bill is internally coherent. The incoherence is between them.

The taxonomies do not line up. What one provider calls a service, another splits across three meters and a fourth bundles into an instance charge. "Compute" is not a comparable line item across two clouds without someone deciding what belongs in it.

The granularity differs. One export gives you resource-level detail by the hour; another gives you meter-level daily rollups. Comparing them means aggregating down to the coarser of the two and accepting the loss.

Tax and currency are handled differently. Depending on the contracting entity and region, one bill may be presented inclusive of local tax and another net of it. Amounts land in different currencies, and whether you convert at the transaction date, the month-end rate, or the rate your finance system already booked will move the comparison by more than the variance you are investigating. Pick one convention and write it down.

The entities differ. A China entity paying a China cloud and a Hong Kong or Singapore entity paying a global one produce intercompany recharges, which means the number in the consolidated management accounts is not the number on any single bill.

None of this is hard individually. All of it together is why the question goes unanswered.

Getting Billing Data Into One Comparable Shape

The exports, and what differs between them

All three major providers can produce detailed billing exports rather than just a PDF invoice. AWS's detailed cost and usage reporting delivers line-item data to storage; Azure's cost management exports usage detail similarly; Alibaba Cloud's billing centre exports itemised bills, commonly with Chinese-language column headers and product names when the account is a Mainland China one. Exact file layouts, field names and export options change over time — check each provider's current documentation rather than trusting a schema you memorised two years ago.

Normalise everything to one flat table with the same columns: period, provider, account or subscription, entity, service, resource identifier, tags, usage quantity, unit, cost in original currency, currency, and cost in your reporting currency. That is the whole trick, and it is unglamorous.

This is where DeepSeek earns its place. Give it a sample of the Alibaba Cloud export and your target schema, and ask it to produce the field mapping — including a Chinese-to-English product taxonomy that reconciles, say, 云服务器 to the compute category you use for EC2 and Azure VMs. Have it produce the mapping as a table you keep and reuse, not as a one-off transformation. A mapping you can inspect and correct is an asset; a black-box conversion you re-run every quarter is a liability.

Tagging discipline decides whether any of this is possible

Everything above is mechanical. This part is not, and it is the difference between an analysis and a shrug.

Cost data can only be attributed to a team, product, environment or client if the resources carry tags saying so. Untagged resources appear as cost with no owner, and in most estates that are not actively managed the untagged share is large enough to swallow the answer entirely. A model cannot infer that an instance belongs to the warehouse system; it can only report that thirty-eight per cent of your spend is unattributable, which is itself worth knowing and deeply unsatisfying.

Two things help. Ask the model to cluster untagged resources by naming pattern, creation date, region and adjacency to tagged resources, and produce a *candidate* attribution for a human to confirm — a shortlist, explicitly labelled as guesses. And agree a minimum tag set — owner, environment, cost centre, application — before the next analysis rather than during it. Note that in AWS, tags additionally have to be activated as cost allocation tags before they appear in billing data, which is a common and quiet source of "we do tag everything."

A Worked Example — Explaining a 30% Quarter-on-Quarter Increase

A 180-person company runs its China-facing platform on Alibaba Cloud under a Mainland entity, and its regional systems on AWS under a Singapore entity. Q2 total cloud spend, consolidated, is up thirty per cent on Q1. The CFO wants a cause, not a chart.

Normalising both exports and asking for a variance decomposition — not a summary — produces a breakdown that adds up to the thirty per cent rather than a set of observations.

About a third is currency and calendar, not consumption. Exchange-rate movement between the two quarters plus one extra billing day accounts for a meaningful slice. This is not a saving opportunity; it is an explanation, and separating it out prevents an engineering team being sent to solve an FX problem.

A little under half is a commitment that lapsed. A reserved-capacity commitment expired mid-quarter and the workload reverted to on-demand rates without anything failing or alerting. Nobody was watching a renewal date. This is the largest single item and the easiest to fix.

The rest is real growth plus two avoidable items. Storage snapshots accumulating with no lifecycle policy, and a staging environment scaled up for a load test in April that was never scaled back down. Both had been invisible because both are small relative to the total and neither appears as a distinct line on any invoice.

The last item is the one worth dwelling on. It was found not because the model is clever but because the question asked was "which resources cost more in Q2 than Q1 and why," which is a mechanical comparison nobody had run across two providers at once.

AI-Assisted Cost Analysis vs Native Cost Explorers vs a FinOps Tool

• Cross-provider, cross-currency, cross-entity comparison — AI-assisted analysis wins. It is the one thing native tools structurally cannot do, because each one only sees its own bill.
• Reading Chinese-language billing exports and reconciling the taxonomy — AI-assisted analysis wins, and this is the specific reason DeepSeek suits this task.
• Accuracy of the underlying numbers — Native cost explorers win. They are the source of truth, they reflect discounts and credits correctly, and any AI-derived figure should be reconciled back to them before it reaches a board pack.
• Ongoing monitoring, alerts and anomaly detection — A FinOps platform wins. Continuous monitoring is a product problem, not a prompt problem; you do not want a quarterly manual pass to be your detection mechanism.
• Commitment and reservation optimisation — Native tools and FinOps platforms win. Both model provider-specific commitment options against your actual usage with the vendor's own pricing.
• Explaining the variance to a non-technical finance team — AI-assisted analysis wins comfortably. Producing a written explanation that names causes and attaches numbers is exactly the shape of the task.

The realistic pattern for an SME is to use the model for the quarterly explanation and the cross-cloud view, keep the native consoles as the arbiter of the numbers, and buy a FinOps tool when the spend justifies the licence — which for most companies of this size, it does not yet.

Forecasting Honestly

A trend line through four quarters of a multi-cloud bill will produce a confident, smooth, wrong number. Cloud cost is not smooth, and the ways it is not smooth are knowable.

Commitments are step functions. A reservation expiring or renewing moves the baseline abruptly. Any forecast that does not have the renewal calendar as an input is guessing at the largest predictable movement in the series.

Migrations and one-offs distort the base. Running old and new environments in parallel for six weeks inflates a quarter. Forecasting from a base that includes a completed migration builds the duplicate cost into every future period.

Growth is not uniform across services. Storage and data transfer often grow with cumulative data rather than with headcount or revenue, so a per-employee ratio understates them.

What to ask for instead is a forecast with the assumptions stated separately and each component's basis named — this much is committed and contractually fixed, this much scales with a stated driver, this much is a known project, this much is unexplained variance. Then ask for a range. A single number with no interval is a false statement about the future, and finance teams are far better at handling a range than technical teams usually expect.

Getting This Right — Billing Data Sensitivity, Account Access, and When to Bring in IT

Three practical points before you export anything.

A cloud bill is business intelligence about your company. Resource counts, region footprint, service mix, growth rate and the names of internal systems are all inferable from a detailed export, and taken together they describe your architecture and your trajectory. Treat it as commercially confidential: strip resource names that reveal client or product identities, use the tier whose data-handling and retention terms you have actually read, and — for organisations with Mainland China data-residency obligations — consider where the processing happens as a deliberate decision rather than a default. Self-hosting an open-weight model is a legitimate option when the constraint is real.

Read-only billing access is enough, and is the right ceiling. Nobody needs write access to run a cost analysis. Provider billing roles are designed for this, and granting broader permissions because it was easier is exactly the pattern that turns a finance exercise into a security finding.

Explaining the bill is not the same as changing it. Acting on the findings means rightsizing instances, setting storage lifecycle policies, buying the correct commitments, and knowing which workloads can move and which cannot — including the ones with ICP filing or data-residency constraints that make "just move it" not an option. That is the work of managed IT cloud services, which covers multi-cloud design across Alibaba Cloud, AWS and Azure including compliant hosting in Mainland China. Our AI+ support practice and managed IT support sit either side of it. Brocent has run cross-border IT across Asia since our founding in Beijing in 2007, with headquarters in Singapore and a Hong Kong office since 2016 — which is to say, we have had this exact conversation about this exact estate shape many times. The same normalise-then-interrogate pattern applies to governing Alibaba Cloud security-group rules.

Frequently Asked Questions

Does a cloud bill contain sensitive business information?

Yes, more than most people assume. A detailed export reveals how many resources you run, in which regions, growing at what rate, and — through resource names and tags — often what your internal systems and clients are called. Treat it as commercially confidential, strip identifying resource names where you can, and choose the processing environment deliberately.

How do we compare Alibaba Cloud and AWS line items fairly?

Build an explicit mapping between each provider's product taxonomy and a common category set of your own, and keep that mapping as a reusable document. Aggregate to the coarser granularity of the two. Fix a single currency-conversion convention and state it. Comparisons made without those three decisions written down are not reproducible, which means they will be re-argued every quarter.

Can this find idle or over-provisioned resources?

It can find strong candidates from billing data alone — resources billed continuously with usage patterns that do not match a production workload, storage growing with no corresponding compute, environments named for testing that run around the clock. Confirming that something is genuinely idle needs utilisation metrics rather than cost data, so treat the output as a shortlist to check, not a delete list.

What about currency and intercompany recharges?

Decide the conversion convention first — transaction date, period-average, or period-end — and apply it consistently, because the choice can be larger than the variance you are investigating. For intercompany recharges, analyse at the level of the bill actually paid to each provider, and treat the recharge as a separate accounting step. Mixing the two is how a cost analysis stops reconciling to the management accounts.

Do we need read-only billing access, or is a monthly export enough?

An export is enough to start and is the lower-friction path. Standing read-only billing access becomes worthwhile once you want this monthly rather than quarterly, or want to check something without waiting for someone to produce a file. Read-only is the correct ceiling in either case.

Is DeepSeek specifically better here, or would any model do?

Any capable model can do the arithmetic and the reasoning. The specific advantage is handling Chinese-language product names, field headers and invoice terminology from Mainland China billing exports without a lossy translation step first — which, for a China-plus-global estate, is the step where these projects usually stall. If your bills are all in English, the tool choice matters much less than the normalisation discipline.

Where to Start

Take last quarter and the quarter before it, from one cloud only, and produce the variance decomposition for that provider alone. It is a small enough task to finish in an afternoon and it will tell you immediately what proportion of your spend is untagged — which decides whether the multi-cloud version of this is worth attempting yet or whether tagging is the actual first project. If the answer turns out to be architectural rather than analytical, that is a different conversation, and one we are glad to have: get in touch.