I need to change an invoice but get this: This is an Unpaid Invoice. You cannot modify an Invoice that is Unpaid.

[Web Host Pro]

Can someone please tell me how I can change an unpaid invoice? The price has changed and I need to adjust it. 

WHMCS is giving me this error when I try This is an Unpaid Invoice.
You cannot modify an Invoice that is Unpaid.

Which doesn't make any sense, of course I will need to change unpaid invoices. 

[pRieStaKos]

 

 

[bear]

1 hour ago, Web Host Pro said:

Can someone please tell me how I can change an unpaid invoice? The price has changed and I need to adjust it. 

WHMCS is giving me this error when I try This is an Unpaid Invoice.
You cannot modify an Invoice that is Unpaid.

Which doesn't make any sense, of course I will need to change unpaid invoices. 

WHMCS decided that immutable invoices should be the default, with no chance of shutting that off for those that don't want or need it. 
This is allegedly being addressed in the latest version; the one where they will be forcing a marketplace account on everyone with no opt out. 
Enjoy. 

To change an invoice now, I believe you need to cancel the current one and recreate it, causing much confusion to the client. 
Again, enjoy? 😉

[Web Host Pro]

2 hours ago, pRieStaKos said:

That thread is outdated, I added this and got an error: Invoice immutability is disabled. We have deprecated the ability to edit invoices and we will remove the option to enable invoice mutability in a future release. Learn More » 

Any Any feedback that current?

 

 

[Web Host Pro]

1 hour ago, bear said:

WHMCS decided that immutable invoices should be the default, with no chance of shutting that off for those that don't want or need it. 
This is allegedly being addressed in the latest version; the one where they will be forcing a marketplace account on everyone with no opt out. 
Enjoy. 

To change an invoice now, I believe you need to cancel the current one and recreate it, causing much confusion to the client. 
Again, enjoy? 😉

This is wacky, WHMCS thought we should not be able to edit our own invoices? Do they think they own our invoices? This is almost as weird as when they wouldn't let us change an account password. 

So what do you do, delete the invoice and create a manual one that won't sync to the product? What's the process if you need to change an unpaid invoice? 

[Waqas Ahmed Waseer]

On v9 the supported way is to reissue the invoice rather than edit it. It takes a minute once you've done it a couple of times:

1. Open the unpaid invoice and click Duplicate Invoice. The copy is created as a Draft with the same line items, invoice date, due date and payment method.

2. Edit the Draft copy (new price, description, whatever changed), then click Publish, or Publish & Send Email if you want the client to get the corrected one straight away.

3. Go back to the original invoice and Mark Cancelled.

Don't forget to fix the price at the source too, otherwise the next renewal invoice comes out with the old amount again. On the client's service (Products/Services tab) update the Recurring Amount, and if the product price itself changed, update the product pricing as well.

If you really want the old behaviour back, it's still there for now: Configuration > System Settings > General Settings > Invoices > Invoice Immutability, pick one of the "Immutability disabled" options. That's also what triggers the "Invoice immutability is disabled" banner you saw. WHMCS says that option will be removed in a future release, so I'd get used to the duplicate, publish, cancel routine instead of building your workflow around editing.

[Nathan Davis]

The duplicate-publish-cancel sequence makes sense, but I'm wondering about the client-side confusion bear mentioned. If you cancel the original and publish the draft copy, does the client end up with two invoice records visible in their billing history, or does marking the original cancelled hide it? For a small operation that's probably fine, but it seems like it could generate support tickets from clients seeing a cancelled invoice next to a new one. Also curious whether the duplicate keeps the same invoice number or generates a fresh one, since that affects how it reconciles with accounting records.

[Waqas Ahmed Waseer]

Good questions, both worth knowing before you do this on a live client.

