Currency, time zones and periods
Three things break reports without ever throwing an error: money in more than one currency added together, timestamps in a different time zone than the reader expects, and periods that are not the same length. Sort them once, at the start.
Currency
Every order stores the currency it was placed in. Every
market has a base currency,
EUR by default. If you trade in one currency, none of this applies to you and
you can skip to the next section.
If you trade in more than one:
Sums across currencies are meaningless unless converted. A total of "1,240,000" over orders in EUR and CHF is not a number. It is two numbers stacked.
Per-account metrics carry a warning flag. The organization_metrics record
for each account has a currency field and a currency_mixed boolean. On the
organization's Orders tab it appears as Mixed currencies. It is true when
the account has traded in more than one currency, which means its revenue
figures are an unconverted sum. Leave those accounts out of any account-revenue
ranking, or report them separately.
Decide the conversion rule before you need it. There are three defensible answers and you must pick one: the rate on the day of the order, the rate at the end of the period, or a fixed internal planning rate. Finance almost certainly already has this rule for the ERP. Use theirs. Reporting that invents its own FX rule will never reconcile with the books.
Report per market first, converted second. A per-market revenue figure in that market's own currency is always correct. A converted group total is a derived number and should be labelled as one.
Time zones
Order timestamps are stored with their time zone. Reports render them in one. The gap between those two facts is where the errors live.
An order placed at 00:30 CET on 1 July is 22:30 UTC on 30 June. If your monthly report groups by UTC and your Innendienst counts by local date, June and July will both be wrong by a handful of orders: enough to make a month-end number irreproducible, not enough for anyone to notice why.
Fix it by deciding the reporting time zone once, for a German company almost
always Europe/Berlin, and using it in every report, export and scheduled
delivery. Then check the boundaries specifically: pull the orders on the first
and last day of a month and confirm they are the ones you expect.
Europe/Berlin has a 23-hour day in March and a
25-hour day in October. Any report comparing "the same hour last week" or
splitting a day into equal buckets will be off across those weekends. It is not
worth engineering around. It is worth knowing before somebody escalates a
7 percent dip that is a missing hour.Periods
Compare like with like. February against January is a comparison of 28 days against 31, a 10 percent difference before anything happened in the business. For a business that only trades on weekdays, the working-day count matters more than the calendar-day count: some months have 20, some have 23.
The safer default for B2B is a rolling window. The rolling 30, 90 and 365-day figures on each account are the same length every time you look at them, which is exactly why the per-account metrics are built that way.
Partial periods lie. A month-to-date figure on the 4th, shown next to last month's total, will always look like collapse. If a report shows the current period, label it, or compare it against the same number of days in the previous period.
Reporting week is not always calendar week. Germany uses ISO weeks starting Monday; several reporting tools default to Sunday. If your team talks in KW 27, make sure the report agrees on which days those are.
What to check
Pick one account that ordered on the first day of last month, and one that ordered on the last. Confirm both land in the month you expect. Then take any account revenue figure and confirm Mixed currencies is off before you quote it.