Guide

Why your Apple payment doesn't match App Store Connect — and how to book it

Updated

This guide is for indie app developers and the bookkeepers who close their books. It explains why Apple's payment differs from the proceeds you see in App Store Connect, where each number lives, and one way to book the payment so your books match the bank deposit.

Short version: Apple pays one consolidated amount for each fiscal month. Each region is converted at the exchange rate at payment time, after withholding, input tax, refunds and adjustments. The financial reports and the Payments page each hold part of that picture. Post the payment to a clearing account (a holding account), then match the bank deposit against it.

The problem: the deposit doesn't match

You add up proceeds from App Store Connect reports or dashboards for a period, then look at your bank. The deposit is a different number, and the dates don't line up either. Developers raise this in the Apple Developer Forums: one thread from July 2024 has several developers reporting a payment lower than the proceeds they expected, and in an April 2026 thread a developer reports $343 of proceeds but only $258 paid.

Apple documents the mechanics behind these gaps. The next section goes through them one by one. If a gap is left after you have accounted for all of them, that is a question for Apple.

Why the numbers differ: six reasons, plus bank fees

1. Apple's fiscal months are not calendar months

Apple's financial reports and its finance reports API are organized by Apple fiscal month. The API takes the report date as a fiscal month (API reference), and a month's reports are ready by the first Friday of the following fiscal month (Download financial reports). A total for "October" in a calendar-month spreadsheet therefore covers different days than Apple's fiscal October. The third-party tracker Appfigures describes the calendar as Sunday-to-Saturday weeks in a 5-4-4 pattern per quarter. That is a reverse-engineered description, not Apple's own (Appfigures).

2. One consolidated payment per fiscal month, paid within 45 days

Apple consolidates proceeds in all currencies into one payment for each fiscal month, and pays it within 45 days of the fiscal month's end (Overview of receiving payments). A deposit that arrives in one calendar month therefore belongs to a fiscal month that ended weeks earlier, and it does not map to a single calendar month of sales. Appfigures estimates that the money lands about 33 days after the fiscal month ends; that is a third-party estimate.

3. Each region is converted at the exchange rate at payment time

Apple converts each region's earnings into your bank account's currency at a spot rate up to three business days before the payment is received (Overview of receiving payments). The Payments page shows the rate as Exchange Rate, and only after the payment has been disbursed (Payment information). If you convert sales yourself at the rate of the sale date, or at a monthly average, you get a different figure.

4. Small regions can be carried forward to a later month

Apple applies a minimum payment threshold to each country or region. For the listed bank countries and currencies, such as US/USD, UK/GBP, UK/EUR and most euro countries, it is US$0.02. Otherwise it is US$40. Amounts below the threshold are not paid that month and carry forward (Minimum payment threshold). On the Payments page, carried-forward and returned amounts appear in the Balance column (Payment information). So sales that you can see in one month's report may be paid later, and a payment can include money from earlier months.

5. Withholding tax and input tax are applied at payment

Withholding is applied when the payment is made (View payments and proceeds). On the Payments page, Withholding Tax is the amount withheld and remitted to taxing authorities, and Input Taxes are amounts added to the payment, such as Australian GST (Payment information). Withholding lowers the deposit; input tax raises it. The financial reports do not carry withholding tax (Financial report fields).

6. Refunds and adjustments

In the financial reports, a refund is a row with Sale or Return set to R, a negative quantity and a negative Extended Partner Share (Financial report fields). On the Payments page, Taxes and Adjustments combines withholding tax, input taxes and any adjustments, and hovering shows the breakdown (Payment information).

Plus: bank fees on the receiving side

Apple notes that bank fees may reduce the deposit (Overview of receiving payments). They show up on your bank statement, not in Apple's reports.

Where the numbers live

Two places hold the numbers, and neither holds all of them.

What the financial reports and the Payments page contain
Source What it has What it lacks
Financial reports Per product and country: Quantity, Partner Share, Extended Partner Share and its currency, Customer Price, Sale or Return. Refunds are negative rows. Exchange rate, withholding tax and the amount actually paid. Tax and commission have no column of their own.
Payments page Per region: Units Sold, Balance, Earned, Pre-Tax Subtotal, Input Tax, Adjustments, Withholding Tax, Total Owed, Exchange Rate, Proceeds. Per-product detail.

Extended Partner Share is the line total for each product and country. Partner Share is the customer price minus taxes and Apple's commission, so commission is never shown on its own (Financial report fields).

The exchange rate and the withholding are not in the financial reports or the API. In 2018 an Apple engineer said in a forum thread that neither the API nor Reporter supports exchange-rate or post-conversion data, and a developer reported in March 2025 that it was still missing (forum thread 110931). They are on the Payments page (Payment information).

That page has a small download icon that exports the Payments CSV. Apple's help pages describe the fields on the page but not the CSV file. The icon is reported by developers in the same forum thread, and the open-source apple-slicer project parses that file. Treat the CSV as community-reported rather than documented: its layout can change.

A worked example

Sample data (made up)

The numbers below come from the made-up sample Payments CSV that ships with the Proceeds Ledger demo (financial_report.csv). They are not real Apple data. The file has six paid regions; this example uses three: Americas (USD), Euro-Zone (EUR) and Japan (JPY, with withholding). Earned, Withholding and Total Owed are in each region's own currency. Proceeds are in USD, the bank account currency in the file.

