Regarding revenue & release reporting and royalties

Development Platform & Builds
, , ,
1

We wanted to get some authoritative answers from Epic regarding revenue reports & royalties:

  1. Regarding quarterly revenue reporting: Some platforms (ex. Apple via App Store) use reporting periods that don’t line up with calendar months/quarters (for example, [edit] Apple’s last financial report for us was for Feb 5 thru March 4, 2017). Is it sufficient to report revenue from, for example, all statements with an end-date within Jan 1-Mar 31, Apr 1-Jun 30, Jul 1-Sep 30, Oct 1-Dec 31 to Epic within Q1,2,3,4 respectively, as long as we are consistent?

  2. For currency conversion purposes, is it sufficient for reporting to Epic to use the conversion rates provided by the platform on disbursement (in this example, Apple)?

  3. How exactly does Epic define a single “Product” for the purposes of the $3000 per-quarter per-Product exemption, and for the purposes of notifying Epic of releases? Is it, for example, by distinct Apple app ID, Apple bundle ID/Google package ID, or similar unique identifier for various distribution platforms?

  4. The forms provided by Epic for notification (Release Form - Formstack) and royalty reporting (Unreal Engine Royalty Form - Formstack) are not encrypted/secured using HTTPS. Does Epic have secure methods for reporting this data?

  5. 45-day deadline: Is there a separate deadline for the reporting procedure vs. the actual payment to Epic? As long as the report is made within 45-days of calendar-quarter-end, will the payment also be made on time?

  6. Does Epic have a W-9 for us to keep on file? (We are US-based, so “Epic Games, Inc.” particularly)

  7. Do we need to do a notification to Epic before we do any alpha/beta/pre-release to end-users outside of our company (for example, if we use Apple’s external testing TestFlight)? Does the answer change if all the pre-releases are zero-revenue (no ad revenue, no game license/IAP revenue)?

  8. If our alpha/beta/pre-releases are all free (no ad revenue, no end-user license/IAP revenue), do we need to thereafter repeatedly report a $0 revenue until full release?

  9. When we do eventually release the production game to the public, is that a distinct Product to notify Epic of, or is the initial pre-release notification sufficient?

2

Ping - anything here?

3

This is in the right hands and you should get an answer by mid-week.

4

Sorry for the delayed response! Below are the answers to your questions. Hopefully this helps provide a little more insight into the process. If you have any other questions please let us know!

  1. You should report revenue for all statements you receive or have the ability to obtain (i.e. download from your distributor’s website or portal) by the end of each calendar quarter’s reporting period, for the given three months being reported. Based on your example above, your February 26, 2016 through March 25, 2016 reporting from Apple would be included in your Q1 royalty report. Your December 26, 2015 through January 25, 2016, and January 26, 2016 through February 25, 2016 Apple reports would also be included. You do not need to calculate an accrued revenue balance for the remaining six days in March, or reduce your revenue by the extra six days included from December. The gross revenue associated with these three reports would be used to calculate your Q1 2016 royalty due.

  2. Yes, you can use the converted USD balance per your distributor’s report.

  3. Yes, each Apple app ID, Apple Bundle ID/Google package ID would be considered a single product. Each individual in app purchase within one product ID is NOT considered a single product.

  4. We are currently looking into this for you. However, for the time being this is our only available option for submitting game release and royalty statement information.

  5. The 45 day deadline applies to both reporting and payment.

  6. Yes, we can provide you with a copy of our W-9. Just send your request to help@epicgames.com.

  7. You should notify Epic of your game release once your game is expected to generate revenue. If your alpha/beta/pre-release phase generates income, then you should notify Epic of that release date. There is an option for comments at the bottom of the release form. If you know the approximate official release date of your game, you can provide that information there. If your game does not generate any form of income during the alpha/beta/pre-release phase, you do not need to report that specific release date. You would then wait and notify Epic once your game is officially released.

  8. You do not need to report royalty until your total gross revenue for a given quarter exceeds $3,000.

  9. Refer to question 7 above. If you did not previously notify Epic of our pre-release, you should notify Epic of your official release date now.

Thanks!

5

