Loading

Setting Up a Numbering Scheme

A scheme binds a format to a specific field on a specific datastore, and owns the counter that fills it.

Where to find it

Architect Panel → Data:

  • Record Numbering — the console — create schemes and inspect counters
  • Datastores — the datastore and field the scheme writes to

What a scheme holds

  • Datastore and field — where the number is written.
  • Scheme key — a short identifier, so several schemes can target the same field for different record types.
  • Entity — which legal company this counter belongs to.
  • Prefix, format and padding.
  • Period key and period value — how and when the sequence rolls over.
  • Next value — the counter itself.

The counter is a row, not a field

This is the design point worth understanding. A separate counter row exists per entity and per period. A yearly scheme with two companies has two counter rows this year and two more next year.

The consequence is that periodic resets need no scheduled job and no year-end task. When the period changes, allocation simply lands on a different counter row, which starts at one. Nothing has to run at midnight on 1 January, and nothing can fail to run.

It also means the entities are genuinely independent. One company's invoice volume cannot advance another's sequence, which is what statutory numbering usually requires.

Choosing a period key

  • Yearly — the common choice, and what most finance teams expect on documents.
  • Monthly — for high volume, where a year's sequence would grow unwieldy.
  • None — one continuous series for the life of the system.

Pick once, at setup. Changing the period key later restarts the sequence, so references issued afterwards can collide with historical ones unless the format also changed.

Setting up

  1. Create the scheme against the datastore and field.
  2. Set the prefix, format and padding.
  3. Choose the period key.
  4. Create the scheme for each entity that needs its own series.
  5. Create one record and check the reference reads as you intended.

Test with a throwaway record

Create one, look at the reference, then delete it. The gap it leaves is harmless, and it is far cheaper than discovering the format is wrong on the invoice a customer has already received.

Do not edit the next value casually

Moving the counter forwards is occasionally legitimate — continuing a series from a previous system, for instance. Moving it backwards means reissuing references that already exist, and the resulting duplicates are hard to unpick because both records look correct in isolation.

Worked example

A group with two trading companies sets up sales invoice numbering as {PREFIX}-{ENTITY}-{PERIOD}-{SEQ}, prefix INV, padding 5, period key yearly, with one scheme per entity. The first invoice of 2026 in the UK company is INV-GB-2026-00001; the Irish company's first is INV-IE-2026-00001 the same week. Neither affects the other, and 2027 starts again with no intervention.

Recommendations

  • Decide the period key before go-live and leave it alone afterwards.
  • One scheme per entity where entities are separate legal companies.
  • Test with a throwaway record.
  • Only ever move the counter forwards, and note why when you do.