About
Revenue recognition reports are not impacted by date selection, and the downloaded list always regards the last full calendar month starting from the third day. For example, on March 5th, you would get a list that would already include transactions from February, while on March 1st it would only include transactions up to the end of January.
March transactions would be available in the report from April 3rd.
The Revenue Recognition reports are automatically generated on the 3rd of each month and can be accessed via the Download Center.
The latest revenue recognition transaction list csv is a log that provides the revenue recognition that results from each of your subscribers. When a subscriber converts on a payment term and you receive revenue, you may wish to treat that revenue as separate installments over the course of user access duration. This prevents you from anticipating future sales because of current growth. For example, if you are a sports news company, you will likely receive increased sales near the date of the Super Bowl, but because this uptake is likely to fade, you might want to spread that revenue out over the year.
Revenue recognition divides the payment up into monthly installments, with each month having a recognized revenue equal to the ratio of the days in that month to the number of days of included access multiplied by the collected revenue. For example, if you sell a 365 day subscription for $365 on January 1st, the recognized revenue in April would be exactly $30, and the recognized revenue in February would be $28 ($29 on leap years). If the subscription begins in the middle of the month, then the recognized revenue for that month is equal to the ratio of the number of days remaining in that month to the number of days of access multiplied by the collected revenue.
Because it is unlikely that the subscription price will be an exact multiple of the number of days of access, the nearest exact multiple lower than the price will be used to determine base revenue recognition. Any remaining revenue is then divided equally over the end of the subscription. For example, if a 365 day subscription costs $100, then each day of the subscription is worth approximately $0.274. Because it is impossible to receive $0.274, each day has a base worth of $0.27. The remaining funds ($1.45) are then split over the last days of the subscription (i.e. $0.01 per day for the final 145 days of the subscription).
This report will only contain information about transactions processed via Piano. In case you have any imported legacy subscribers, their transaction data will not be available in this report. Any transactions will be recognized only after their subscriptions are renewed in Piano directly. The data about the legacy transactions should be available in the 3rd party system that was used to bill them in the past.
The report utilizes different default timezones based on the dashboard locale your application is located on to accurately reflect the data based on regional contexts.
For applications on the EU dashboard (https://dashboard-eu.piano.io/), the timestamps are in Coordinated Universal Time (UTC). For the US dashboard (https://dashboard.piano.io/), the timezone employed is America/New_York. For the AU dashboard (https://dashboard-au.piano.io/), you will observe data aligned with the Australia/Queensland timezone, while applications on the AP dashboard (https://dashboard-ap.piano.io/) will experience data presented in the Asia/Tokyo timezone.
Note: On the third of each month, the revenue recognition transaction .csv will automatically compile in your Download center.
Fields and Descriptions
System Tracking Fields
|
Field |
Column |
Description |
|
External Tx Id |
A |
The unique external transaction ID that Piano receives from the external payment provider. |
|
Term |
C |
The name of the term that the user converted on for the given subscription. |
User Information
|
Field |
Column |
Description |
|
User |
B |
The email address that the user provided upon registering. Note that registration may have happened before the user converted on the term. |
Subscription Information
|
Field |
Column |
Description |
|
Amount |
D |
The listed price of the term that the user converted on. |
|
Access From |
G |
The date on which access began or is scheduled to begin for the purchased subscription. |
|
Access To |
H |
The date on which access ended or is scheduled to end for the purchased subscription. The "Access From" and "Access To" dates are inclusive. |
|
Refund Date |
I |
The date on which the refund to the subscription was issued (if applicable). |
|
Days of Access |
M |
The number of days that the user's access is valid for, not including grace period. |
Payment and Transaction Information
|
Field |
Column |
Description |
|
Currency |
E |
The currency in which the transaction was executed (USD, CAD, EUR, etc.). |
|
Payment date |
F |
The date on which the transaction was executed. Note that this might not be the same as the "Access From" field. |
|
Adjustment |
J |
The amount that you manually adjusted for the given transaction (if applicable). |
|
State |
K |
The state of the transaction (can be either completed or refunded). |
|
Total Recognized |
L |
The amount that you actually collected from the user after accounting for refunds and adjustments. |
|
Monthly Recognized Revenue |
N and further |
The monthly recognized revenue that results from the upfront transaction, as defined above. |