Difference between revisions of "Credit Notes"

Revision as of 16:09, 11 September 2011

Credit notes are a common document in business transactions mostly used to correct items/services that were incorrectly invoiced before.

Note upfront GnuCash makes a distinction between invoices and bills in the user interface. A bill is received from a vendor, while an invoice is sent to a customer. This distinction is only made to avoid user confusion. The document received from a vendor could just as well be called an invoice in accounting terms. For the remainder of this page I will only talk about invoices, but it can mean either bill or invoice in the GnuCash sense of the words.

From an accounting perspective a credit note is very similar to an invoice. The document has got all the same properties as an invoice, but the sign is reversed. When you send your customer an invoice, the customer owes you money. Yet when you send your customer a credit note, you owe your customer some money.

Since technically invoices and credit notes are that similar, it makes sense to treat both documents very similarly in GnuCash as well, at least in the processing. To avoid confusion the user interface could make a distinction between the two document types, but the user should be allowed more or lest the same set of actions on either.

At present, GnuCash doesn't really support credit notes. The workaround suggested is to make a payment to the vendor for the amount of the credit note received. In this way at least GnuCash knows the vendor owes you this amount of money and will substract it automatically from the next invoice(s). This is not optimal in several ways:

• There's no document tracking. GnuCash doesn't know anything about the credit note.
• Expense accounts aren't updated properly. Say the credit note was for a book you bought before, then the original invoice would increase the "Books" expense account, yet the expense account isn't decreased when the credit note is processed. So you end up with an incorrect balance. And it gets even more complicated if the credit note has multiple entries (with or without taxes).

What follows is an analysis of what is required to fully support credit notes in GnuCash. This includes an interface to enter credit notes, how to handle credit note payments or invoice/credit note interactions, what impact the changes in the engine will have on older GnuCash releases and so on.

Artificial limitation

This section will be pretty technical...

The core issue regarding credit notes is a design assumption from a long time back:

• to track invoice payments, invoice splits and its related payment splits are grouped in lots. Some parts of GnuCash assume invoices to be in one sign (say positive) and payments in the opposite sign (say negative for this example). Note that for bills the signs are exactly opposite but that's irrelevant for this discussion.
• From a business logic perspective, a credit note is a negative invoice. With the above assumption (invoice=positive, payment=negative) that would mean that some parts of the business logic would incorrectly interpret a credit note split as a payment and a credit note payment as an invoice.

To avoid this unwanted confusion "negative" invoices are prohibited.

The first step of this analysis is to uncover all parts of GnuCash that may be influenced if negative invoices were allowed.

owner-report.scm

This report will display a transaction history for an owner (invoices and payments). It distinguishes between invoice splits and payment splits based on the transaction type (currently can be 'I' for invoice and 'P' for payment). If credit notes are introduced in the business logic as a negative invoice, the invoice splits would still have the 'I' transaction type and payment splits would still have the 'P' transaction type. Hence this report is not influenced. If however a new transaction type is introduced for credit notes (say 'C'), this report will no longer show the credit note splits.

aging.scm

This report uses the positive=invoice, negative=payment assumption. It doesn't however list separate splits in detail. It only creates sums for splits that increase or decrease open invoices or overpayments. In that calculation it doesn't really matter whether a split was actually an invoice or a payment split. The sums still add up correctly with credit notes (negative invoice splits) and credit note payments (positive invoice splits). So this report is most likely not affected.