Business Features Issues
The GnuCash business features are a set of tools layered on top of the basic accounting functionality in gnucash. It uses dedicated Accounts Receivable (AR) and Accounts Payable (AP) accounts to manage business transactions (invoicing/billing/payments).
In principle these AR/AP accounts are not meant to be manipulated directly. Yet gnucash does not prevent direct manipulation because sometimes a manual intervention is needed to keep the books correct. Unfortunately this "not meant to, yet allowed" configuration can lead to confusion and people mistakenly make changes in these accounts that go unnoticed by the business features.
Fortunately these changes will not throw off your books. The balances will still be correct as will be income statements and most other general accounting reports. The business features however as well as several business-specific reports will be off.
As a general rule of thumb don't create new transactions directly into an AR/AP account or create transactions in other accounts and which have one or more splits in an AR/AP account. These transactions will be ignored by the business features.
Apart from direct user entry in AR/AP accounts bugs in the gnucash software could also lead to unwanted links between invoices/bills and payments. The lot links which were introduced in gnucash 2.6.0 for example could lead to chains of transaction splits in the AR/AP account which could make it very difficult to figure out which invoice got paid by which payment or even which invoices were still (partly) unpaid.
This wiki page will list some common issues and offer methods to correct them.
Note the text below sometimes refers to bills/vendors and sometimes to invoices/customers. Unless explicitly stated the explanation is valid for both types of business objects. In case of vendors and bills the relevant account is always AP in case of customers it is AR. Adapt the steps below according to your needs to either set.
Unposting and reposting a paid invoice loses its payment
As of gnucash 2.6.0, when you unpost a paid invoice (or bill) and then repost it again after making corrections the invoice is no longer marked as paid. These have to be manually linked together again.
Unfortunately gnucash 2.6.0 to 2.6.2 contained bugs that prevented this. In those versions your only option is to
- delete the payment
- delete the accompanying lot link transaction from the AR account
- reapply the payment
This is cumbersome so the recommended alternative is to upgrade to gnucash 2.6.3 or higher. As of that version here is how you can fix this
- Open Business->Customer->Process Payment...
- Select the correct customer and optionally also the correct "Post To" account (usually the latter is ok by default)
- Now select both the unpaid invoice and the corresponding pre-payment
- This should set the amount to 0 and the transfer accounts should get greyed out
- Click Ok
If the amount is not 0 that means the unpaid amount of the invoice doesn't match the amount of the pre-payment. How to proceed depends on the situation.
- Perhaps there was a second pre-payment to select ? You can do so and with all the lines selected click Ok.
- Or the invoice wasn't fully paid before either ? Then manually set the amount to 0 to indicate no additional payment (apart from the pre-payment) should be entered now.
- Or you have an additional payment to enter at this time ? You can set the amount to that of the additional payment and indicate which account was used for this payment.
As said above, as of version 2.6.0 gnucash can create lot link transactions in your AR/AP accounts. These particular transactions were introduced to allow the implementation of credit notes. Unfortunately the initial implementation used lot link transactions for each and every invoice payment, causing the AR/AP acounts to be flooded with lot link transactions.
As of gnucash 2.6.5 the lot link code has been considerably improved and will only be used when absolutely needed (which is when you offset an invoice with a credit note). If you used the business features of gnucash versions 2.6.0 to 2.6.4 your book will likely still have several superfluous lot links though.
To get rid of the superfluous lot link transactions you can
- Go to your Account Hierarchy tab
- Select "Actions -> Check & Repair -> Check & Repair All
- Depending on the size of your financial data this can take a considerable amount of time. On my hardware 2011 hardware running Fedora Linux, running Check & Repair on a book with 6328 splits in AR/AP combined it took almost 15 minutes to complete. I expect it to be much slower still on Windows.
- More importantly there is still a bug in Check & Repair in GnuCash 2.6.5 that will cause it to end up in an infinite loop under certain conditions and the Check & Repair option will never finish. This bug will be fixed in GnuCash 2.6.6.
- If you want to try and clean your book already in gnucash 2.6.5, please try this first on a copy. To know whether it is still performing normally or got into the infinite loop, you can open the transaction log file that is generated while gnucash is running Check & Repair. This transaction log is found in the same directory as your gnucash data file and has the .log extension. There will be several, you'll want to open the most recent one. The log lists the splits of transactions as they are being edited in blocks between '===== START' and '===== END' markers. If the same block gets repeated over and over again (note the posted date,descriptions and amounts) with each time more splits getting added you are in the endless loop. Your only way out is to kill gnucash and revert to your original copy.
Advanced manual intervention
If you run into the infinite loop but don't want to wait for gnucash 2.6.6 to clean up your lot link transactions here is what you can do (again - try this first on a copy):
- From the log file generated during the infinite loop determine which transaction is causing the infinite loop. You can use the date posted, amounts and description as hints.
- In the (fresh) copy of your data file, locate the transaction in your AR or AP account. This should be a lot link transaction.
- Delete this transaction.
- Any invoices/bills and payments this transaction linked together will now be unlinked. That means for this customer or vendor you will now have an unpaid invoice of bill again and a prepayment.
- You can use the Business->Customer/Vendor->Process Payment... menu option to link these together again as described above.
- Save your book and retry to run Check & Repair. It may run to completion now. Or it may end up in yet another infinite loop in which case there is yet another bad condition lot link transaction. So continue to repeat these steps until all these bad condition lot link transactions have been manually eliminated.
I entered a payment directly instead of using Process Payment
If you entered a payment transaction directly in the account registers (for example in your Checkings Account with a transfer to the Accounts Payable account), this transaction will be ignored completely by the business functions. That is probably not what you want. It won't show up on the Vendor Report nor in the Payment Window for your Vendor.
To integrate this transaction in the business features do this:
- Open your Checkings Account (or whichever account this transaction was entered in)
- Right-click on the transaction and select "Assign as payment..."
- A Process Payment window will open with most of the payment's details filled in
- Select the correct vendor
- Optionally select a bill to pay. If you don't the payment will be treated as a pre-payment which you can assign to an invoice in the future.
- Click Ok
The logic behind "Assign as payment..." has to figure out if the payment is meant for a vendor's bill or a customer's invoice. The algorithm to determine this is quite basic and may propose the wrong business partner type. If that is the case unfortunately you can't use "Assign as payment..." for this transaction. Instead you will have to delete the transaction and use Business->Vendor->Process Payment..." to re-enter the payment in the traditional way.
Our bug tracker carries an enchancement request to improve on this situation.