Revenue Recognition compatibility

We no longer sell licenses for Revenue Recognition.

ChartMogul’s Revenue Recognition product is tailored specifically for the use of SaaS subscription businesses. It is well-suited for handling subscriptions with differing service periods and allows you to select from a range of recognition strategies. Below are some key considerations when evaluating whether our product fits your requirements.

What you need to know

  • ChartMogul’s revenue recognition engine assumes that your fiscal year aligns with the calendar year.
  • Some prorated items don’t have a service period. They are accounted for from the time of the charge until the beginning of the next subscription period.
  • The system doesn’t have a grasp of the probability of payments being made.
  • As a rule, taxes are excluded from the recognized revenue, though this relies on them having been explicitly provided as a separate item when they were imported. To see how ChartMogul handles taxes depending on the billing system, visit this article.
  • Each payment currency you have received payments in is displayed separately rather than combined into a single set of tables.
  • The maximum service period length we support is ten years.
  • If your data has been imported using our API, ensure you also include the invoice transactions.
  • MRR Data editing will not impact your revenue recognition figures.
  • Currently, the revenue recognition strategy selected will be applied to 100% of the payments received. This means that there are no accruals for refunds. This is how refunds are currently treated:


    1) If the refund amount is up to the amount of deferred revenue of the line item to which this refund belongs, then the refund is spread out according to your recognition strategy to the future only. The service period runs from the day of the refund to the end of the original service period to which the refund relates.


    2) If the refund amount exceeds the remaining deferred revenue of the line item to which this refund belongs, then:

    a) any deferred revenue will be offset by the refund of the same value.

    b) any remaining refund value will be recognized at the time of the refund.

    Refunds will never affect periods that are already closed.

    Examples of how refunds are displayed at the customer level can be seen in this article.

Integration-specific limitations

  • The recognition of revenue around when an invoice was issued (as opposed to when it was paid) is supported only for Recurly.
  • The revenue recognition timing option for recognizing invoices when they are issued is susceptible to data changes. Learn more about data settings in ChartMogul.
  • As customers from Stripe require a successful paid transaction or a free trial for the subscription to be imported, the setting for recognizing revenues when invoices are issued will not work for customers who have not yet had a subscription with a successful payment.
  • As our API integrations do not support partial payments, these can inflate recognized revenue.
  • The Google Sheets integration is unable to process partial refunds. You are limited to issuing full refunds logged on the same day as the original invoice. You’re also unable to send invoices with the status failed or open. Therefore revenue recognition will always occur when invoices are paid. The integration is limited to only one line item per invoice.
  • Our App Store Connect integration only imports subscription revenue. Non-subscription revenue is excluded. Depending on how you selected to import your data, the amounts will either include both Apple’s fees and sales tax/VAT, or neither. You can read more about this in this article.
  • Our Shopify integration only imports non-subscription revenue.
  • Revenue recognition does not support data imported via PayPal’s REST integration, Chargify, Google Play, or for individual customers added via the Customers page.
Was this article helpful?

We’re sorry to hear that. Would you like to share more feedback?


Thanks for your feedback!