[CodesInChaos]

You generally can't rely on strict monotonicity of primary keys, since the order in which transactions commit isn't necessarily the order in which the ids were generated. But I have relied on primary keys being "monotonic enough" to sort output by creation time for display purposes.

[OptionOfT]

I've worked on invoicing software where we had to introduce a public, always +1 counter to ensure there are no gaps between invoices. Not +2, not +5.

That way you couldn't make them disappear.

[chiph]

In the days when you used custom printed forms that had a number printed on them by the printer - when you loaded a new box of paper into your printer you had to input the first form number into the system so they'd match.

If you opened boxes in "whatever" order you'd have invoice numbers that would run contiguous for 150 or so counts (the number of forms in the box), then skip to the next multiple of 150 to correspond to when the next (or previous!) box had been used.

[stefs]

That mustn't be the primary key, though, but a serial that counts (and is unique) per-customer.

[OptionOfT]

This was before the SaaS days.

On-prem, single company who issued invoices to customers.

When there was an audit the government could ask to see invoices in a certain range. If some of them were missing, what does that mean? Paid under the table?

My wife worked at a place where they did manual PDFs, but there they had a tool to change properties of a PDF to change the creation time / last editing time, for when 'modifications' were needed.

And this reminds me of the other post here where some people assume cash means shady. Definitely the case there.