Invoicing process illustrated

This chapter outlines the information needed to understand how service charges, credits/refunds and payments are used in the invoicing process and how they are reflected in the attributes of the invoice (such as the amount due). The process is explained using different scenarios.

PortaBilling provides a flexible and easy-to-use invoicing system, covering various scenarios of likely interactions with customers. An administrator can specify:

• The invoice grace period (this indicates within how many days payment must be received following an invoice’s date of issue).
• When to send reminders about an approaching due date or overdue payment of an invoice.
• When a customer’s service should be suspended.
• When to permanently close a customer’s account.

An invoice is a PDF document reflecting all transactions (calls, payments, refunds, subscription charges, etc.) which have occurred during the billing period.

 For the sake of simplicity, we will use “calendar” billing periods in the following examples (i.e., the billing period starts on the first day of the month and ends on the last day of the month). However, the principles described here will work with any other billing period – monthly, weekly, etc.

An invoice’s status can be one of the following:

• Unpaid – the normal status after invoice generation; the customer is expected to pay the amount due (calculated as the sum of the previous invoice’s amount due and this invoice’s total).
• Overdue – no payment was received for this invoice and the due date has already passed. If applicable for this customer class, the collection process (notifications, suspension and termination) will be launched.
• Paid – invoice paid in full.
• Partially paid – a payment was received, but it does not cover the full invoice amount (invoice total).
• Do not pay – the invoice total is zero (e.g., the customer did not use the service) or negative (e.g., the customer was given credit in an amount higher than the actual service usage) and there is no unpaid balance from the previous invoices. No payment is applicable to this invoice; it is produced only for the customer’s reference.
• No payment required – this invoice’s amount due is lower than the collection threshold, so the customer is not required to pay it right now (but still has to pay it eventually). The collection process will not be launched if no payment is received.
• Previous balance remaining – although this invoice has a zero (or negative) invoice total, when combined with the amount due from earlier invoices there is still an outstanding balance. So the customer is still required to make a payment (to be applied to the earlier invoices), after which this invoice’s status will become “Do not pay.”

