When moving your subscription management to Iteras, a number of questions arise that are specific to the transition period between two systems. What should you do in your old system right before the transition – for example, should you wait to invoice subscribers who are ready for invoicing until after the switch? What happens when a customer, after the switch, pays an invoice from the old system? How should you handle stopping subscription periods that involve crediting invoices from the old system? These questions are the topic of this article.
Note that there may be differences in how data is imported into Iteras, and therefore there may be variations to the following principles.
Invoicing up to the switch
If you can wait – for a period of time, such as a month – before the switch to invoice subscriptions that are ready for invoicing, it is generally a good idea. This shortens the period in which payments are received for invoices issued by the old system after the switch to Iteras, and reduces the number of payments that need to be handled manually. Iteras registers all payments automatically after the switch, but payments issued from the old system will fail, since the payment ID is not recognized in Iteras. These can then be exported as a CSV file and imported or entered into the old system, provided it is still available.
Invoices from the old system are paid in the old system
Invoices created in the old system should be fully processed in the old system, if practically possible. Iteras generally assumes that for subscriptions migrated to Iteras, the current period is paid (see the next point).
If invoices from the old system turn out to be uncollectible, i.e., never paid, they should be credited in the old system, and the subscription should be manually stopped in Iteras.
Information about invoiced, credited, and paid amounts is transferred to Iteras
Amounts invoiced, credited, and paid in the current period are imported into Iteras. Based on this, Iteras can credit the correct amount when active subscriptions are stopped before expiration. Read more about how this crediting can be done here.
There will typically be a number of issued but unpaid invoices at the time of the transition. For these, there are two options regarding payment information:
You import them as unpaid. This way, when the subscription is stopped in Iteras, no amount will be released for refund to the customer – which is the correct outcome. However, many subscribers who were unpaid at the time of transition will pay their invoice after the transition. This payment will be registered in the old system, but if this approach is chosen, you will also need to update the payment information in Iteras.
If, for some reason, it is impractical to update Iteras with daily payment information for invoices from the previous system in the period immediately after the transition, you can instead choose to fully apply the assumption that all migrated subscriptions are paid, and register them as paid with an amount equal to the invoice amount – even if they are not actually paid. The disadvantage of this is that the stop function will then assume that an amount is available for refund to the customer, which may be incorrect. You can either accept this as a (likely minor) loss, or you can create a solution where you record missing payments in a custom field, which can then be updated with incoming payments (since custom fields are easier to update via import or API than financial fields where payment information is normally stored). If you also cannot update the custom field, you will have reduced the number of subscriptions that require manual checking in the old system for payment status to only those that were unpaid at the time of the transition (statistically about 1/12). Since unpaid invoices are usually resolved within the first month, this transition process will only need to run for a short time.
Stopping a paid subscription from the old system
When a subscription that has been invoiced and paid in the old system is stopped in Iteras (which after the transition can happen for a period as long as the longest subscription), Iteras’ stop function calculates the correct amount to credit, based on the responses given to when the subscription should be stopped and when payment should be made until. Note that the payment information is critical for what the stop function calculates as the credit amount. See more under the point above.
Stopping an unpaid subscription from the old system
Another situation is when a subscription that has been invoiced but not paid in the old system is stopped in Iteras. Since invoices from the old system are typically processed within the first month after the transition to Iteras, this will only occur in the early period.
A particular issue is that the subscription, and thus the delivery, is ongoing. If physical products are involved (and not just digital access, for example), there have been costs associated with delivering the product to the customer. Whether or not there have been costs, the publisher’s policy is often that payment is required for the delivered period. Media policies on this vary, but Iteras will often credit the remaining period and resend an updated payment instruction showing the credited amount deducted from the originally invoiced amount. However, this is not supported when Iteras has not created the invoice.
Therefore, the solution is to create a manual stop with full crediting if the payment has not been entered. If payment has been entered for all, including those who have not actually paid, then you must create a stop without crediting, and issue the credit in the old system. You would then manually create an invoice for the delivered period, with the amount calculated manually for the period delivered relative to the total invoice amount.