If you are building or using an e-commerce system and want to look all professional, you need invoice numbers. Invoice numbers are required, at the very least, for auditing purposes by most businesses. However, nothing says "not professional" quite like "dressing in a shirt that is flashier than a light pinstripe" or invoice numbers based solely on a MySQL 'auto_increment' field starting at '1' or, worse, a false arbitrary starting value.
Searching Google for an industry-standard practice of creating an invoice number turns up pathetic results. So this blog entry aims to correct this severe oversight of the Internet and bring it down to the level of the average programmer.
Businesses that are large enough have dedicated finance departments. These people like things to be EXTREMELY organized. If you are developing an application that is going to bring in money (e.g. an e-commerce solution), it needs to generate sequential orders that can be verified later should the organization be required to perform an audit. Audits are annoying. If you start numbering invoices/orders at 500, the auditor is going to want to know where invoices 1 through 499 are. So, you really should start numbering orders at '1'. However, from a customer's perspective, being the first person to order anything is viewed as rather "tacky" for the invoice. So, what should be done about this?
Invoice numbers should represent the order in some fashion that makes sense and makes looking up the order later on easy to do. It should also include some letters with the numbers. What follows is my own blend of parameters that creates a rather good-looking invoice number in most cases, makes it easy for programmers to extract the order number, AND meets the auditing restrictions imposed by most businesses:
CompanyAbbreviationYYMMDD-OrderNum
So, a sample invoice number could be:
CS101119-1
The example is the company "CubicleSoft" abbreviated to an acronym, the two-digit year, two-digit month, and two-digit day of when the invoice was created (November 19, 2010), a hyphen (-), and then the order number (Order 1). It could be the very first order ever in the system but the customer won't notice - they will likely just think it was the first order of that particular day. For programming purposes, it is easy to locate the hyphen, convert whatever comes after that to an integer, and then use the value to look up the order in the system. In fact, the only thing that really matters with the invoice is the number after the hyphen. The stuff before the hyphen can just be used for verification purposes.
The next issue is that finance departments require the ability to map an invoice number to the money. That is, they need to be able to exactly match the order to each and every penny. An e-commerce solution depends on a third-party to process the payment. This creates a disconnect between the order and the payment that must be resolved. The invoice number on the payment end of things must match the order entry system or auditors get unhappy. Therefore, be sure to send the payment processor the fancy invoice number so when someone later on goes to do a report, they can easily get that information, which makes that person's life easier and simpler.
In conclusion, I really like that video. :)
Searching Google for an industry-standard practice of creating an invoice number turns up pathetic results. So this blog entry aims to correct this severe oversight of the Internet and bring it down to the level of the average programmer.
Businesses that are large enough have dedicated finance departments. These people like things to be EXTREMELY organized. If you are developing an application that is going to bring in money (e.g. an e-commerce solution), it needs to generate sequential orders that can be verified later should the organization be required to perform an audit. Audits are annoying. If you start numbering invoices/orders at 500, the auditor is going to want to know where invoices 1 through 499 are. So, you really should start numbering orders at '1'. However, from a customer's perspective, being the first person to order anything is viewed as rather "tacky" for the invoice. So, what should be done about this?
Invoice numbers should represent the order in some fashion that makes sense and makes looking up the order later on easy to do. It should also include some letters with the numbers. What follows is my own blend of parameters that creates a rather good-looking invoice number in most cases, makes it easy for programmers to extract the order number, AND meets the auditing restrictions imposed by most businesses:
CompanyAbbreviationYYMMDD-OrderNum
So, a sample invoice number could be:
CS101119-1
The example is the company "CubicleSoft" abbreviated to an acronym, the two-digit year, two-digit month, and two-digit day of when the invoice was created (November 19, 2010), a hyphen (-), and then the order number (Order 1). It could be the very first order ever in the system but the customer won't notice - they will likely just think it was the first order of that particular day. For programming purposes, it is easy to locate the hyphen, convert whatever comes after that to an integer, and then use the value to look up the order in the system. In fact, the only thing that really matters with the invoice is the number after the hyphen. The stuff before the hyphen can just be used for verification purposes.
The next issue is that finance departments require the ability to map an invoice number to the money. That is, they need to be able to exactly match the order to each and every penny. An e-commerce solution depends on a third-party to process the payment. This creates a disconnect between the order and the payment that must be resolved. The invoice number on the payment end of things must match the order entry system or auditors get unhappy. Therefore, be sure to send the payment processor the fancy invoice number so when someone later on goes to do a report, they can easily get that information, which makes that person's life easier and simpler.
In conclusion, I really like that video. :)
As this video is on a .co.uk website, I think I ought to point out that regulations in the UK now require invoice numbers to be in a series. That series does not need to begin at 1, nor does it need to increment by 1, but the increments must be consistent: if you increment by 5, 10 or even 17(?!), you must do so each month.
ReplyDeleteHowever, each client/customer may have their own series, and projects for that client may have their own series as well. You can even start your series again each year.
If you're a smaller organisation, you don't want your clients to know how many invoices you're issuing, so have a system. Mine is the client code (followed by the project code, if there is one), followed by the year and then a sequential number. I did think you use only the last two digits of the year and then it occurred to me that, since accounting records are typically kept for 7 years, I needed only the final digit of the year.
My clients have a 6-digit code, so if there isn't a project code, an invoice number looks like this:
150209-507
where this is the 7th invoice to client no 150209 in the most recent year ending in 5 (e.g. 2015). I suppose I could start at x00, rather than x01, for each client. This allows me to send up to 99 (or 100 if starting at x00) invoices per year: 2 almost every week, which is highly unlikely. I typically invoice once per month, so I need 12 numbers, meaning I need 2 digits.
Interesting. On a side note, incrementing/serial invoice numbers can actually be a security vulnerability in the application. Some websites have exposed other invoices simply by changing a URL to another easily guessed invoice number. One of the major U.S. airlines had this problem - exposing travel information for all of their passengers.
DeleteIt is also possible to accurately guess how much money has been made off of a product with many invoice number systems. Legally forcing an evenly incrementing order number might result in exposing a lot of different organization's financial information if they decide to just strictly follow the rules and don't come up with a way to obscure order numbers. Most organizations try to keep financial information private. Order numbers can expose much more than most organizations anticipate.