Allocation templates

A template is a saved split. You make the distribution once, name it, and the next invoice that needs the same distribution costs one click instead of five rows of typing.

This is the part of split coding that pays for itself, because the splits that matter are the recurring ones: the landscaping contract, the pest control agreement, the shared insurance premium.

Before you start

  • A balanced split on a real invoice. A template is made from one, so work through splitting an invoice first. The split has to be balanced, every row has to name a property, and no row may be worth nothing — those are the three reasons Save as template… is unavailable, and the reason is printed under the button rather than hidden in a tooltip.
  • Your role. Admin, Controller Approver and AP Specialist can save, apply, edit and delete templates. A Viewer cannot.
  • A vendor on the invoice, if you want the template offered automatically later. The template is bound to whichever vendor the invoice names, and an invoice with no vendor produces a template nothing can offer.
  • Room under the cap. A workspace holds 200 templates. Settings → Split coding prints how many you have used.

When you finish part one you have a named template listed under Settings → Split coding. When you finish part two, the template is offered on that vendor's next invoice, and one click applies it.

1. Balance the split you want to keep

Open the invoice from the Inbox, split the line or the whole invoice, and get the chip above the grid to read Balanced. What the template saves is the grid in front of you, not the split the invoice had stored a moment ago — so the numbers you are looking at are the numbers that get kept.

The Split coding panel with one printed line selected. Three properties are suggested with their share of that line, and the grid below holds one row per property with its percentage and amount. A green Balanced chip shows the rows add up to the line.
One line of the GreenLeaf invoice, split by unit count across three buildings. The percentages run to four decimal places; the amounts are whole cents, and they add up to the line.

2. Press Save as template…

The button sits beside the basis buttons under the grid. It saves one split: the line you have open, or the whole invoice. Splits on the other lines of the same invoice are not part of it, and the dialog says so with a count.

The dialog also tells you two things worth reading before you type a name:

  • It is saved as fixed percentages, not amounts. The invoice you saved it from was $9,600.00; next month's is $9,742.15, and the template distributes whatever amount it is given. A template that should follow today's unit counts or square footage instead is a basis change afterwards, in Settings.
  • It will be bound to this invoice's vendor, and offered above the grid on that vendor's next invoice. When the invoice names no vendor the dialog says that too: the template is still saved, but nothing will offer it and you can only reach it from the Template list.

Rows for the same building are merged into one row carrying the sum, because a template is a per-property distribution. If those rows carried different GL codes, the merged row keeps the first one, so check the GL code on the template afterwards.

3. Name it, and save

Give it a name a colleague would recognize — "GreenLeaf monthly" beats "Template 3". Names are unique within a workspace, and a name already in use is refused by name rather than silently saved twice.

You should now see a confirmation naming the template and the vendor it was bound to, and the template appears in the list under Settings → Split coding with its shares, its properties and its basis on the row.

4. Apply it to the next invoice

Open the next invoice, choose the line or the whole invoice, and take either route:

  • The one-click offer. While that split is still empty, templates bound to the invoice's vendor are offered above the grid as buttons with their shares printed on them — "40% / 30% / 30%" — so you can tell which one it is before you press it. The two most-used are offered.
  • The Template button. It opens a search box over every switched-on template, and it searches the name, the bound vendor and every property named on the template. So "GreenLeaf" finds the landscaping split whatever it was called.

The weights are distributed across the amount on the server, the pennies land under the largest-remainder rule, and the split arrives balanced. A template that is switched off is not listed, and applying one is refused with "Turn it back on first."

5. Check the apply landed

You should be looking at a grid whose chip reads Balanced, carrying one row per property on the template. Prove it two ways:

  • In the workspace record. Open Audit Log and filter the action to Allocation Template Applied. The entry names the template, the line it was applied to, and the weights it computed. Six months later, "where did this 40 / 30 / 30 come from?" has a written answer.
  • On the template itself. Settings → Split coding shows how many times each template has been applied and when it was last used. The counters are bumped only after a split is written, so an apply that was refused is not counted — and templates nobody uses are visible and can be culled.

If the invoice had already been approved, the confirmation is an amber warning: the coding changed, so the invoice went back to review for a fresh approval.

