Currency and Converted Amounts
This page explains how Opactiv handles cost figures that a provider billed in a currency other than the one your organisation reports in, and how converted amounts are disclosed wherever they appear.
The primary goal of the Opactiv platform is to support as timely and useful financial information as can be provided under the circumstances in order to support technology spend decision making.
1 Why this exists
Your organisation reports in one currency, chosen when the organisation is set up. Your cloud providers do not necessarily bill in that currency. An AWS payer account can invoice in US dollars while the organisation reports in Australian dollars, and a single organisation can hold several data sources that each bill differently.
Additionally, a cloud provider can invoice in one currency (for example at month-end), but provide interim cost values in a different currency inside regularly imported cost/usage report files.
Every figure that spans more than one data source is affected by this: organisation totals, pool totals and pool limits, forecasts, budget and constraint evaluation, breakdowns by service or region, and the figures used in scheduled reports. If the provider’s own numbers were simply added together, the sum would be arithmetically meaningless and would still be displayed with your organisation’s currency symbol, understating spend from the cheaper-currency sources by roughly the exchange rate (and vice-versa for more-expensive currency sources).
Opactiv therefore carries a currency dimension through the whole expense pipeline. The purpose is to make single-currency reporting as meaningful and traceable as reasonably possible, and to avoid reporting in several currencies at once. See section 12.
In order to accomplish this, Opactiv must use conversion rates that will probably not match the exact rate values eventually used by the service provider for example at month-end. Additionally, daily rate variations will have an impact on costing in comparison to application of the rate in effect at month-end across all charges. These and other factors will affect total financial accuracy.
2 One reporting currency, applied at import
Every cost figure Opactiv stores for reporting is denominated in your organisation’s reporting currency. Conversion happens once, when the data is imported, not when a page is drawn.
This matters for two reasons. A figure you read yesterday does not change today because exchange rates moved, so a dashboard, a report and an alert that were generated at different times agree with each other. And budgets, pool limits, forecasts and alert thresholds are all expressed in the reporting currency, so they are compared against figures in the same currency rather than against a mixture.
3 What is kept alongside each figure
Conversion never discards the provider’s own numbers. For every expense row Opactiv retains:
- The provider’s original amount
- The provider’s own currency code
- The exchange rate that was applied
- The date that rate belongs to
These are written on every row, including rows where no conversion was needed, in which case the rate is recorded as 1.0 and the original currency is the same as the reporting currency. Every row is therefore self describing, and any figure can be traced back to what the provider actually reported without going back to the provider.
4 The rate that is used
Conversion uses the European Central Bank daily reference rate for the date the usage occurred, retrieved and cached by Opactiv.
The usage date is used rather than a month-end rate deliberately. A month-close convention would convert every day of a month at the previous month’s rate, which is both more operational work and less accurate for every day except the close itself.
For anyone reconciling against an accounting system: in cases where currency conversion is necessary daily rates will not reconcile exactly with an accounting process that closes at a single month-end rate, and a per line item conversion will never equal an invoice total converted at the invoice rate. This is why converted figures are always presented as indicative. See section 6.
5 Which data sources are converted
For AWS, Azure and GCP the billing currency is read from the provider’s own data rather than from a setting, because that is where the truth is. For the AI providers, Snowflake and OVH the currency is declared by the integration and conversion already happened at ingest.
A data source is expected to be single currency. If records within one import declare more than one currency, the import stops with a message that says so rather than summing them. That is a situation a person has to resolve, not something Opactiv can decide.
6 Where conversion is disclosed
Wherever the console presents an amount that involved conversion, it says so, and the disclosure always carries the words “indicative only”.
Where nothing was converted, nothing is shown. An organisation whose every data source bills in its own reporting currency sees no markers anywhere, and this page describes behaviour it will never encounter.
The form the disclosure takes depends on how much room the surface has:
- On summary tiles and cards: a marker beside the figure that resolves to the full wording on hover or on keyboard focus
- In tables: a “Converted (indicative)” label in the column header rather than on every cell, so numeric columns stay aligned and readable
- On charts: a footnote marker beside the chart with the wording beneath it, because a chart drawn to a canvas cannot carry text inside it
- On the Cost Explorer PDF export: a single page level note covering every money figure on the page, since a saved document has no hover
A marker is never an icon alone. An icon cannot say “indicative only”, so every marker resolves to real text, and footnote markers are programmatically associated with their footnote so that keyboard and screen reader users reach the same wording as everyone else.
7 What the disclosure actually says
For a total, the wording names the currencies that were converted into the total and the rate basis used, for example “includes amounts converted from USD and EUR at ECB daily rates”.
It does not name a single rate, and this is not an omission. A pool or organisation total blends many rows from several data sources, converted at each row’s own daily rate, so there is no single source amount and no single rate that would be true of the total. Naming the source currencies and the basis is the honest statement; naming one rate would not be.
8 Data source billing currency
A data source’s details show the currency that data source actually bills in, read from its own data. This can legitimately differ from your reporting currency, and for Azure it can also differ from the currency the subscription is priced in, which is normal: Azure commonly prices in US dollars and bills in the local currency.
9 Cost and usage exports
Exports carry the provider’s own billed amount and the provider’s own currency code, per row. They do not carry converted figures.
For the FOCUS export this is a conformance requirement, not a preference. The FOCUS BillingCurrency column means the currency the provider invoiced in, so a converted figure under it would be wrong. FOCUS is per row multi currency by design, so one file can legitimately carry Australian dollar Azure rows beside US dollar AWS rows, and a consumer reading the currency column per row cannot be misled.
The practical consequence: for an organisation with data sources in more than one currency, an export total will not equal a console total, and it is not supposed to. The export is what the providers invoiced. The console is your reporting currency view of it.
10 When a rate cannot be retrieved
If no rate is available for a conversion that is required, the import stops and the data source reports a failure that names the rate problem specifically, rather than storing an unconverted amount that would look like a valid figure. Data already imported is unaffected, and re-running the import once rates are available completes the period.
If the rate for a specific past date cannot be retrieved but a current rate can, the current rate is used as a temporary stand-in, marked as an approximation, and retried on later import runs until the real rate is obtained. Because the provider’s original amount is retained on every row, such a figure is corrected by arithmetic rather than by re-importing from the provider.
11 Choosing the reporting currency
The reporting currency is selected during organisation setup, while no external data source is connected. Once a data source exists the selection is fixed, because changing it would re-denominate the organisation’s entire cost history along with every budget and threshold expressed in it. Contact Opactiv if an established organisation needs its reporting currency changed.
12 What this is not
Opactiv reports in exactly one currency per organisation. It does not offer a per pool, per user or per viewer reporting currency, and it does not offer a consolidated view spanning organisations that report in different currencies.
This is a deliberate scope decision rather than a gap. Genuine multi-currency reporting is a core financial governance capability: it requires an operator controlled rate source with an approval workflow, rate pinning per accounting period so a closed month cannot move, a translation convention defined per use and applied consistently across expenses, budgets, forecasts and recommendations, reconciliation reporting against provider invoices, and restatement handling when a rate is corrected after a period closes. Opactiv is a cost visibility and optimisation platform, not a core financial platform, and a partly governed multi-currency capability would produce figures that look authoritative to a finance function/audience while being unreconcilable.
What is delivered instead is correct single-currency reporting with the provider’s original amount, currency and rate retained on every row, so provenance is never lost.
13 Availability
Some parts of this behaviour depend on your deployment and on when your data was imported.
Periods imported before conversion was enabled for your organisation may still hold the provider’s own amounts. Such figures are identifiable, because rows carrying no currency provenance are a distinct state from rows that were not converted, and correcting them is an operator run rebuild of the affected data sources rather than something that happens automatically.
Scheduled email reports do not yet carry the conversion disclosure. Treat money figures in an email for a mixed-currency organisation as indicative, and read the console for the disclosed version.
A small number of console surfaces do not yet disclose: the AI usage pages, which run on a separate cost pipeline, the tag breakdown table, the data source summary tiles, and the PNG download of a chart, which captures only the chart image and so cannot include a footnote. Where a surface does not disclose, it is showing the same converted figure as everywhere else; what is missing is the wording, not the conversion.
Visibility of the individual rates that were applied, and the ability to override a rate for a period with one your finance function considers authoritative, are not yet available.
