Enhancement Request: Invoice Number Padding

I have what is hopefully a small enhancement request - would it be possible to add an option to the Sales Invoice Template Settings to specify number padding? I’d like to be able to pad the invoice number to six figures with leading zeros.

My current finance system uses the format ‘INVxxxxxx’ where x is the padded invoice number (e.g., INV000123 or INV001234). For consistency, I’d like to maintain this format post-migration. I know I can set the ‘INV’ prefix but the padding is an issue at the moment.

Thanks very much.

I had the idea of using a custom view template to achieve the number formating I want but have unfortunately hit a brick wall.

My plan was to hard code the ‘INV’ prefix into the template and set the Invoice number prefix in Sales Invoice Settings as 00000. This would create a reference of, for example, INV00000123. Since I want the numeric part of the reference to be six digits long, I intended to use the split standard filter in Liquid to effectively cut out the leading zeros that push the figure beyond six digits.

This is the line I used in the template but it doesn’t work:

INV{{ reference | slice: -6, 6 }}

All elements of the invoice reference are present but the leading zeros are not dropped and I can’t see why. As a test, I put in the following line lifted direct from the Liquid guidance ([here][1]); it still doesn’t work (it should output “llo” i.e., returns the last three characters of the string only):

{{ "hello" | slice: -3, 3 }} 

I wonder if Manager isn’t compatible with this filter or if I’m doing something wrong? Any help is appreciated.

[1]: Liquid for Designers · Shopify/liquid Wiki · GitHub

You are right, “slice” filter wasn’t supported. Check the latest version (15.1.13) where it was added.

You’re a gent. Thanks very much.

Hi Lubos,

Sorry to bring up such an old thread but it seemed a better option than creating a new, similar one.

I’ve just updated to 16.9.71 and it seems the slice feature of the Liquid markup isn’t working again, meaning that invoice numbers in my custom invoice template which were showing as, for example, INV001234 are now reading as INV1234 (where INV is hard coded and 1234 is the document number which I padded as detailed above).

Has this feature been removed and if so, is there an alternative? I know it’s a relatively minor thing but I like to see consistency in number formats, particularly where I’ve had them established for a long time.

Thanks for your help.



Not sure why this issue has re-appeared but check the latest version (16.9.73), should be fixed.

Thanks for looking into that, Lubos. Much appreciated.

Can I just check one other related thing with you - I had my Invoice Number Prefix in Sales Invoice Settings (back when I started this thread, so a while ago now) with a prefix of 00000. I would use this in conjunction with the slice feature in Liquid to create a six digit padded invoice number.

Am I right in thinking that particular settings option has been depreciated? I ask because firstly, I can’t find it and secondly, I’m getting an error with slice because the character length in the invoice number field is too short leading me to conclude that the prefix I had originally set for invoice numbers is no longer valid.

It’s not a major issue if that is the case - I’ll just hard code the padding into the template as a workaround. I just wanted to check that I’m not missing something though.



Yes, it has been. Initially, it was preserved only for legacy businesses, then later was removed for all businesses.

Thanks, Tut. I thought that would be the case but it’s a very minor thing with an easy workaround so all is well!


I realise this is an old thread, but could you please post your workaround to this issue?

I am also interested in inserting a text prefix with padded leading zeros for the invoice number.

Thanks a lot.

This isn’t the most efficient coding, it being something created through research and experimentation with the mindset of ‘it works, don’t fix it’ and so, you may be able to improve on this. But this works for me so, feel free to give it a try.

You’ll see that this block of code resides inside a loop that iterates through each of the different fields available.

  • First, I’m outputing the name of the field as given in ‘field.label’. This is contained in its own
    element for style purposes.
  • Next is to get the string length of the current field value, using the ASSIGN command. This is stored in the variable ‘handle’.
  • The CASE block then checks the length and prepends the required number of zeros. This modified document number is stored in a new variable called ‘ref_out’ - it doesn’t actually change the document number stored in ‘field.text’. For example, I like a six digit number. In the event that the document number is 123 (3 digits long), three zeros are prepended (added to the start). So, ‘ref_out’ would now store ‘000123’.
  • The next step is to look at what the field label is, by examining ‘field.label’. If it is ‘Invoice number’ or ‘reference’ (the two occasions I’ve decided to use this format) then the ‘ref_out’ variable is used to display the output on the document. Otherwise, the standard ‘field.text’ output is used. This again is contained in a DIV element for style purposes.


{% for field in fields %}
  <div style="font-weight: bold">{{ field.label }}</div>

  {% assign handle = field.text | size %}
  {% case handle %}
    {% when 1 %}
      {% assign ref_out = field.text | prepend: "00000" %}
    {% when 2 %}
      {% assign ref_out = field.text | prepend: "0000" %}
    {% when 3 %}
      {% assign ref_out = field.text | prepend: "000" %}
    {% when 4 %}
      {% assign ref_out = field.text | prepend: "00" %}
    {% when 5 %}
      {% assign ref_out = field.text | prepend: "0" %}
    {% else %}
      {% assign ref_out = field.text %}
  {% endcase %}      

  <div style="margin-bottom: 10px">
    {% if field.label == "Invoice date" %}{{ field.text }}{% endif %}
    {% if field.label == "Issue date" %}{{ field.text }}{% endif %}
    {% if field.label == "Due date" %}{{ field.text }}{% endif %}
    {% if field.label == "Date" %}{{ field.text}}{% endif %}		
    {% if field.label == "Invoice number" %}{}{ ref_out }}{% endif %}
    {% if field.label == "Reference" %}{{ ref_out }}{% endif %}
    {% if field.label == "Quote number" %}{{ field.text }}{% endif %}
    {% if field.label == "From" %}{{ field.text }}{% endif %}
    {% if field.label == "To" %}{{ field.text }}{% endif %}	

{% endfor %}

Thanks a lot for the detailed response BGPS. I believe I followed most of your example, but still have a question or two.

I have taken a slightly different approach to the ‘prefix & padding’ problem, inspired by this post.

{% for field in fields %}                            
    {% if field.label != 'Invoice number' %}
        <div style="font-weight: bold">{{ field.label }}</div>
        <div style="margin-bottom: 10px">{{ field.text }}</div>
    {% endif %}
    {% if field.label == 'Invoice number' %}
        <div style="font-weight: bold">{{ field.label }}</div>
        <div>{% capture new_var %} 000000{{ field.text }}{% endcapture %} RD{{ new_var | slice: -6, 6 }}</div>                                                                 
    {% endif %}
{% endfor %} 

This example above will only operate on field.label = ‘Invoice number’. Just wondering if you can see any critical flaws with this solution, or any reason not to use it?

I haven’t made any allowance for field.label = ‘Reference’, when would this be needed? What is the ‘Reference’ number?

I am of the understanding that all of the adjustments to the invoice number, are only effective in editing the numbers on the forms themselves, they are in no way reflected back into the Manager environment. For example, in the ‘Sales Invoice’ list, the invoice numbers are the original numbers (without prefix & padding). Is this how you see it too?

Thanks again for your help.

Reference depends on the context. It could be a quote number, PO number, invoice number, etc. It will change from form to form.

That is correct. The code you have posted is for a custom theme, which displays data in conjunction with other things arranged around the data. It does not alter the data.

1 Like

Great, thanks Tut.