Thank you for the detailed responses @bdavis - apologies for the lengthy questions, we just want to make sure our accounting records will line up with Epic’s interpretations of the EULA, and my quick guess from Google is that you are an accountant for Epic. :slight_smile:

Because my follow-up is too long for the forum, I’ve split into 2 parts.
Part 1 - Re: your responses:

On Qs #1, 2, and 5: Re: the interaction between the distributor’s financial reports, currency conversion and the 45-day deadline, to be specific: In determining which revenue falls in which calendar quarter for Epic royalty purposes, which date should we look to being within the quarter: (a) the customer sales end-date for the report, or (b) the date we actually have the final numbers including the currency conversion rates (which is usually the day of or before disbursement). (For example, the last 2 reports we have received, the final USD numbers were reported 32 days after the end-date.)

On Q#3: Yes, this looks like our interpretation. For a single Apple app ID or Google package ID, a single Product covers all of: the initial sale price of the app itself, the revenue we receive from ad placements shown within that app, and the purchases of in-app items within that app. Correct?

6

Continuing my follow-up to @bdavis. Part 2:

For app/in-app sales, Epic states “gross revenue” for the purposes of EULA royalties includes the commissions paid to the app platform/distributor.

(a) Does gross revenue also include VATs/GSTs/and similar taxes when included in the “customer price” as reported by the distributor to us, or may we exclude those?

(b) Are we allowed to exclude from gross revenue the returns/refunds? For example, if the customer pays $2.99 for an app, then refunds the app for -$2.99, does Epic count that as $0 gross revenue or still $2.99?

Let me give another detailed example of why (b) matters. Let’s say we have an app using Unreal (App 1), we have some other app not using Unreal (App 2), and a bundle that includes App 1 and App 2 (Bundle 3). From your definition of Product, it appears there are two Products we would report and owe royalty on, App 1 and Bundle 3.

When a user buys App 1 for $1.99, and then uses the App Store’s Complete my Bundle feature on Bundle 3 to for example get App 2 for say an extra dollar, we’d see accounting for:
(i) the original $1.99 sale of App 1;
(ii) a -$1.99 return/refund of App 1;
(iii) a bundle $2.99 sale of Bundle 3;

We’d believe in this case we’d report {App 1: $0 gross revenue; Bundle 3: $2.99 gross revenue} and not {App 1: $1.99 gross revenue; Bundle 3: $2.99 gross revenue}. Correct?

(to be clear, we aren’t asking for accounting advice for our own accounting/tax definitions of these terms, we just want to make sure we’re on the same page as Epic re: EULA definitions)

7

Regarding your first follow up question, You should us the customer sales end-date for the report. For example, Q1 2017, you have sales reports from Apple showing sales during January, February and March. The January and February sales data and payment should most likely be reported and paid to you within that first quarter time frame, so there should be no issue with that information. March data is likely available to you sometime in April. Given our Q1 2017 deadline for reporting and payment is May 15, 2017, this should provide sufficient time for gathering all data for January, February and March to be reported for Q1.

On Q#3: Yes, this looks like our interpretation. For a single Apple app ID or Google package ID, a single Product covers all of: the initial sale price of the app itself, the revenue we receive from ad placements shown within that app, and the purchases of in-app items within that app. Correct?

You are correct.

For app/in-app sales, Epic states “gross revenue” for the purposes of EULA royalties includes the commissions paid to the app platform/distributor.
(a) Does gross revenue also include VATs/GSTs/and similar taxes when included in the “customer price” as reported by the distributor to us, or may we exclude those?

Yes, you may exclude these. The term “commissions paid to the app platform/distributer” is referring to the platforms distribution fee, for example, the 30% distribution fee paid to Apple. You may deduct VAT, taxes, refunds and returns.

(b) Are we allowed to exclude from gross revenue the returns/refunds? For example, if the customer pays $2.99 for an app, then refunds the app for -$2.99, does Epic count that as $0 gross revenue or still $2.99?

You are allowed to deduct refunds and returns. In your example that would be considered $0 gross revenue.

