Difference between revisions of "Credit Notes"

Revision as of 19:22, 11 September 2011

Introduction

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 less 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.
• Income/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.

Note that the basic premise for new features is always that the new version of GnuCash must be able to handle the new data, while the old version should at least be able to read it, but not modify it. Changes proposed will always be in this sense.

Artificial limitation

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 affected. If however a new transaction type is introduced for credit notes (say 'C'), this report will no longer show the credit note splits.

Old

• No changes required, unless a new transaction type is introduced for credit notes.

New

• No changes required, unless a new transaction type is introduced for credit notes.

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.

Old

• No changes required.

New

• No changes required.

gncInvoicePostToAccount (in gncInvoice.c)

When posting an invoice the code checks for an open lot for the invoice's owner that can be used to associate with this invoice. The check is twofold:

• Is this lot a "payment" ? This actually checks if the lot has the opposite sign of the invoice. If not the evaluated lot is skipped.
• Does the lot have an invoice associated with it ? If so, the lot is skipped as well. This prevents that the code accidentally attempts to associate two invoices with the same lot (which would seriously mess up things).

By the way this check is not in gncInvoicePostToAccount but in the helper function gnc_lot_match_owner_payment in the same file.

These checks together mean that posting a credit note will never accidentally try to post it to an open invoice lot, which simplifies backwards compatibility considerably.

The code as is however will fail to work for posting credit notes because of the simple sign evaluation. To enable posting for credit notes the gncInvoicePostToAccount the calculation of the "reverse" parameter will have to be extended.

gncOwnerApplyPayment (in gncOwner.c)

When applying a payment, this code will iterate over all open lots for a given owner. This can include a specific lot associated with a preselected invoice, but that's not relevant to this discussion.

When filtering the lots, there's no check on sign. All open lots will be selected. When later the routine starts applying payments the sign is checked. Note that in this context a payment is considered negative, compared to an invoice balance being positive. Since a credit note has the opposite sign of an invoice it's also considered negative in this context. Lots for which the sign is "negative" (hence payments and credit notes) are skipped, although the first one found is retain to add overpayments to in the end.

This can cause problems.

Use case: suppose we have an unpaid credit note and no unpaid invoices. For simplicity I'll also assume there are no other overpayments. Now let's apply a payment for this owner. When the routine iterates over the open lots, it will find the credit note lot, consider it a "negative" lot and take it for a valid pre-payment lot. Since there are no open invoice, the payment is added to this credit note lot in the end of the routine. We now still have only one lot, but holding the credit note and a payment, effectively increasing the lot.

Next step: Create and post a new invoice. As described above when posting an invoice the lots which already have a document associated with them are skipped. So the credit note lot with the pre-payment is skipped and a new lot is created for the invoice. The prepayment didn't get linked with the invoice. So when the time comes to pay the invoice, GnuCash will propose its full amount, instead of the invoice amount minus the credit note and the prepayment. Also when selecting the credit note to pay (assuming the sign issues for this have been dealt with) would now propose a payment of the credit note amount plus the prepayment. Note that eventually the totals will add up again so the complete owner balance remains correct. It's just in the payment interface that things get confusing.

New code can be easily made to deal with this. But when a data file is shared between new and old versions of GnuCash this can lead into the situation described above (a credit note is added in a new GnuCash version and then a prepayment and an invoice are added in an old version).

To prevent this situation from happening, I think it's best to add an additional check in the old GnuCash version that prevents any lot having an invoice associated already to be reserved as a pre-payment lot. The net result would be that credit notes will completely be ignored for payments in the older version of GnuCash.

The code as is won't work for Credit Notes either. A lot is considered for a payment when its balance is "positive", but with the current evaluation of "positive" a credit note has a "negative" balance and is simply skipped. Additionally when a payment for a credit note is entered (assuming the GUI allows this), this code will add this payment to the first invoice found instead. But that's the wrong sign, so the invoice lot would be increased instead of decreased. To fix this, lots to be considered shouldn't be of a predefined "positive" or "negative", but rather of the opposite sign of the payment and have a document attached to it. And conversely to be eligible as a pre-payment lot (used at the end to save overpayments) a lot should be of the same sign as the payment and not have a document associated with it. This way payments are never accidentally assigned to lots that don't make sense.

Note that combined with the restrictions in posting invoices/credit notes, a credit note is never automatically used to reduce the amount due for an invoice. This is slightly inconvenient and may call for a more flexible user interface to handle payments.

Alternatively or additionally the payment code could already be improved to separate invoice and credit note lots at the beginning, first creating transactions that reduce open invoice and credit note lots to a minimum ("pay" open invoices with open credit notes or the other way around depending on which kind has the highest balance) and only then try to assign the payment to the still open lots.