Sample data (made up): Earned to Proceeds for three regions
Region (currency) Earned Withholding Total Owed Rate Proceeds (USD)
Americas (USD) 1,462.26 0.00 1,462.26 1.000000 1,462.26
Euro-Zone (EUR) 722.76 0.00 722.76 1.093400 790.27
Japan (JPY) 156,440 −15,644 140,796 0.006712 945.02
Proceeds for these three regions (USD) 3,197.55

In this file the columns relate like this:

  • Total Owed = Pre-Tax Subtotal + Input Tax + Adjustments + Withholding Tax. Input tax and adjustments are 0 for these three regions, so for Japan: 156,440 + 0 + 0 − 15,644 = 140,796.
  • Proceeds ≈ Total Owed × Exchange Rate, rounded to cents.

Checking each region:

  • Americas: 1,462.26 × 1.000000 = 1,462.26
  • Euro-Zone: 722.76 × 1.093400 = 790.2658, which rounds to 790.27
  • Japan: 140,796 × 0.006712 = 945.0228, which rounds to 945.02

The proceeds add up: 1,462.26 + 790.27 + 945.02 = 3,197.55. The whole sample payment has six regions and totals 4,320.90, so the three regions shown here do not add up to the file's total.

The other regions in the same file show other mechanics from the list above:

  • Australia (AUD) has 46.07 of input tax added to 460.66 earned, so 506.73 is owed.
  • Canada (CAD) carries a Balance of 37.25 into the month: 37.25 + 305.48 earned = 342.73 Pre-Tax Subtotal.
  • Mexico (MXN) is listed in a separate block with no exchange rate and no proceeds, so it is not part of this payment.

See this example in the tool

The sample files hold the numbers above. Every check and download works on them.

How to book the payment

Post the payment to a clearing account rather than straight to revenue or to the bank. Call it Apple clearing.

  1. Post the payment to Apple clearing. Use one journal per Apple payment, with lines for sales (net of Apple's commission), refunds, withholding, input tax, adjustments and currency rounding. Apple's Partner Share is already net of commission, and the reports have no commission column, so this method books revenue net of commission. Refunds get their own line if you split them out using the financial reports.
  2. Match the bank deposit against Apple clearing. When the deposit arrives, match it to the clearing account. Book any difference as bank fees.

The clearing account is there because Xero manual journals can't post to bank accounts. Xero's API documentation says bank accounts and system accounts can't be used in manual journals, and suggests a clearing account instead (Xero manual journals).

The example as a journal

Convert each component of a region at Proceeds ÷ Total Owed for that region, not at the rounded rate Apple displays. For Japan that factor is 945.02 ÷ 140,796 = 0.00671198:

  • Earned: 156,440 JPY × 0.00671198 = 1,050.02 USD
  • Withholding: 15,644 JPY × 0.00671198 = 105.00 USD
  • Difference: 1,050.02 − 105.00 = 945.02 USD, which is the Proceeds figure

Converting at the displayed 0.006712 instead gives 1,050.03 − 105.00 = 945.03, one cent more than Apple paid. A currency rounding line takes up a difference like that. With the Payments CSV alone, every region in this example converts to the exact cent, so the rounding line is 0.00 and is left out. Americas and Euro-Zone have a single component each, so they convert exactly.

If you also load the financial reports, sales and refunds become separate lines, each converted and rounded on its own. Then a one-cent rounding line can appear: in the demo, Japan's 1,052.59 of sales and 2.56 of refunds net to 1,050.03, so the journal adds a 0.01 rounding line to match the 945.02 Apple paid.

Sample data (made up): journal for the three regions (USD)
Account Line Debit Credit
Apple clearing Americas, net proceeds 1,462.26
Apple clearing Euro-Zone, net proceeds 790.27
Apple clearing Japan, net proceeds 945.02
Withholding tax receivable Japan, 15,644 JPY withheld 105.00
App Store sales Americas, 1,462.26 USD earned 1,462.26
App Store sales Euro-Zone, 722.76 EUR earned 790.27
App Store sales Japan, 156,440 JPY earned 1,050.02
Total 3,302.55 3,302.55

Debits: 1,462.26 + 790.27 + 945.02 + 105.00 = 3,302.55. Credits: 1,462.26 + 790.27 + 1,050.02 = 3,302.55. The three Apple clearing debits add up to 3,197.55, the same as the proceeds. Where to book withholding depends on your tax situation, so ask your accountant.

Matching the bank deposit

On the bank side, match the deposit against Apple clearing. If the bank shows exactly 3,197.55, the clearing account returns to zero. Suppose it shows 3,182.55 instead, because of a bank fee of 15.00 (a made-up number for this example). The entry looks like this:

Sample data (made up): matching a deposit of 3,182.55 (USD)
Account Line Debit Credit
Bank Deposit received 3,182.55
Bank fees Difference to the expected 3,197.55 15.00
Apple clearing Clears the three regions above 3,197.55
Total 3,197.55 3,197.55

Cash vs. accrual

This method books each Apple payment as received, at the exchange rate Apple applied. The journal date can be the payment date or the fiscal period end; pick one and keep it. Accrual accounting with month-end exchange rates and a foreign exchange gain or loss is a different method. This guide does not cover it, so ask your accountant which one fits your books.

Check your own payment

Free without a license: the demo, the checks on your own files and the reconciliation CSV. A license unlocks the Xero and QuickBooks journal downloads for your own files.

Sources

Apple's pages were checked on October 13, 2026. They can change, so check the current page before you rely on a detail. The example numbers are made up.

Apple documentation

Apple Developer Forums

Accounting software

Third party

Not accounting or tax advice. Review entries with your accountant before posting.