Let me give another detailed example of why (b) matters. Let’s say we have an app using Unreal (App 1), we have some other app not using Unreal (App 2), and a bundle that includes App 1 and App 2 (Bundle 3). From your definition of Product, it appears there are two Products we would report and owe royalty on, App 1 and Bundle 3.
When a user buys App 1 for $1.99, and then uses the App Store’s Complete my Bundle feature on Bundle 3 to for example get App 2 for say an extra dollar, we’d see accounting for: (i) the original $1.99 sale of App 1; (ii) a -$1.99 return/refund of App 1; (iii) a bundle $2.99 sale of Bundle 3;
We’d believe in this case we’d report {App 1: $0 gross revenue; Bundle 3: $2.99 gross revenue} and not {App 1: $1.99 gross revenue; Bundle 3: $2.99 gross revenue}. Correct?

You are correct.

If there’s anything else we can help with just let us know!

8

Thanks @bdavis - last follow-up for now. Due to Apple’s fiscal reporting months (and thus the customer sales end-dates) not lining up with calendar months, in 2017:

  • Jan 1-Mar 4 sales fall into Calendar Quarter 1, (ex. the sales of Mar 5-Mar 31 are reported in a monthly statement with an end-date after Mar 31)
  • Mar 5-June 3 sales fall into Calendar Quarter 2,
  • June 4-Sept 30 sales fall into Calendar Quarter 3 (and the rest is not public to us yet)

While this means the rough number of days reportable in each quarter varies, I don’t see another consistent way of reporting financial statements with end-dates on or before Mar 31, Jun 30, Sept 30, Dec 31, etc. Sounds good?

9

That’s totally fine. It sounds like your Q1 2017 reporting would include most of December, January and February. As long as you remain consistent in your reporting each quarter, we should be fine on our end.

10

Thanks @bdavis - we’ll stick with using the sales End-Date for determining the quarter consistently.

11

Actually @bdavis - Q1 2017 would not have included any of 2016 December, just Jan 1 2017 thru Mar 4 2017 as said above, b/c the monthly report for 2016 December ended exactly on Dec 31 2016. We’re at the mercy of whether Apple decides to make the fiscal months end on, before, or after calendar months/quarters, and looking at FY 2016 and FY 2017, they change their minds year to year. Regardless, all sales will be counted in some quarter, just each quarter may have different number of days as per the example in my comment above.

12

Got it, that should be fine. Thanks!

13

Perfect. thanks

14

@bdavis I was looking for an information and came here and got a lot more information. I want to know few more things:

  1. How gross revenue will be calculated on sale period, if I want to give discount for a specific period. For example,
    a. Price for a product is $100. I’m giving a coupon of 50% off. So specific customers are buying that product with $50.
    b. Same product, we are offering that 30% off to all customers during whole December.
    How the gross revenue is calculated over these two scenario?
  2. Assume I’ve submitted royalty reports and payment for Q1. Then I got gross revenue less than $3000 on Q2. But again got over $3000 in Q3. Here, if I don’t have to submit reports for Q2, but still submit lifetime reports with Q3 reports (I saw that epic needs to know life to date number of sales). So how epic will determine that developer was not eligible for revenue during Q2.
  3. I’m still confused about pre orders. If pre orders are taken, should we pay royalties during pre order period or after releasing the product.
  4. For crowd funding (not sale or pre order or game access or anything, without any benefits), will it be counted as revenue?

Thanks

15

Hello @sohan5005,

Thanks for your questions. I hope these answers help.

  1. Gross revenue for royalty calculation would be calculated at the price you sell the product. So discount will be included for periods of sales. If you sold the game for $50 instead of $100, thats $50 in gross revenue for that sale.
  2. When you report Q3, feel free to report for Q2 as well (even if its below $3000) using our submission forms here: Unreal Engine Royalty Form - Formstack You can also choose to mention Q2 was under the $3000 sale threshold when you report a later quarter.
  3. If pre-orders are taken, please report royalties on them in the quarter in which they were earned/sold. This also means if your quarterly royalties/preorders are <$3000 you do not owe anything.
  4. If crowd funding does not effectively count as a pre-order to access the game (i.e., no game code or access is provided for the reward tier) then they are not included for royalty calculation. If a crowdfunding tier partially includes game access, the portion of that tier relating to the game access will be used in royalty calculation. Typically one of the lower tiers in crowdfunding, which often rewards access, will suggest a price for the game we use for royalty calculations.