Suppose a customer’s service charge for the September billing period is $3. An invoice (see #1) with a total of $3 is then produced at the end of the month, and since there are no other factors to be considered (previous balance, etc.), the amount due for this invoice is $3. In October, the service charge is $4, so the total (or net amount) of October’s invoice (#2) is $4, while the amount due is $7 ($3 + $4), since the previous invoice balance is included.

On November 10^th the customer makes a payment of $5. This payment is applied first to the oldest unpaid invoice (#1 for the September billing period, $3 total), and the remaining portion ($2) is then applied to the most recent unpaid invoice (#2, for October). As a result, the invoice status for September is now “paid,” while October’s invoice status is “partially paid” (the remaining balance due for this invoice period is $2). In November the total service charge is $3, so on December 1^st a new invoice for November is produced. Its total is $3, and the amount due is $5 (previous invoice’s amount due) minus $5 (payment made during this period) equals $2 + $3 (new invoice total) = $5.

The total charge for December is $3, so invoice #4 for December is for a total of $3 with an amount due of $8. When payment is made in January, it is again split: $2 is applied to the October invoice (#2), whose status becomes “paid,” then $3 is applied to the November invoice (#3), and its status also becomes “paid,” and finally, the remaining $3 is applied to the December invoice, (#4). As a result, all invoices are now paid.

The total service charge during September is $3. At the end of the billing period when the invoice is produced, its total is $3 – so as a part of the invoice generation the customer’s credit card is charged $3 to pay the invoice. The payment is recorded as being applied to the September billing period, and as a result, the invoice is created with a zero amount due, and its status is “paid” (see below).

Customer’s invoice #1 for the September billing period had an invoice total of $30 and was due on October 21^st. No payment was received until the end of October, so invoice #2 (produced on November 1^st) has an invoice total of $4, bringing the amount due to $34.

On November 10^th the customer’s service is suspended because invoice #1 is overdue. On November 15^th the customer makes a payment of $50 and $30 of this payment is applied to invoice #1, which then becomes paid. Since there are no other overdue invoices, the suspension is lifted from the customer’s service. Then $4 of the remaining payment amount is applied to invoice #2 designating it as paid. There are no other outstanding invoices, and the remaining sum ($16) of what has already been paid is not applied to any invoice. This sum will be recorded in the "unallocated payments" property of the customer (you can see it on the Payment Info tab in the Customer Info form) so that it can be applied to future invoices. When invoice #3 for the November billing period is produced (with an invoice total of $9) the customer’s unallocated payment amount is immediately applied to the invoice. As a result, the invoice becomes “paid” and the unallocated payments now total $7.

For the December billing period the customer’s invoice total is $4. The remaining sum of unallocated payments ($7) covers this invoice, which becomes “paid” and the unallocated payments now total $3 ($7 - $4).

In the January billing period, the customer’s invoice is for $5. Given that $3 is left in unallocated payments, this covers part of the invoice amount. Now the invoice is “partially paid” (the remaining balance is $2), and unallocated payments are down to zero.

The refund transaction can be applied in different cases. Let’s consider some of them:

 In the beginning of October your postpaid customer makes a $20 pay in advance payment. Their invoice for the October billing period is $5, the invoice is paid and there is $15 left in unallocated payments.

On November, 1, the customer comes to you and says that he wants a refund on his balance ($15) so you apply the Refund transaction and return $15 to the customer.

Now the customer’s balance is zero while he continues to use the service. At the end of the billing period $15 is added to the customer’s invoice and this is reflected in the Credits group.

Now, suppose this is one of your first customers to use your service for ages. You want to reward him so you offer a $5 credit which is applied to his balance on December 5th. This does not affect the November invoice, but is reflected in the current billing cycle for December.

So then when the December billing period is over, the invoice contains applicable service charges for that period ($13) minus the credit ($5), which brings the total to $8 – and the amount due is then $8.

Both transactions are reflected in the Credits group on the customer’s invoice for the current billing period.

You provide some services using PortaSwitch and therefore, charge your customers for them. When an external company provides services to your customers using their platform, they should be included in the customer’s invoices. To enable data entry from the external system, an administrator activates the delayed billing period closure functionality and sets the allowable maximum number of days for approval to 7.

Suppose a customer’s total charge for the August billing period is $450.

On September 2^nd the administrator receives a list of customers to be charged for additional services and then inserts a $200 charges for a certain customer (see the transaction #6) into the database for the August billing period.

The transaction for additional services was physically added into the database in September, but since the August billing period was still open, the services will be included in the August billing period.

Then the administrator approves the billing period closure. On the night of September 3^rd an invoice is generated to include all of the charges (including the transaction manually added on September 2^nd) for the period between August 1^st and August 31^st.

Therefore, an invoice (see #1) with a total of $650 is produced for the August billing period, and the amount due for this invoice is $650.

Let’s consider the example shown above.

As in the previous case, a customer’s total charge for the August billing period is $450. On September 2^nd the administrator receives information about a customer’s additional charge, $200, for the August billing period (see transaction #6).

But in this current case, the administrator doesn’t approve the billing period closure.

On the night of September 7^th the billing period is automatically closed and PortaBilling generates an invoice with all of the charges (including the transaction manually added on September 2^nd) for the period between August 1^st and August 31^st (see an invoice #1).

The customer was initially created with invoicing disabled. During the first period (September) the total sum of charges was $20 ($13 for calls plus a $7 subscription fee), but no invoice was produced. During the October billing period invoicing is enabled, so invoice #1 is created on November 1^st. This invoice, covering the October billing period, will contain the actual charges for October ($20 for calls and a $5 subscription fee) – and the invoice total will be $25. The total charges accumulating in the account prior to October will be included on this invoice as the previous balance ($20), so the amount due for this invoice will come to a total of $45 ($25 + $20).

During November the customer makes a payment of $40 which is recorded as follows: $20 is applied to the “previous balance” of the first invoice (since there were no invoices for earlier periods) and the rest ($20) is applied to the invoice total itself. Since the payment applied to the invoice is less than the invoice total ($25), invoice #1 is “partially paid” (the sum still pending is $5). When November ends, a new invoice #1 is produced that contains the applicable charges for services provided in November ($35), so the invoice total is $35. Combining the previous balance ($45 due from invoice #1), payments made during this period ($40) and the invoice total ($35) work out like this: $45 - $40 + $35 = $40.

When sometime during the December billing period the customer makes a payment of $10, it is applied to the remaining outstanding balance for invoice #1 (for October), and its status then becomes “paid,” and as the rest of the payment ($5) covers part of invoice #2 (for the November period), its status now becomes “partially paid” (since the outstanding sum owed is $30). During December the following charges are applied to the customer: $10 for calls, $5 for subscription, and $10 for configuration assistance (applied personally by an administrator), so invoice #3 will contain: the previous balance due of $40, payments: $10, invoice total $25 ($10 + $5 + $10), bringing the amount due to $55.

Let’s say the customer plans to be away for several months starting at the end of September, and is worried that he will not be able to pay his bills regularly. Then in mid-September (while there are no outstanding invoices) he makes a payment of $50. Since there are no unpaid invoices, this amount goes to “unallocated payments.” Assuming the service charge for September is $15 ($10 for calls and $5 for subscription), on October 1^st when invoice #201 is generated, the unallocated payment balance is applied and the invoice status immediately becomes “paid.” The amount due, shown on the invoice, is -$50 + $15 = -$35 – and since it is a negative number, a “Credit balance, do not pay” message will appear next to the amount due in the invoice PDF. The unallocated payments now total $35 ($50 - $15).

Service charges for the October billing period are $25, so when invoice #307 (invoice total = $25, amount due = -$35 + $25 = -$10) is produced for this period, the “unallocated payments” are again applied to it, and the invoice becomes “paid.” The unallocated payments now total $10 ($35 - $25 = $10). The charges for November are $20, so the same process is repeated at the end of the November billing period. Invoice # 378 for a total of $20 is created stating the amount due:  -$10 + $20 = $10. The remaining amount in “unallocated payments” ($10) is applied to this invoice – but since the available amount is less than the invoice total, the invoice status becomes “partially paid” and the unallocated payment amount is zero. Starting with the next billing period the invoicing continues as usual.

For example, on June 20^th a $6 monthly subscription, charged two months in advance, is added to an account.

When invoice #501 for June is generated (on July 1^st), it contains the “past” subscription charge for the period from the day the subscription was activated until the last day of June (10 days), as well as advance charges for two future billing periods (July and August), bringing the total subscription charges to $14: $2 (10 days out of 30 in June, so the pro-rated charge is $6/30*10 = $2) + $6 (July) + $6 (August) and the “billed to” property of this subscription is set to August 31^st. So the invoice total for invoice #501 is $14, and the amount due is $14 as well.

Invoice #607 for the July billing period (produced on August 1^st) contains a $6 subscription charge for September (since the customer has already been charged for July) and the “billed to” property is updated to September 30^th, accordingly. Since the previous balance (on invoice #501 for the June period) was $14, the amount due for this invoice becomes $20 ($14 + $6).

On August 15^th, the subscription is canceled. At that moment, a credit is issued for the entire billed but unused service period - from August 15^th until the “billed to” date (September 30^th), so the credited amount is $9 ($3 for half of August and $6 for September). Invoice #692 is produced on September 1^st for the month of August. It includes the $9 credit, and assuming there were no other charges for that period, the invoice total is -$9.  The amount due will then come to $20 - $9 = $11. In addition, a negative invoice total is recorded in the system in the same way the payment would be (since effectively, the outstanding customer balance is less now). The $9 balance is applied to pay off invoice #501 for the June period ($14), which becomes “partially paid” (the sum remaining is $5). Invoice #607 for the July period remains “unpaid” ($6). The status of invoice #692 is a bit tricky – and although there is nothing due on the invoice total itself, it still carries an unpaid balance from the previous invoices – so the customer still needs to pay this invoice’s amount due ($11) for all invoices to be paid and up to date.

Let’s consider an example for when a customer’s service becomes suspended because of insufficient funds.

A $6 subscription charged 1 month in advance is added to the account of the prepaid customer. The customer has $10 in available funds.

On September 30^th the system calculates the subscription charges for the period between October 1^st and October 31^st ($6) and compares them with the amount of funds available ($10).

The customer has sufficient available funds, thus the charges are applied. The amount of available funds becomes $4.

The invoice #1 generated for the September billing period has the “do not pay” status and states the following:

• Previous balance ($-10) – since the customer has had no previous invoices, the previous balance here shows the funds the customer initially deposited which is a negative value.
• Payments (0) – the amount paid by the customer during the last billing period;
• Invoice total ($6) – the sum of all charges for this billing period minus refunds/credits;
• Amount due ($-4) – this is calculated as the Previous balance + Invoice total - Payments. In this particular case the negative value of the amount due shows the amount of available funds the customer had at the moment of invoice generation. Thus, no payment is required.

  

In October the customer’s service charge is $1 for making calls, which means that the amount of available funds becomes $3. On October 31^st the system calculates the subscription charges ($6) for the period November 1^st – November 30^th. Since the customer has insufficient available funds ($3), the service is suspended and no charges are applied. Therefore the customer’s available funds remain $3.

The invoice #2 generated for the October billing period has the “do not pay” status stating the invoice total as $1 and the amount due as $-3 ($-4 + $1= $-3).

On November 5^th the customer makes a $15 payment. The total amount of available funds is now $18, and therefore the suspension is lifted from the customer’s service. The system applies the subscription charges ($6) for the November billing period. However, since the customer did not use the service until November 5^th, an $0.80 refund is generated for the period from November 1^st – November 4^th (4 /30* $6 = $0.80) and is returned to the customer. Now the amount of available funds is $12.80.

On November 30^th the subscription charges ($6) for the period December 1^st – December 31^st are calculated and applied to the customer, thus bringing the amount of available funds to $6.80.

The invoice #3 generated for November will have the “do not pay” status and the amount due will be $-6.80.

Please refer to Subscriptions charged in advance to prepaid customers section of PortaBilling Administrator Guide for more information.

Collection threshold allows payment to be delayed if the total amount is too low to make it worthwhile. If the amount due on an invoice is lower than the specified threshold, no payment is required and the collection process is not launched, i.e., notifications about the due date or an invoice being overdue are not sent. If no payment is made, the invoice balance is rolled over to the next invoice(s) until the amount due on a new invoice crosses the threshold.

Let’s consider the following scenario with an invoice grace period of 21 days and a collection threshold of $10. During the initial period (September) the customer does not have any subscription charges (it is a promotional period) and he only makes calls for $2 in total. Invoice #1 with a total of $2 is then produced at the end of the month; the amount due for this invoice is likewise $2. As the amount due is less than $10 (the collection threshold), this invoice is considered exempt from the collection process. The customer will receive a PDF file with the invoice information; however, no further notifications will be sent, and the status for this invoice is displayed as “No Payment Required.” On October 21^st, when the invoice would have become overdue, nothing will happen.

During the second period (October) the total sum of charges is $5 ($2 for calls plus a $3 subscription fee). At the end of the month, invoice #2 with a total of $5 is produced; the amount due for this invoice is $7 ($2 + $5), since the previous invoice balance is included. This amount is still below the collection threshold, so this invoice is also marked “No Payment Required” and exempted from the collection process.

During the third period (November) the total sum of charges is $6 ($3 for calls plus a $3 subscription fee). At the end of the month, invoice #3 with a total of $6 is produced; the amount due for this invoice is $13 ($7 + $6), since the balance of the previous invoice (#2) is included.  This amount is above the collection threshold ($10), and so the invoice is considered “normal” (its status is displayed as “Open”).

On December 10^th the customer makes a payment of $10. This payment is first applied to the oldest unpaid invoice (#1 for September, $2 total), then to invoice #2 (October, $5) and then the remaining amount ($3) is applied to invoice #3. As the result, invoices #1 and #2 are now “paid”, and invoice #3 is partially paid. The customer will receive notifications about the approaching due date (December 21^st), and if payment is not received by then, the normal collection process will start.

This option can be activated for any subscription plan on its General Info tab. “Remaining Subscription Charges” should be selected in the Early Cancellation Penalty option button.

A subscription plan has a $30 monthly subscription fee and a 12-month subscription period. If a customer signs up on June 10^th 2012 and cancels the subscription on August 15^th, then for the period June 10^th 2012 – July 1^st 2012 the customer will receive an invoice that includes the subscription fee for a total of 20 days ($20). The second invoice for the period July 1^st 2012 – August 1^st 2012 will include the month’s subscription fee ($30). Because the customer cancels the subscription on August 15^th 2012, the invoice in September will contain the remaining fees for the period from August 1^st 2012 until June 10^th 2013, bringing the invoice total to $310:

• $300 ($30 * 10 (August 1^st 2012 – June 1^st 2013))
• $10 (June 1^st 2013 – June 10^th 2013)