Show Credits / Payments On Invoice Pdfs

[FRH Dave]

Currently the invoice PDFs do not show any applied credits or payments.  For example, in the following circumstances:

 

Service Total:  $200.00

Existing Account Credit:  $25.00

Partial Payment:  $100.00

 

Blesta will print an invoice showing the customer owes $200.00, when in reality he only owes $75.00.  This can cause some confusion among customers.  We're also printing a padded invoice; the customer can then use that data to falsify their books, embezzle funds from their company, falsify taxes, etc.

 

Or let's say one year after the invoice is paid, the customer's accountant is auditing their books.  The accountant requests and gets a copy of invoice #12345, which shows the client "paid" a $200.00 balance.  This creates a discrepancy with the client's books, which only show a payment of $175.00 (let's assume for the sake of simplicity that the accountant already saw the previous $100.00 partial payment and correctly attributed it to this invoice).  Now the client has an unreconciled $25.00.

 

A PDF should show the payment status in detail.  Ideally, it should show each related transaction.  In the case above, we might see three payment lines:  Account Credit / $25.00, Visa Payment 10-21-2013 / $100.00, PayPal Payment 10-29-2013 / $75.00.  Alternatively, all payments can be grouped so that we would see two lines:  Account Credit / $25.00, Account Payment $175.00.

[Michael]

Good idea If a customer contacts me or a payment fails, I cancel the subscription and tell them that they can save money by remaking the subscription when they pay for the next invoice.

[MemoryX2]

+1000000

 

This is very important!

[Paul]

Any preference to where this would appear on an invoice? Toward the bottom, below all line items?

[Daniel B]

Any preference to where this would appear on an invoice? Toward the bottom, below all line items?

 

When I do this sort of stuff manually, I simply add a new line at the bottom of all the other line items for a negative amount, and list it as a credit/partial payment/etc; that is my preferred place for it to go.

 

Though having a separate area for credits/partial payments (maybe a "charges" line item area and a separate "credits" line item area below it) would be nice as well.

[FRH Dave]

At the bottom, between "subtotal" and "total due".

[S.H.]

Any update on this? Blesta 2.5 invoices had this feature, why was it removed? Every client has to contact us to find out why their partial payment is not reflected on the sent invoice.

 

A fix for this would be greatly appreciated.

 

Thanks

[mrrsm]

+1 as I had thought this was happening but wasn't.

[Paul]

I have assigned this to CORE-1148

[Max]

Information on invoices

 

Invoices should never change once issued.

 

Remarks about payments only belong on invoices if the payment was made PRIOR to the invoice being issued.

If you asked and received payment in advance, the invoice you send must (under EU rules) mention the date the payment was made.

Usually this is done by having a line at the bottom like "Already paid by <payment method> on <date>", where you would normally have payment instructions instead ("Payment due in 14 days. If paying by bank transfer please mention reference ABCD")

 

 

One issue with Blesta is that when a new order is placed by the customer and paid directly by credit card, the invoice is created first and the payment applied after that.

Think it would be better if that was reversed. Do not issue an invoice until gateway confirms payment (or issue a pro-forma invoice first, if the customer wants to make a manual payment)

That way you do can mention the payment that was made on placing the order.

And not creating invoices until the first payment arrives also reduces unnecessary tax liability, for orders placed but for which the payment process was never completed.

 

 

Credits

 

Credits should be rare and not an everyday occurrence.

 

If the customer accidentally paid too much when paying a previous bill, you really should refund it to whatever payment source it came from, instead of hanging on to it as credit.

 

If you offer the customer a discount (e.g. when he is upgrading from a smaller package he already paid for, to a bigger package), mention the discount as a second invoice line with negative amount.

This also reduces the tax to pay properly, something which will not happen if you just give him some credit for it.

 

 

(Partial) payments after invoice has been issued

 

If customers have problems paying their bills in full, make partial payments, and have problems keeping track of how much is left to pay, the proper way would be to send them a separate account statement listing transactions and outstanding balance.

Not append later information to an invoice issued previously.

[mrrsm]

(Partial) payments after invoice has been issued

 

If customers have problems paying their bills in full, make partial payments, and have problems keeping track of how much is left to pay, the proper way would be to send them a separate account statement listing transactions and outstanding balance.

Not append later information to an invoice issued previously.

 

I really like this idea and believe you should open this as a separate feature request. (Otherwise I may do it next week).  Being able to email/print an account statement as a customer or for a customer would be very useful.

[Paul]

Information on invoices

 

