[FR] Add configurable reporting currency for MRR and revenue analytics

[LukasB-DEV]

Feature request

Currently, the displayed currency for MRR/revenue analytics seems to change depending on the currency of the most recently processed or checked order.

For example, if the latest processed order is in EUR, the MRR may be shown in EUR. If the next processed order is in USD, the displayed MRR currency may switch to USD. This can make the analytics view confusing, especially for apps with international users and purchases across multiple currencies.

Suggested solution

It would be very helpful to add a configurable reporting currency option at the project level.

For example:

• Project reporting currency: EUR / USD / GBP / etc.
• All MRR and revenue analytics are normalized into the selected reporting currency.
• The selected currency remains stable until the user changes it manually.
• Original transaction currencies can still be preserved in the raw order/subscription data.

Why this would be useful

Many apps sell globally, so purchases can come in different currencies. For analytics, especially MRR, revenue trends, and consolidated financials, it is important to have one stable reporting currency.

Without a fixed reporting currency, revenue metrics can appear inconsistent or misleading when the displayed currency changes based on the latest order.

Possible implementation idea

A project-level setting such as:

reportingCurrency: "EUR" | "USD" | "GBP" | ...

[hyochan]

Thanks for the detailed request. I checked the current Kit implementation and this is a valid feature request, not just a display bug.

Current state:

• subscriptionStats and revenueMetricsDaily are intentionally keyed by currency so Kit does not add USD/EUR/JPY amounts together without an FX rate.
• The Analytics tab renders one selected currency at a time; when no user choice exists yet, it falls back to the first available currency in the rollup window.
• The Subscriptions MRR card currently exposes a single headline currency chosen from the per-currency MRR breakdown, but there is no project-level reportingCurrency setting or FX conversion path yet.

Before implementing, I am confirming the expected scope in the follow-up comment below so we do not ship a misleading financial total or pick the wrong FX behavior.

[hyochan]

Before jumping into implementation, I want to confirm the intended scope.

Would this solve your use case?

1. Add a project-level reportingCurrency setting, e.g. EUR, USD, GBP.
2. Use that setting as the stable default currency for the Analytics revenue chart and Subscriptions MRR card.
3. Preserve original transaction/subscription currencies on the raw records.
4. For currencies that already match the reporting currency, show them directly.
5. For other currencies, only normalize if Kit has an explicit exchange-rate source; otherwise surface that those currencies are excluded from the converted total instead of silently mixing amounts.

The main design question is whether you need full FX conversion inside IAPKit immediately, or whether the first useful step is a stable reporting-currency default with clear per-currency breakdowns and no automatic cross-currency summing.

A full FX implementation needs us to choose and document the rate source, update cadence, effective date semantics, rounding behavior, and what happens when a historical rate is missing. I want to avoid shipping a misleading financial total if your primary need is simply stable dashboard currency selection.

[LukasB-DEV]

That makes sense.

I also want to clarify one important point: I do not expect IAPKit to produce accounting-grade payout numbers. Apple and Google payout handling can differ from simple transaction-date conversion. For example, Apple’s financial reports apply the exchange rate used for the payment/bank-account currency, while analytics values can be estimates.

So my main concern is not exact payout reconciliation.

The immediate issue is that the current MRR card appears to already aggregate subscription amounts across different currencies, but then displays one currency label, seemingly based on the latest processed order. For example, it may show MRR HUF 34.08, even though the underlying subscriptions may include EUR, USD, HUF, etc.

That is misleading because different currencies should not be silently summed without conversion.

For the first iteration, I think the safest behavior would be:

• Do not mix different currencies into one MRR total without explicit FX conversion.
• Keep a stable project-level reportingCurrency for the dashboard.
• If FX conversion is not available yet, include only subscriptions matching the reporting currency in the main MRR card.
• Show other currencies separately as a per-currency breakdown or clearly mark them as excluded from the converted total.
• Preserve the original transaction/subscription currency on the raw records.

Full FX conversion can be added later, but it should be clearly documented as an estimated analytics conversion, including the rate source, update cadence, effective date semantics, and rounding behavior.

[hyochan]

That clarification helps. I will take this in the minimal no-FX direction:

• project-level reportingCurrency
• main MRR/revenue surfaces use only rows matching that reporting currency
• other currencies remain visible as a separate breakdown / excluded set
• no silent cross-currency summing
• raw subscription / transaction currencies stay unchanged

IAPKit will not do FX conversion or payout reconciliation; store financial reports / accounting systems are the right place for that.

[hyochan]

Implemented the minimal no-FX iteration in #136: #136

What changed:

• Added a project-level reporting currency setting.
• New projects default to USD; existing projects fall back to USD until changed in Project Settings.
• The Subscriptions MRR headline now includes only MRR already in the reporting currency.
• Non-reporting currencies are shown separately and explicitly excluded from the headline total.
• The Analytics revenue view defaults to the project reporting currency and shows a notice when other currencies are excluded.
• Raw subscription / transaction currencies are preserved.

IAPKit does not do FX conversion or payout reconciliation; use store financial reports / accounting systems for currency conversion.

[hyochan]

Adjusted #136 to match the minimal IAPKit scope: FX conversion is not planned as part of IAPKit.

The PR now documents the product stance directly:

• reporting currency is a stable dashboard filter/label for main MRR and revenue views
• IAPKit does not convert currencies or reconcile payouts
• non-reporting currencies remain visible separately and excluded from the main total
• store financial reports / accounting systems remain the right place for payout currency conversion