In our neck of the woods the tax men and women want to have a continuous invoice numbering when we get an audit. Because breww assigns a number when creating an order and this directly corresponds to the invoice number -we need to be extra carefull not to cancel orders but to re-use the number - otherwise I get holes in my invoice numbering.
Often programs use seperate order and invoicenumbers because of this reason. Another solution could beto assign an order number when an order is marked as confirmed and leave the number as “draft” or “concept” before this point?
Thanks for getting in touch about this.
We do have a similar rule in the UK, however, it is acceptable to have gaps in the sequence if you have a record of why there is a gap. The UK guidance states:
What if there is a break in sequence, for example where I cancel an invoice or it is spoiled and never issued to a customer?
As long as you retain the cancelled or spoiled invoice in your accounting records, or you can provide an explanation for the break in sequence, this is acceptable.
I appreciate you’re not in the UK so your rules might differ. Do you know if you have a similar concession for cancelled orders, as we do here in the UK? If so, this would mean that the current Breww approach could work for you without the complications of making sure you don’t forget to “reuse” missed numbers. In Breww we don’t let you delete orders ever (they can of course be cancelled), and this is partly to ensure you can never lose the record of why a number was missed.
If this isn’t acceptable to your local tax authorities, we can look for a solution that is
As a side note, one of our main reasons for using the same number for orders and invoices is to avoid confusion, especially when these numbers are shared with customers. For example, a customer phones you to discuss “Order 123” and you have both an order 123 and an invoice 123 and you’re not sure which is being referred to.
Thanks for the response. Good to know you thought this through. I’ll check with my accountant again how big this problem is