Not all invoices are created equal

12 Mar 2013

This is a post about invoice numbers. Don’t say I didn’t warn you.

I started a company recently. Starting a new organisation is an opportunity for certain indulgences:

  • you get to choose a name
  • you take decisions on how things look
  • you get to set things up the way you want

As I’ve amply demonstrated already, I like thinking things through (some might call it overthinking). There won’t be many people affected by my invoice numbering scheme, and quite possibly even fewer who are interested, but here are the reasons why I have not gone for just ANG001, ANG002.

I wanted a scheme that had the following properties:

  • short. Online banking often only allows a few characters in “reference number” columns, and shorter codes means fewer typos.
  • unlikely to cause confusion during transmission/pronunciation. Should be resilient to substitution of zero for “O”, etc.
  • sortable. Given a list of invoice numbers, I want to be able to sort them alphabetically and for them to end up in chronological order.
  • sequence visible. I wish this was unecessary, but if someone is auditing things, it needs to be obvious from a list of numbers that the whole sequence is present.
  • verifiable. I’d like a check digit, to reduce mistakes in transmission. Even better, I reckon I can make it difficult for an unauthorised person to generate invoice numbers.

Here a sample invoice number, and a break down. The hyphen is just for presentation:


D3C encodes year, month and day using Crockford base 32 encoding. This ensures sortability is more succinct than something like 20130312, and using this encoding means there aren’t any potentially-confusing letters in there.

AN is a client code, and 001 a sequence. I need to ensure no confusing characters sneak in here, either - but as you’ll see momentarily, I’m using a computer to generate things, so I can be rigorous.

GY represents 10 bits of a SHA-1 hash, again using Crockford encoding. The hash is performed on the other eight characters, plus a secret phrase. These two characters make unauthorised generation of invoice numbers difficult (well, 1 in 1024), and provide a way for people who know the secret phrase to verify them.

Over-complicated, maybe, but the complication is entirely on my side. Once it’s out there “in the wild”, these invoice codes are just a ten character sequence.

Expect more geekery about decisions taken whilst working for/setting up Angent Ltd…

Tags: angent, code