Understanding How Recurring Invoice Numbers Work

Self-Hosted | v5
1

Version v5.11.78

Environment Other - Rocky 9 VM, nginx, npm, MySQL

I keep having issues with how my Recurring Invoices are generated each month in the year cycle. As I resell license agreements along with IT services/support agreements, this is super important for me to understand and get right.

My regular invoice numbers are generated 01234, but I want my recurring invoice numbers to get generated as 01234-1 from the initial invoice that invoked the recurring product or service.

  • So if Invoice #00020 starts a 1-year software license along with maybe some implementation or migration costs, I want #00020-1 to be the first month of the license, and the 2nd month of the license would be #00020-2, and so on for the whole 1-year commitment.

Except, the new invoices that get automatically created and sent from the Recurring Invoice entry keep adopting new invoice numbers, like #00021, and #00022, which is bad!

This is currently how my Invoice Number generation is set:

image
image535×179 4.84 KB

image
image588×190 5.9 KB

But, today Recurring Invoice #00016-1 generated Invoice #00022 for the new license month which is not desired! I keep needing to manually adjust my recurring invoices to fit with the expected cycle.

image
image588×325 13.2 KB

What am I not understanding here about Recurring Invoice logic and their generated number value?

2

Hi,

I think you may be confusing the recurring invoice (which is a template) with the standard invoice which is generated when it runs. In most cases the recurring invoice number doesn’t matter, it just identities the template. What actually matters is the number of the invoice it generates.

3

AHH… That makes sense to think of the Recurring Invoice solely as a template, and NOT as the first invoice in a cycle of self-similar invoices as I previously was.

So is my desired logic not possible then? – Where newly created invoices in the Recurring Invoice number are all on the same number but with only the -# incrementing?

