If you use any deterministic algorithm(operating on the global invoice ID) to do this, then you're susceptible to the user finding out the numbers.
Since we generally reject Security by Obscurity, you have to assume the user knows how you're generating the invoice number.
Let's call your algorithm $H$. If you give to the user $H(n)$, they can simply enumerate through the natural numbers and apply $H$ to them.
That is $$A=H(n)$$ $$H(1) = A?$$ $$H(2) = A?$$ $$...$$ $$H(n) = A?$$
Yes! it does. Therefore the invoice number is $n$. This even has the advantage that once you find out the number for one of your invoices, you just start the next one from your last invoice number. Unless you get many millions of invoices, this is going to be a feasible solution.
This means that the number has to be generated non-deterministically. I.E using randomness. You could just generate a unique random number for each invoice, and give that to the user. Or, since generating a unique number gets slow as you get more invoices (have to check all the previous numbers) for each user or each day or both you can have a prefix on the number, then put your randomly-generated number after it. This way you'll generally have to only check a few invoices. You can also number the invoices incrementally, starting from 1 with each user (with a prefix)