The client will see both. Cancelled invoices still show in the client area invoice list (there's a Cancelled status filter in the sidebar on the default themes), so the original stays visible next to the new one. Draft invoices aren't shown to the client, which is why I'd do it in that order: get the corrected copy ready as a Draft first, then publish it and cancel the original back to back, so they never see two unpaid invoices at the same time.

What cuts down the tickets for us is putting a short note on the new invoice before publishing, something like "Replaces invoice #1234 (price correction)". The Notes field on the invoice is shown to the client on the invoice itself, so they get the explanation without having to ask.

On numbering: the duplicate is a new invoice with its own new ID, not the same number. If your accountant cares about gaps, look at Sequential Paid Invoice Numbering under Configuration > System Settings > General Settings > Invoices. With it on, the formal invoice number is only given out when an invoice is paid, so a cancelled one never takes a number in that sequence and your paid run stays gapless. If you already reconcile on the invoice ID, just keep the old and new ID together in that note so the trail is clear.

One more check before you publish: open the line items on the draft and make sure they're still tied to the client's service or domain, so paying it renews the right thing.

[Michael Wilson]

The duplicate, publish, cancel sequence makes sense, but I'm wondering about the client-side side effects. If I cancel the original and publish a duplicate, does the client end up seeing two invoices in their billing history for the same period, or does cancelling hide the original from their view? Also, on the recurring amount fix, is updating it on the service enough, or have you seen cases where the product pricing change didn't propagate until the next billing cycle? Trying to avoid the exact confusion pRieStaKos and bear were describing before I start cancelling anything.

[Waqas Ahmed Waseer]

@Michael Wilson the client-side part is covered in my reply just above (Nathan asked the same thing): cancelled invoices stay visible in the client area, the duplicate gets a new ID, and a "Replaces invoice #..." line in the Notes field heads off most of the tickets.

On the recurring amount: WHMCS builds the renewal invoice from the Recurring Amount on the client's service, not from the product's current price. So changing the product pricing on its own doesn't touch existing services. Either edit the Recurring Amount on the service directly, or tick Auto Recalculate on Save on the service and save, which pulls the current product and configurable option pricing into it.

The catch that usually trips people up is timing. If the next renewal invoice has already been generated (that depends on your Invoice Generation days setting under Automation Settings), updating the  service won't change that invoice. It only affects invoices created after the change. So check the client's Invoices tab first: if the upcoming one already exists, fix it with the same duplicate, publish, cancel routine, and the corrected service amount takes care of everything after that.

[Junaid Omer]

https://marketplace.whmcs.com/product/9186-extended-invoice-manager
I am using this addon

[Nathan Davis]

The note on the new invoice is the part I hadn't thought about — putting "Replaces invoice #1234" in the Notes field so it shows on the invoice itself seems like the simplest way to head off the tickets. On the numbering question, if Sequential Paid Invoice Numbering is on, does the cancelled original keep whatever ID it already had assigned, or does it stay out of the paid sequence entirely until it's paid? I'm trying to picture how that looks when reconciling later. Also good call on re-checking the draft line items are still tied to the service before publishing.

[Waqas Ahmed Waseer]

@Nathan Davis The cancelled original stays out of the paid sequence entirely. With Sequential Paid Invoice Numbering on, an invoice only takes a number from that sequence at the moment it's paid. Until then it's a proforma, identified by its internal invoice ID. So the one you cancel never uses up a paid number, and the replacement picks up the next number when the client pays it. Nothing gets skipped.

For reconciliation that leaves you with two different references:

• The invoice ID (the one in the URL). The cancelled original and the replacement each have their own, and the IDs will drift away from the paid numbers over time. That's normal.
• The paid invoice number. Only the replacement gets one, once it's paid.

If your accountant works off the paid sequence, the cancelled original simply never appears there, and the "Replaces invoice #" note ties the two together for the client and for anyone searching later.

One case behaves differently: if you cancel or refund an invoice that was already paid, it keeps the paid number it was given, so the sequence still has no gap. It's worth checking how your invoice template labels those, because some older custom templates print "Proforma" for anything that isn't marked Paid.