I know this logic is maybe a bit weird. I just thought it would be a good idea for my clients and I to be able to track which invoices from me are one-offs and which ones are on a recurring cycle (as indicative of the #####-#).

4

I don’t believe that’s currently supported, one solution maybe to use a webhook or a tool like Make to update the number after the invoice is created.

5

Hmmm that then still leaves the issue of the incorrect invoice number being shown to the end-client when the Recurring Invoice automatically sends the next invoice in the cycle, thus still reducing this entire process to manual effort if I want to continue this naming scheme. :woozy_face:

So can I ask: What then is the defined logic or expected usage for the Recurring Invoice Number Pattern in the app Settings?

6

If you use a webhook or Make you can disable auto-email to adjust the invoice after it’s created but before it’s sent to your client.

Not sure I understand your question. The pattern defines the number, the number is a unique identifier.

7

Hey there Hillel,

In my previous post, I was basically just asking what does the Number Pattern field under Settings > Generated Numbers > Recurring Invoices actually do because it seems that Invoices which are created from a Recurring Invoice end up just following the regular Invoice’s Number Pattern anyway?

I think Recurring Invoices having their own Number Pattern and Counter fields is what originally led me to believe that Recurring Invoices are a distinct type of Invoice suited for monthly subscriptions, licensing, recurring commitments, etc. instead of just simply serving as a template, as you clarified for me.

Continuing on the understanding that they’re indeed templates, it then becomes a bit confusing for me what the functionality of Number Patterns for Recurring Invoices are, since the actually Recurring Invoice itself is just a template for future regular Invoices to be generated from.

Does that make sense? I’m just trying to understand how this all works at a deeper level. As InvoiceNinja is indeed becoming quite an important tool for my startup to operate!

8

That’s correct.

The “functionality of Number Patterns for Recurring Invoices” is just way to control the numbering of the records, it’s provided for all top level entities.

9

Right but what I’m trying to say is that there is no observed resulting effect that the Number Pattern field for Recurring Invoices seems to take anywhere in the application. That’s why I’m asking: what does the NumPat for RecInvs actually do? Because, as we’ve discussed here – Recurring Invoices – simply just generate regular Invoices. But regular Invoices already have a distinct associated Number Pattern – which is what Invoices generated from a Recurring Invoice follow anyway! – This is what I’ve been observing in my own instance, and what is part of the original problem I’ve brought up in this thread.

So that’s what I’m trying to articulate here, is that the NumPat for RecInvs doesn’t seem to result in any practical application within InvoiceNinja. Unless I’m missing something here?

10

It determines the number of the recurring invoice itself.

11

Ahh, I’m sorry if this getting to be a bit painful. But that just doesn’t seem to be how Recurring Invoices work in my instance. :sweat_smile:

From what I’ve observed in my instance, Recurring Invoices just generate a regular invoice with the line item details and client info copied over. The resulting generated invoice number is yielded directly from the Generated Number field value for regular Invoices.

For context, I’m a startup IT MSP, I have a few clients from personal connections so far. I currently have 2 clients on license subscriptions which are billed monthly, one for Google Workspace and one for M365, both setup in InvoiceNinja as Recurring Invoices.

image
image1416×401 27.8 KB

Here is my Number Pattern for Recurring Invoices:

image
image968×408 17.4 KB

Here is my Number Pattern for regular Invoices:

image
image801×395 16 KB

Both of those Generated Number fields have been untouched for a couple months now.

A few weeks ago, Recurring Invoice #00016-1 generated Invoice #00022, which I had to adjust to become Invoice #00016-3, as was the intent with my Recurring Invoice Number Pattern field value – and what prompted this forum thread to begin with. I had to notify the client accordingly too as an automatic email was sent for the incorrectly generated invoice.

image
image654×521 23.4 KB

Same thing happened recently with my other license subscription… Recurring Invoice #00017-3 generated Invoice #00023, which I needed to fix and resend as Invoice #00017-4.

image
image650×516 24.1 KB

I’m showing these to illustrate that the Recurring Invoices generate regular Invoices using the Regular Invoice Generated Number Pattern field value, not the Recurring Invoice’s Generated Number Pattern field value. This, as you can see, becomes a bit problematic for me when it comes to organizing and managing license subscriptions. I hope to also sell hosting agreements, and Managed Services bundle contracts in the near future too, which will all also require that I have a solid handle on how Recurring Invoices are generated.

Once the 1-year agreements for Recurring Invoices #00016-1 and #00017-1 are completed and my clients renew them, that would of course invoke a fresh new invoice at the latest counted number. When either myself (or a future employee) or a client see for example Invoice #00016-1, #00016-2, #00016-3, etc. etc… — #00016-12, everyone knows that they’re for a Monthly Commitment predicated on an associated contract/agreement.

This is what would make Recurring Invoices work amazingly well, except in this context, it falls apart a bit because as I’ve shown here, the Recurring Invoices do not just follow the Recurring Invoice Generated Number Pattern field, they instead follow the regular Invoice Generated Number Pattern field. Which doesn’t seem very intuitive. This is why in my previous posts here I’m asking what the Recurring Invoice Generated Number Pattern field actually does, because I cannot seem to find any observable resulting effect of it.

Does that all makes sense? To that end, is there an issue with my understanding of something here or is there an issue in how the Generated Number field for Recurring Invoices works?

12

I mean if you click ‘Create new recurring invoice’ and click save

13

I’m not sure I understand? Both of my Recurring Invoices for license subscriptions are currently saved with the Recurring Invoice Numbers shown in my first screenshot above.

14

Maybe it’s a bug? I would expect the number to end with -0.

15

A-ha!! So presuming this may be a bug (yet to be confirmed of course), then my presumed understanding of the Recurring Invoice’s functionality from my very first original post sounds like should work as intended then?

My regular invoice numbers are generated 01234, but I want my recurring invoice numbers to get generated as 01234-1 from the initial invoice that invoked the recurring product or service.

So if Invoice #00020 starts a 1-year software license along with maybe some implementation or migration costs, I want #00020-1 to be the first month of the license, and the 2nd month of the license would be #00020-2, and so on for the whole 1-year commitment.

Where, I can continue issuing 1-off invoices as needed as 01234 while my Monthly Recurring Invoices can be generated as 00112-01, 00112-02, 00112-03 etc., right?

If that’s the case, I can happily file a bug on the GitHub repo using my experiences and findings here.

16

As mentioned previously I think we may be using the term ‘recurring invoice’ differently. If you click the ‘Recurring Invoices’ option in the sidebar you’ll see recurring invoices, I believe you referring to the standard invoices generated by a recurring invoice.

17

Vermutlich liegt der Unterschied daran, wie das System zwischen Vorlage und tatsächlicher Rechnung unterscheidet