Allow credit to have a payment behind it

[TekWarren]

What version of Invoice Ninja are you running? v5

What environment are you running? Docker

Additional context Currently credits can have a monetary value...but not a payment or paid for value. This makes working with lump sum payments (what I would consider prepaid "credit") that are used to cover multiple future invoices not as convenient to work with and do benefit from how IN handles what it considers credit.

For example being able to create a credit with a selectable payment type (cash, credit, etc) would trigger the credit have an actual incoming monetary value (what IN considers a payment). Currently credits have a value that can be applied to invoices but this value is not considered a payment. Thus all credits are technically free monetary amounts from the business and not calculated as income or payments when sometimes they should be.

Hope this makes sense.

[TekWarren]

From a discussion about this with @hillelcoren on the forum:

I am wondering how the system intends lump sum prepayment (paid credit) to be tracked in a way that is both useful to business user and clients. Without being able to somehow link a credit to a payment, prepayments that are used to cover multiple future invoices lack all the features credits have for tracking and reporting purposes. The only thing I can think of is do this manually:

The only other thing I can think of to handle this is to create both a payment and a credit when a client pays in advance. The payment would just be there to account for the money received from the client and not be applied to any invoices. The matching credit would then be used towards future invoices and benefit from how the system handles and displays credits.

Can you think of any adverse affects of doing this? Since I now know that the value of a credit is not accounted for as a payment…this should both serve to accurately log the incoming payment as well as provide a method to distribute and track it as a credit. It’s not ideal and maybe a feature could be added to allow this to happen automatically with an option selected but I need to figure out the best way to make this work.

[turbo124]

I don't think creating a payment and matching credit will work as intended a credit is still considered as "cash" as it is able to pay down an invoice balance.

You can see this in action if you generate a customer statement, you'll be able to see the payment amounts applied to the invoice.

[TekWarren]

@turbo124 I understand credits can pay down on invoices, but my issue is that credits can not be accounted for as money paid by clients (a payment in invoiceninja terms)... at least from what I understand and have been told by @hillelcoren.

Because a large portion of our business involves prepayment, I want to be able to treat that money as (paid) credit and use the functionality invoiceninja provides with credit.

Circling back to the issue with my dashboard numbers being off ... I believe the reason for this was because I was entering customer prepayments (actual cash or checks received) as credit (so I could use the credit functionality) and not as payments.

In my test instance I went through and manually created payments for each past "credit" I had entered that should be accounted for as money paid. I then deleted the credits and applied the payments to those old related invoices. This tipped the dashboard numbers in the correct direction.

I guess I need some guidance on these items:

How are credits intended to be used in invoiceninja? Can credits represent actual payments or are credits always assumed to be something like a refund, discount, or free dollar amount given to the client?

What is the intended practice for managing regular lump sum prepayments that will then be applied to multiple future invoices? I can make a "payment" without an invoice but payments do not get any of the nice functionalities that credits do and I am having a hard time figuring out an automated way to keep clients updated on their balance. -When I was (I think) doing it wrong and entering prepayments as credits, I could use the statement report. There are reports that can do this but clients are likely to have a hard time with or not even look at a spreadsheet based email attachment.

Sorry for the long reply.

[TekWarren]

Apologies for double post as I keep trying to dig into this. I've spent some time today looking at the user guide to see what it says about credits.

The first line states: A credit note is a document sent to the client, notifying that a credit has been provided to their account. Credit notes are used to issue redeemable credits for a specific Product or for a flat rate. Credits can be applied to invoices as a payment.

If I am I correct in what I did wrong initially (assuming that credits can also be a form of payment), it might be nice to add to the end of the line above in the documentation: Credits can be applied to invoices "as" a payment...but are NOT payments received from the client, only a credit GIVEN TO the client.

There is another statement in the documentation that says when you delete credits, the applied amount stays applied to the invoices. This is not what I experienced when deleting credits in my test instance. When I deleted credits, invoices paid for by those credits changed status to UNpaid, I was then able to create a "payment" for the same amount and apply that those credits to mark them paid again.

I am still left wondering how best to square up my mistake because I have several "credits" that where actually payments (money received) from clients and what is the appropriate or intended way to handle prepayment going forward.

[TekWarren]

Hi @turbo124 any thoughts on this? Apologies for pushing I just need know how to fix what I have done.

I can only see two options: one is deleting the credits and replacing them with payments and reapplying the payment to the invoices. OR just creating a matching Payment and not applying it to any invoices but just having as a record of money received from the client.

The first option is what I tried in my test instance and it seemed to come out okay.