What Currency and Billing-Cycle Differences Mean for a Provider Migration

The engineering cutover took an afternoon. The finance consequence lasts a quarter, because the month you switched contains two partial bills that do not add up to a month, in two currencies, converted on two dates.

Four cycle shapes and what each does

Providers bill inference on one of a small number of patterns, and the pattern matters more than the price when you are trying to compare periods.

• Calendar month, arrears. Usage accrues from the first to the last day of the month and is invoiced afterwards. This is the easy case and the one everybody assumes.
• Anniversary cycle. The period runs from the day you signed — the 17th to the 16th, say. Every monthly figure from this provider spans two of your accounting months, so no invoice from it will ever match a calendar-month usage query without splitting.
• Prepaid credits, drawn down. You buy a balance and usage consumes it. There is no monthly bill at all; the cash event is the top-up, which happens when the balance runs low rather than when the month ends. Cost in a month and cash out in a month become unrelated, and if credits expire, some of the cost never corresponded to usage at all.
• Committed spend with overage. A fixed periodic amount covers usage up to a threshold, with anything beyond it billed separately. The marginal cost of a request is zero until it is not, which makes per-request cost meaningless inside the period and makes a month-to-month comparison depend on where in the commitment you were.

A migration frequently crosses shapes rather than staying within one — prepaid credits to a committed contract is a common direction — and a comparison of monthly totals across a shape change measures the shape, not the provider. This is the strongest argument for costing from token counts and a dated price table rather than from invoices, as in the reconciliation procedure.

Why the switch month reconciles to nothing

Suppose you cut over on the 12th. The outgoing provider bills a partial period, possibly prorated against a subscription component, possibly with a minimum that applies in full regardless. The incoming provider bills from the 12th, possibly with a setup or ramp arrangement, possibly with the first period starting on the 1st of the following month instead. Your accounting month now contains: a partial bill, another partial bill, at least one unexpired prepaid balance, and any minimum commitment that did not prorate.

Three things follow, and all three are worth deciding in advance rather than discovering in a variance review. The switch month is not a data point — exclude it from any before-and-after comparison and report it separately as migration cost. Unspent prepaid balance at the outgoing provider is a real number that should appear in the migration cost, not vanish. And any minimum commitment on the outgoing side continues to be payable through its notice period, so the true overlap cost is however many months of parallel spend the exit terms impose, which is a question to ask before signing on the new side rather than after.

There is a subtler boundary problem too. Providers close a usage day at some particular instant, and not all of them close it at midnight UTC. Traffic near the boundary lands in different periods on different sides, which is invisible in an annual figure and clearly visible in the first and last day of any monthly chart. Normalise to UTC in your own records and treat any provider-reported day as a vendor-specific bucket rather than a date.

Three numbers, one purchase

If the two providers quote in different currencies, one API call produces up to three distinct amounts, and confusing them is the most common cause of a comparison nobody can reproduce.

• The quoted amount, in the currency of the price page, derived from token counts. This is the only one you can compute yourself and the only one that is stable.
• The invoiced amount, in the currency the vendor bills in, which may already involve a conversion the vendor performed at a rate and date it chose.
• The settled amount, in your functional currency, after your bank or card issuer converted it at its own rate on its own date, plus any foreign transaction fee.

The gap between the first and the third is not an error and it is not small over a quarter. Two decisions make it tractable. Pick one base currency and one FX policy — a fixed month-end rate is usually easiest to defend, a daily rate is more accurate and more work — and apply it consistently to both providers across the whole comparison window, including retrospectively. And never re-derive historical periods with a current rate: a comparison that changes every time it is run is not a comparison.

Two related items belong in the same conversation. Indirect tax is presented differently depending on where each entity is established and whether a reverse-charge treatment applies, so an invoice total from one provider and another from a different jurisdiction are not like-for-like until you strip tax and compare net. And a provider that bills in your local currency has usually converted at a rate it set, which may or may not track the market — worth asking about, because over a large committed spend it is a price term in everything but name.

Commitments and credits distort the boundary

A committed-spend arrangement changes what a monthly number means in a way that outlasts the migration. Inside the commitment, incremental usage appears free, so any per-unit cost derived by dividing invoice by volume is a function of how much of the commitment you have consumed rather than of the workload. Two months with identical traffic can show different unit costs for that reason alone.

The way through is to keep two figures side by side: the list-price cost of the traffic, computed from tokens and the price table as if no commitment existed, and the actual cash cost. The first is what makes providers comparable and what makes a workload change visible; the second is what finance needs. Report both, and report the commitment utilisation as its own percentage, because an under-consumed commitment on the outgoing provider is a cost of the migration that nothing else in the report will surface.

What to change before you cut over

Very little of this is fixable afterwards, and all of it is cheap beforehand. Ask for the incoming provider’s cycle start and whether it can be aligned to your calendar month — often it can, at signature, and never later. Ask what happens to unused prepaid balance on the outgoing side and get the answer in writing before you stop sending traffic. Establish the FX policy with your finance team and write it into the query rather than into somebody’s spreadsheet.

Then plan a full-month overlap where both providers carry real traffic under the same measurement, so that when the comparison is finally made it is between two complete periods rather than between two halves of a disrupted one. That overlap costs a month of duplicate spend, and it is the cheapest thing in the migration: without it, the answer to “did this save money” is a number assembled from two partial bills in two currencies, and nobody involved will believe it, correctly.