Payments against starting credit balances for customers unrelated to pre-start-date sales invoices are not being handled correctly. To illustrate the problem, first consider a straightforward example. In this example, there are only two relevant financial transactions: One customer starting credit balance One sales invoice At the start date of 01/01/2017, ACME Services owes Brilliant Industries 10,000. This is not related to a prior sales invoice, but to an overpayment by Brilliant under a previous accounting system. So the 10,000 credit is set as a starting balance for Brilliant in the Customers tab. On 01/01/2018, ACME raises a new sales invoice to Brilliant for 6,000. Manager properly applies the credit to the new sales invoice, which is then paid in full: [03%20PM] The invoice’s status in the Sales Invoices tab is correct: [38%20PM] And the drill-down on the invoice’s balance due in the Sales Invoices tab is correct: [06%20PM] Brilliant’s Accounts receivable balance in the Customers tab is also correct: [27%20PM] However, if a refund payment is made to Brilliant before the new sales invoice is raised, problems result. To continue the example, we add a single additional transaction: One refund payment ACME refunds 10,000 to Brilliant on 07/01/2017, eliminating Brilliant’s credit balance. Because no sales invoice is involved, the payment is posted to Brilliant’s Accounts receivable subaccount, but not allocated to an invoice: [56%20PM] Despite the fact that the customer’s account was zeroed by the refund payment, before the sales invoice was raised, the sales invoice still shows as paid in full: [58%20PM] And a drill-down on the zero balance shows that 6,000 of the no longer available starting credit balance was erroneously applied: [26%20PM] Meanwhile, in the Customers tab, Brilliant’s Accounts receivable balance reflects the full amount of the sales invoice that shows in Sales Invoices as paid in full: [20%20PM] The discrepancy between invoice status and Accounts receivable is further highlighted by a customer statement, showing clearly that the customer’s balance was zeroed by the refund before the sales invoice was raised: [02%20PM] As a side note, the Customer’s tab shows two invoices for this customer, but there is only one. Could that somehow be related to the problem? Thanks to @Solnce for first bringing this up on the forum and providing so much information to help understand the problem.

This issue has nothing to do with starting credit balances though. It’s simply a case when paying funds back to customer (e.g. refund) without specifying an invoice, Manager won’t automatically increase balance due on previously paid invoices. This can produce a weird state where customer can owe you money even if all their invoices are paid. But is this a bug? I’m not entirely sure. You could argue this is a bookkeeping error too. Usually you don’t refund money to customer unless they have a credit. In this case, if you are refunding 10,000 because the invoice is being refunded, you’d issue credit note too, right?

[image] lubos: But is this a bug? I’m not entirely sure. If prior to starting with Manager a Customer has double paid an Invoice, then they have a “credit” balance so that becomes their starting balance within Manager. If subsequently, after starting with Manager, the customer is refunded that double payment then that payment should cancel out the opening credit balance. But as I understand the example, that payment is not cancelling out the opening credit balance, but instead is being applied against invoices dated after the payment. [image] lubos: Usually you don’t refund money to customer unless they have a credit. The balance is a credit but just not from a credit note. Then perhaps, Manager shouldn’t allow for an opening credit balance to be entered just as a figure as per the current method, but instead, such opening credit balances should be entered via a Credit Note. So at the starting date, if the Customer has an opening debit balance, then you enter any unpaid invoices (as currently) but if the Customer has an opening credit balance, then you need to enter an unallocated credit note. Now when the refund payment is made it can be allocated against the credit note, to cancel it out and doesn’t affect later transactions. Or to put it another way, currently Manager requires documented entries (invoices) to create a debit balance but doesn’t require any documented entries to create a credit balance, its just an entered figure.

[image] lubos: But is this a bug? I think so, because it results in a misrepresentation of position for reasons the user cannot discern or diagnose. [image] lubos: In this case, if you are refunding 10,000 because the invoice is being refunded, you’d issue credit note too, right? Definitely not (as things are currently designed), because the event that created the credit balance occurred before the start date. You might have issued a credit note in a previous accounting system. You would not want to repeat that. Or the credit balance might be the result of a dispute settlement. Whatever the origin, the credit balance (an equivalent liability of the company) existed on the start date, so it seems appropriate to me that it somehow be set as a starting balance, not created after the start date. I will, however, agree that one way to set starting credit balances is by @Brucanna’s suggestion to enter pre-start-date credit notes, paralleling the way debit balances are created by pre-start-date sales invoices. That has the benefit of consistency. [image] Brucanna: Now when the refund payment is made it can be allocated against the credit note, to cancel it out and doesn’t affect later transactions. Conceptually, this is all right from an accounting perspective, but you cannot allocate a payment to a credit note in Manager. You also should not need to allocate specifically to the credit note, as long as you allocate to the customer. In all this discussion, it has not been mentioned that the same situation will exist for supplier starting balances. Whatever solution is decided for customers should be duplicated for suppliers.

The above illustrated bug has wider issues then just the one illustrated above. A) If the starting credit balance is refunded via a payment prior to the invoice (6,000) being created and that invoice includes a tax component and remains unpaid, then on the tax summary report - cash basis, that unpaid invoice is listed as a “paid” transaction due to its false “Paid in full” status as illustrated above. B) The aging section on the report > Customer Statements (Unpaid invoices) is not correct. Refer to the topic Non Cash transactions appearing on Cash Basis tax reporting - #9 by Solnce for illustrations.

I understand that this on one is not the priority, but is there any chance to have this solved in near future?

As a workaround, instead of giving the customer a starting credit balance, create a Sales Invoice predating the Start Date for that Customer but with a negative value (minus sign in front) to equal the starting credit balance and using the word “Credit” as the invoice number. Then for the Spend Money, make sure you do the full allocation to Accounts Receivable + Customer + Invoice (Credit). PS: You should delete the existing starting credit balance entry first.

Fixed in the latest version (19.1.18). Before transactions are matched to invoices, the system will offset any refunds. This should avoid issue where customer can have invoices which are paid while at the same time owing money. The same applies to suppliers.

Mishandling payments against customer starting credit balances

Uncategorized

Topic		Replies	Views
Starting balance for Customer with Credit balance Uncategorized	9	1177	June 18, 2021
Invoice paid by beginning balance Uncategorized	3	503	June 22, 2019
Newly created invoice shown as paid Uncategorized	22	1487	March 28, 2018
Customer starting balance issue Uncategorized	2	375	January 26, 2023
The starting balance for partially paid invoices Uncategorized	3	292	July 29, 2022

Mishandling payments against customer starting credit balances

Related topics