Reporting across currencies and time zones.

Platforms report in the currency of the account. Run one client in two markets and you have two accounts, two currencies, and one column called spend that contains both.

Add that column up and you get a number with no unit. It is not wrong in any way a computer can detect, so nothing errors, nothing is flagged, and the figure goes into a report and then into a decision. This is the quietest data fault there is, and it arrives the day a client opens their second market.

Converting is easy. Converting the same way twice is the part that needs deciding, and there are four decisions rather than one.

• Which rate

  A daily closing rate, a monthly average, or a rate finance fixes for the year. These are not interchangeable and finance usually has an answer already. Reporting should use theirs, because the alternative is a marketing total that never reconciles with the accounts.

• On which date

  The date the money was spent, or the date the report is run. Only the first is stable. Converting historical spend at today's rate means last year changes every day.

• Applied where

  At ingest, storing the converted figure, or at read, storing the original and converting in the query. Whichever you pick, store four things: the original amount, its currency, the converted amount and the rate used.

• Rounded when

  Convert then sum, or sum then convert. The two give different answers, and the gap surfaces as a report that is off by a small amount nobody can account for, which costs more trust than a large error would.

Converting at read time with whatever rate is current today means every historical figure moves every day. Run a report for a closed month on Monday and again the following Monday and you get two totals, both produced correctly.

A client cannot be told that a finished month has a moving total, so the requirement is not accuracy but reproducibility. Store the rate that was used alongside the figure it was applied to. Then any number in any report can be rebuilt exactly, including the ones you sent last year.

A day is a boundary, and nothing agrees on where it sits. Each platform reports days in the timezone of the account. Your warehouse has its own. Your client's week starts on a day and in a place, and neither is necessarily yours.

The failure is identical: no error, just a Monday containing several hours of Sunday, and a week on week comparison that wobbles for a reason nobody can find. It shows up first on clients whose markets are far apart, and on any metric where somebody looks at a single day rather than a month.

The fix is the same shape too. Keep the timestamp with its zone rather than a bare date, decide one reporting timezone, convert once on the way in, and say on the report which zone the days are in.

Five lines per client, kept with your metric definitions rather than in somebody's head. The reporting currency. The source of the rate. The rule for which date's rate applies. The reporting timezone. Where the week starts.

Without those, two careful people produce two different reports from the same tables and both are defensible. That argument is not resolvable by looking at the data, because the disagreement is not in the data. It is in five decisions that were never recorded.

One currency per metric is a quarter of what AI-ready means here, alongside one name, one type and one grain. The conversion is applied in the transform step, in your own warehouse, so the rule for every client is readable in your own account rather than being a setting inside somebody's reporting tool.

The original amount and its currency stay in the tables next to the converted figure. Because syncs add to the tables rather than replacing them, the rate that applied at the time is still there when somebody asks about a month that closed a year ago.