Fixed templates and derived templates

This is the distinction that decides whether a template can go stale, and it carries one trap: splitting an invoice by unit count and saving it does not make a derived template. Every template saved from an invoice grid is fixed. To make it derive, open it in the edit dialog under Settings → Split coding and set its Basis to unit count or square footage. Until you do, it carries the percentages that month's unit counts happened to produce.

A fixed template carries the weights you saved. A 40 / 30 / 30 agreed by the owners is 40 / 30 / 30 in March and in November. Nothing behind it can change, so it cannot drift.

A derived template — one whose basis is unit count or square footage — is recomputed from your property records every time it is applied, and the weight box in the dialog is read-only because the figure comes from the property. It has to work that way: a portfolio that gained forty units since March has a different correct answer now, and applying March's percentages would charge the wrong buildings for eight months before anyone noticed.

A derived template refuses rather than approximates. If a property on it has lost its unit count or its square footage, the apply is refused and the message names the building. A missing figure is never read as zero. A property deleted from the workspace is a different case: its row is deleted with it, and the template then spreads the whole amount across the buildings that remain — so check a template after you retire a property.

When the numbers have moved: the drift notice

Applying a derived template recomputes it and then tells you what changed, property by property: the figure the template was saved with, and the figure today.

Take a template saved across three buildings with 48, 40 and 30 units — 118 in total. Elm Terrace then converts four storage units into apartments and its record reads 44, so the next apply recomputes across 122 units:

PropertyUnits when savedUnits todayShare of $9,600.00 today
Maple Court4848$3,777.05
Elm Terrace4044$3,462.29
Oak Ridge3030$2,360.66
Total118122$9,600.00

Both splits total exactly $9,600.00. What changed is who pays: $128.03 moves off Maple Court and $80.02 off Oak Ridge onto Elm Terrace, which is correct, because Elm Terrace now has four more doors being served.

The recomputed split is applied straight away and the notice tells you what moved. You then choose what to do about it, and there are only three honest answers:

  • Accept the recomputed split. The usual answer, and the reason the basis was recorded.
  • Save the new figures over the template, so the notice stops appearing until the counts move again.
  • Edit the split by hand before saving the invoice, if this one month is genuinely an exception.

What the product will not do is apply the old percentages while telling you they are current. Stale percentages are the standing failure mode of recurring splits, and the only honest way to handle it is to recompute and say so.

Managing templates

Everything below is on Settings → Split coding.

Switching one off. There is an on/off switch on the template row, and the same switch inside the edit dialog. Off keeps the template and its rows, hides it from the picker and refuses an apply — the right state for a seasonal split, like snow clearing in July, that you do not want to delete. Switch it back on and it is offered again.

Editing one. The edit dialog holds the name, the vendor binding, the basis, a default GL code and the rows. Saving it replaces the template outright: the rows are deleted and written again from what the dialog holds, so a row you removed in the dialog is gone, and there is no way to patch a single field.

One thing to expect in that dialog. It checks that a fixed-percentage template's typed weights total 100.0000%, and a template saved from an invoice grid carries the cents of that invoice as its weights instead. Those weights are relative and apply correctly — the Share column beside each row shows the percentage the split will actually use — but the dialog will not save until you retype them as percentages totaling 100.0000%. The on/off switch does not go through that check, so switching a template off and on again is unaffected.

Editing changes future applies only. Invoices already split keep the allocations they were saved with, because those allocations are the coding of a document that may already be approved or posted. Deleting a template works the same way: the splits it produced stay exactly as they are, and it stops being offered.

Binding a vendor changes how the template is found and offered, never what was posted. You can change or clear it at any time.

Limits

A workspace holds up to 200 templates, and the New template button goes dead at the cap with the count printed beside it. A template needs a name, at least one property, and a weight above zero on every row — a property with no share would take nothing on every future invoice, so it is refused rather than dropped.

Practically nobody reaches 200. A portfolio needs one template per recurring distribution, and at a hundred and fifty it is worth asking whether some of them are the same distribution under different names, because a template list nobody can search is a template list nobody uses.

The cap sits alongside the other split limits: 150 allocations on one line, 200 on one invoice. All three are the same on every plan, including Free.

Where to go next