Invoices should never change once issued.

 

Remarks about payments only belong on invoices if the payment was made PRIOR to the invoice being issued.

If you asked and received payment in advance, the invoice you send must (under EU rules) mention the date the payment was made.

Usually this is done by having a line at the bottom like "Already paid by <payment method> on <date>", where you would normally have payment instructions instead ("Payment due in 14 days. If paying by bank transfer please mention reference ABCD")

 

 

One issue with Blesta is that when a new order is placed by the customer and paid directly by credit card, the invoice is created first and the payment applied after that.

Think it would be better if that was reversed. Do not issue an invoice until gateway confirms payment (or issue a pro-forma invoice first, if the customer wants to make a manual payment)

That way you do can mention the payment that was made on placing the order.

And not creating invoices until the first payment arrives also reduces unnecessary tax liability, for orders placed but for which the payment process was never completed.

 

 

I made a note regarding invoices being changed in the task when I created it, and it's something we will consider. However, I think proforma invoices once implemented (In CORE-497) will solve any concerns about invoice amounts & payments changing after they are created. If proforma is enabled, a proforma invoice will be issued. Paying the proforma invoice will generate and pay a typical invoice. Combined with CORE-923, you can be pretty sure invoices will not change at all once they are created.

[Max]

I made a note regarding invoices being changed in the task when I created it, and it's something we will consider. However, I think proforma invoices once implemented (In CORE-497) will solve any concerns about invoice amounts & payments changing after they are created. If proforma is enabled, a proforma invoice will be issued. Paying the proforma invoice will generate and pay a typical invoice. Combined with CORE-923, you can be pretty sure invoices will not change at all once they are created.

 

Note that CORE-923 mentions caching the invoice on disk, which sounds .pdf only.

The data as it appears on the invoice should be stored in the database as well, as you also need it to be able to generate reports from it, in order to fill in your tax return properly.

 

One needs the customer's country and customer's VAT ID as it was on the day the invoice was issued at a minimum.

(Need to supply the government with a list containing the VAT IDs of companies in other EU countries VAT was exempted/reverse charged for, and the total amount sold to that company in a reporting period)

But better to stick all other invoice data in the invoice table as well, just in case any other jurisdiction needs more.

 

 

Also not sure how caching on disk as described in CORE-923 is going to work when generating a single pdf containing multiple invoices (print queue thing?), and viewing single invoices earlier or later.

Do you plan to store the invoices as single pdfs on disk, and use a library (such as Zend_Pdf or FPDI) to concatenate them when generating a batch? Or does it still end up generating fresh invoices containing possibly new data, which is a problem?

[PauloV]

+1 for the EU invoice like Max as said

[Max]

I really like this idea and believe you should open this as a separate feature request. (Otherwise I may do it next week).  Being able to email/print an account statement as a customer or for a customer would be very useful.

 

Feel free to create the feature request for account statements.

 

For me having the statements itself is not top priority.

Just believe separate statements are a better alternative to making changes to already issued invoices (which you do when you scribble transaction information on them).

[Larry]

I've supported several commercial billing systems (now semi-retired). Here is what I've seen:
Transactions are permanent. Once created a transaction's data can't be modified
Data may be added (ie closed date).
Transactions include:
     invoices.
    payments
    refunds
    credits
    debits

An invoice documents a sale. It does not contain balance or payments or previous due amt.
An invoice contains line items (qty, desc, unit cost, ext cost, date)

A statement is a report containing period to date transaction data, (invoice, payment, credit). Since a statement is a report, typically a pdf, it can be created anytime. It is not the source record for anything.  It is convenient to keep, particularly if it was sent to a client.

 

It is common to save the invoice as a pdf along with a record of  to who and when it was sent. The systems I worked on were not required to be able to recreate an invoice pdf from data and have it match the original pdf.

 

The point is, the financial integrity is not dependent on statements  So a modified statement can be sent in place of an invoice, That's what blesta does, it is a combination statement/Invoice, which is fine.  Very typical.

 

I see over on Core 923 there is concern about associating contact info with an invoice and then having the contact info change. The few bits of data, like VAT and country that have to be "remembered" for an invoice are stored as part of the invoice record. (that or a versioning sysem for the contact info which adds complexity, Last system I worked on did that)

 

Lar

 

 

[Larry]

.

[Debunker13]

I agree this will save me innumerable hours answering phone calls from clients asking why their current invoice doesn't reflect any payments they made.  Previous version supported this feature why was it removed?

[alexistkd]

+1 for this very useful