Loading article…
Loading article…
Last updated on Aug 26, 2026
Revenue Recognition Methods in Maxio Core determine how and when revenue is recognized across contract terms. This article outlines every recognition option, from daily and evenly distributed methods to one-time recognition, so you can align revenue reporting with accounting standards and internal policies.
Each Transaction in Maxio Core has an associated revenue schedule. The revenue schedule is created using the Transaction's start date, end date, and the selected recognition method.

| Recognition Method | Definition |
|---|---|
| Daily | From Revenue Start Date to Revenue End Date. Revenue depends on the number of days in the month. |
| Evenly with prorated partial months | When the Transaction Duration is any multiple of months, the Transaction Amount is first spread evenly over the number of months in the duration, and that monthly amount is applied to each full month between the Start and End Dates. A 12-month agreement, for example, can span 13 months and a 2-month agreement can span 3 months. So, the average days per month in the total Transaction Duration is considered in the proration. Example Transaction: $1200 transaction with 12/02/17 start and 12/01/18 end Revenue: Dec17=$96.77, Jan18=$100, Feb18=$100 ... Dec18=$3.23 |
| Evenly with partial months combined into the first | The Transaction Amount is computed by months not days, and spread evenly over each month for each month between the Start and End Dates. A 12-month agreement never spans more than 12 months and a 2-month agreement would never span more than 2 months. Example Transaction: $1200 transaction with 1/15/10 start and 1/14/11 end Revenue: $1200/12=$100; Jan10=$100, Feb10=$100 ... Dec10=$100; no revenue in the last month of the term |
| Evenly with partial months combined into the last | The Transaction Amount is computed by months not days, and spread evenly over each month for each month between the Start and End Dates. A 12-month agreement never spans more than 12 months and a 2-month agreement would never span more than 2 months. Example Transaction: $1200 transaction with 1/15/10 start and 1/14/11 end Revenue: $1200/12=$100; Feb10=$100, Mar10=$100 ... Jan11=$100; no revenue in the first month of the term |
| All on Start date | All revenue is placed on the Start Date. Again noting that the Revenue Start Date is an independent field but set normally to be the same as the Transaction Start Date. |
| No Revenue | No revenue is created. |
| Evenly over each month | The revenue schedule is computed by dividing the Amount into months not days, and spread evenly over each month for each month between the Start and End Dates. A 12-month agreement could span 13 months and a 2-month agreement could span 3 months. Example Transaction: $1200 transaction with 1/15/14 start and 1/14/15 end Revenue: $1200/13=$92.31; Jan14=$92.31, Feb14=$92.31 ... Jan15=$92.31 |
| Evenly over each month starting in the second month | The revenue schedule is computed by dividing the Amount into months not days, and spread evenly over each month for each month between the Start and End Dates, but starting in the second month. |
| Evenly over the full months with prorated partial months (old calc) | Note: this method remains available but is not recommended. With this method, the revenue is first calculated with the Daily method, and those daily calculations are applied to prorated months if present. Then the remaining amount is spread evenly over each full month between the Start and End Dates. Example Transaction: $1200 transaction with 12/02/10 start and 12/01/11 end Revenue: Dec10=$98.63, Jan11=$99.83, Feb11=$99.83 ... Dec11=$3.24 |
| XX days from Start to End | XX = 30, 60, 90, 120 With this method, the revenue is calculated XX from the Start Date through the End Date using exact days. |
| All on XX days from Start | Places all revenue XX days after the Start Date. XX = 30, 60, 90, 120. |
| All on End date | Places all revenue on the Revenue End Date. |
| All on Order date | Places all revenue on the Transaction Order Date. Note this is the Transaction Order Date and not a Revenue Date! |
| Order to End | Revenue is calculated using the Transaction Order Date (not the Revenue Start Date) and the Revenue End Date. Example 1. Transaction Order Date = 01/10/17 2. Transaction Start Date = 02/01/17 3. Transaction End Date = 01/31/18 4. Revenue Start Date = 02/01/17 5. Revenue End Date = 01/31/18 Revenue is generated using the Daily calculation from Transaction Order Date of 1/10/17 (#1 in the list above) to Revenue End Date of 1/31/18 (#5 in the list). |
| Start to XX days | Useful for recognizing implementations and other one-time fees over a fixed period from the Start Date. XX = 30, 60, 90, 120. Revenue starts on the Start Date and ends XX days later. Example, XX = 30 Transaction: $1200 transaction with 1/1/14 start and 12/31/14 end. Revenue starts on 1/1/14 and ends on 2/8/14; January revenue = $1200. |
| Daily with XX day catch up | Useful for recognizing subscription revenue when you have a contingency such as a money-back guarantee and do not want to recognize revenue during the period when the contract is not assured. XX = 30, 60, 90 With this method, the revenue between the Start Date and XX days from the Start Date is lumped onto the XX day as a catch-up. For example, with Transaction and Revenue Start Dates of 1/1/14 and XX = 30, the first 30 days of revenue are caught up 30 days from the Start Date, on 1/31/14. After that, the schedule uses the Daily method. |
Still need help?
Reach out and our support team will take it from here.