How to Track App Store and Google Play Revenue Together

Once a mobile app launches on both iOS and Android, the question "How much did we make this month?" becomes harder than it sounds.

Apple and Google provide useful reports, but the numbers are not designed as one unified accounting dataset.

Start by preserving the source

Every imported amount should retain its origin:

Apple App Store
Google Play
AdMob
AdSense
Stripe
other

Do not collapse the source after import. You will need it when totals differ from a platform dashboard or bank payment.

Separate activity from finalized financial data

A useful revenue model should distinguish fast operational data from finalized accounting-oriented reports.

For example, platform dashboards may show recent customer transactions before all fees, taxes, refunds, adjustments or currency effects are reflected in a final payout.

The exact terminology differs by provider, which is why a normalized system should preserve both a common category and the original report meaning.

Use a common monthly model

A practical internal schema might include:

provider
period_start
period_end
source_report_type
currency
gross_activity
refunds
platform_fees
taxes_or_adjustments
net_or_proceeds
payout_amount
payout_status

Not every provider fills every field. That is better than inventing values simply to make all rows look identical.

Do not convert currencies destructively

Store the original amount and original currency. If you need a reporting currency, add conversion information separately.

This makes the calculation reproducible and prevents a later exchange-rate change from rewriting the source data.

Reconcile payouts after the period

A useful monthly close can follow this order:

1. import the relevant platform reports,
2. validate the reporting period,
3. separate refunds, fees and adjustments,
4. calculate or read finalized proceeds/earnings where available,
5. match payouts,
6. compare with the actual bank receipt,
7. export a clean period summary.

Avoid false precision

If one provider number is estimated and another is finalized, do not present their sum as a finalized accounting total without clearly labeling the state.

This is especially important for a live "this month" dashboard. It can be useful for operating the business while still being different from the month-end accounting view.

Where Faturatik fits

Faturatik is being built around this exact workflow: bring platform reports into one place, preserve the financial meaning of each source and make monthly review easier.

The product should not replace jurisdiction-specific tax or accounting advice. Its value is creating a cleaner, explainable data layer underneath that work.

The number founders actually need

The useful answer to "How much did my app make?" is not one unexplained total. It is a small set of numbers you can reconcile:

what customers paid → what was refunded → what platforms deducted → what became your proceeds/earnings → what was paid → what reached the bank.