GNOME Bugzilla – Bug 535781
Support for Credit notes (or negative invoices)
Last modified: 2018-06-29 22:05:03 UTC
The current version of GnuCash doesn't have a paradigm for Credit notes. For clarity: with a credit note, I mean the opposite of an invoice, or a "negative" invoice, depending on the view you prefer. This report is created as a follow-up to the mailing list thread called "GDA: status", although most of this thread deals with GDA and not Credit notes. The relevant part of this thread starts May, 27th 2008. According to Derek, it's not possible to simply remove the negative totals error check. The internal logic relies on value+accounttype to determine whether a transaction is an invoice or a payment. Reworking the internal logic would be the first step to solve the CN issue. Once the internal logic no longer depends on value+accounttype, the restriction could be removed and a basic form of credit notes are possible. In the longer run there would be some "nice to have's" of course: * separate and combined reporting in invoices and credit notes * different wordings on printed invoices and credit notes (required by Belgian law by the way: invoices need to state clearly: Invoice, while credit notes need to state: Credit note) Finally more obvious GUI hints to the creation of credit notes would be helpful as well. I am thinking of * the business menus would have to mention Bill/CN and Invoice/CN, or broaden the term to "Sales documents" and "Purchase documents"... I know these aren't very nice for menus, but they just serve as suggestions. Someone else may think of better words. * Inside the "New invoice/bill" dialog (which may also have to be renamed), an option could be added to specify whether the new document will be an invoice or a credit note. * The dialog in which the actual invoice/CN transactions are entered could then continue to use positive values at all times. The internal logic can determine the real sense of the final transaction based on A/P vs A/R together with the document being invoice or CN * A slight variation on the last suggestion is that even an invoice or a CN can be positive or negative. The sense of the final transaction then simply depends on three parameters: AP vs AR, invoice vs CN and sign of document total. Note that although a negative invoice and a positive credit note have the same mathematical effect, but Belgian law doesn't consider them the same (although I personally consider this pure nitpicking). * Instead of renaming the current menu items, it is also possible to add another (set of) menu items specifically for CN's (New CN, Search CN,...). This would eliminate the need for additions to the two dialogs that follow (some name mangling not considered here). Final note: until this would be implemented, Derek suggests a (somewhat awkward but working) work around: A Process Payment gives you that "Negative" number. What you would do is Process Payment to, say, your checking account. Then after the transaction gets posted you can go in and change it from Checking to Income. Make sure you only change the account, not the AMOUNT. Changing the amount will throw off all the numbers.
Hoi, I would suggest "open items" as generic term for A/R and A/P and maybe their management. Then "sales statement" and "purchase statement" as generics for Bill/CN and Invoice/CN. When I am translating, I am always puzzling, what is bill and what invoice. But at least in theory there is also a third form: an account current can mix both. Then "statement of account" would fit better. I think, the different words are not a only belgian, but at least an EU rule and affect more countries. One aspect, we should respect also, is: there are different causes for a credit memo, which affect different parts of the accounting hierarchy: * storno/cancellation reverts some proceeds * retour/return reverts some proceeds, but are often kept in separate accounts for transparency reasons as "quote of return" * bonus reduces some previous proceeds, but are often kept in separate accounts * finally the monthly closing of a "statement of account", where you balance A/R against A/P * Forgot I some? There could be an option to switch between a general "statement of account" and a dynamic "Invoice/Credit Note" depending on the sign of the bottom line. Then you had all three forms in one report. But IANA and no native english speaker, so some terms could be improper.
*** Bug 635146 has been marked as a duplicate of this bug. ***
I favor Frank's approach. Sometimes the same person is listed as both a customer and a vendor, and I would like to be able to offset their bills and invoices to avoid sending checks both ways. (However, not all businesses can operate this way!) Combining A/P and A/R into one system would allow these accounts to be mixed in this way.
Ian, First off, I'm not an accountant so someone with authority in this field may correct me. I don't think what you suggest is acceptable from a business accounting point of view. In Belgium at least, I'm pretty sure vendors and customers have to be treated separately, even though they may be the same real life entity. I have to post all vendor's bills to an A/P account and all customers to a separate A/R account. So I don't think we can structurally treat the A/P and A/R account as one single account. Not for technical limitations (as with credit notes), but for business accounting law restrictions. Nothing prevents you of course to manually keep track of open bills and invoices for a given business partner and only write a check for the remaining balance. Splitting such a single check over multiple invoices/bills in GnuCash will obviously involve entering some manual transactions, which I agree is kind of a nuisance.
> Splitting such a single check over multiple invoices/bills in GnuCash > will obviously involve entering some manual transactions, which I agree is kind > of a nuisance. I don't understand this statement. The payment processing will handle multiple invoices (to the same payment entity, customer or vendor). However yes, paying a A/P balance with an A/R balance would be hard; you would probably need to do it wish a suspense account and it wouldn't directly link the transactions together.. At least until there's a way to apply a payment directly to a customer or vendor.
(In reply to comment #5) > > Splitting such a single check over multiple invoices/bills in GnuCash > > will obviously involve entering some manual transactions, which I agree is kind > > of a nuisance. > > I don't understand this statement. The payment processing will handle multiple > invoices (to the same payment entity, customer or vendor). > Yes, but that's not what Ian's request is about. It's about paying both an invoice and a bill together. > However yes, paying a A/P balance with an A/R balance would be hard; you would > probably need to do it wish a suspense account and it wouldn't directly link > the transactions together.. At least until there's a way to apply a payment > directly to a customer or vendor. This is what my statement (poorly) tried to convey.
Geert: Agreed that application of the proposed feature would have to be subject to legal, compliance, contract, and business policy restrictions. Maintaining the existing separation may sometimes be necessary, though the contact information could still be shared. One compromise here would be to combine contact information and then create an optional feature to automatically pay new A/R or A/P items when there is an existing balance from the other side.
Ian, I do see value in sharing contact information. I see this in other accounting systems as well. It is however a different feature request from this initial support for credit notes. So I would prefer to see this tracked in a separate bug report or on gnucash.uservoice.com.
Hi all! Is this topic still getting attention from the developpers? The impossibility of creating credit invoices still keeps me away from embracing GnuCash.. Kind regards!
Credit notes have already been added to the development branch.
Credit note support is ready and will appear in gnucash 2.6. Closing this bug.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=535781. Please update any external references or bookmarks.