---
title: Allocation templates
description: Save a split once and apply it every month — vendor binding, fixed versus derived templates, what happens when unit counts move after a template was saved, and the 200-template cap
section: Tutorials
order: 17
---

# Allocation templates

A template is a saved split. You make the distribution once, name it, and every future invoice that needs the same distribution is one keystroke rather than 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. Read [splitting an invoice](/docs/splitting-invoices) first if you have not yet made a split by hand.

## Saving a template

Balance a split, then save it from the invoice. You are asked for three things:

| Field  | What it does                                                                                                      |
| ------ | ----------------------------------------------------------------------------------------------------------------- |
| Name   | What you will search for later. "GreenLeaf monthly" beats "Template 3".                                           |
| Vendor | Optional. Binds the template to one vendor so it is offered on that vendor's invoices.                            |
| Basis  | Optional. Whether the weights are fixed as saved, or recomputed from unit counts or square footage on each apply. |

The template stores a weight per property, not the dollars. 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.

Two details of the save are worth knowing, because they are decisions the product makes for you:

- **Rows for the same property are merged.** A template is a per-property distribution, so two rows for Elm Terrace with different GL codes become one row for Elm Terrace holding the sum.
- **Conflicting GL codes are dropped rather than picked.** When the merged rows disagree about the account, the template carries no GL code and your normal [coding rules](/docs/rules-reference) fill it in on apply. Choosing one of the two silently is how a template starts quietly mis-coding half of a split.

## Applying a template

Open an invoice, choose the line (or the whole document), and apply. The template's weights are distributed across the amount, the pennies land under the [largest-remainder rule](/docs/allocation-rounding), and the split arrives balanced.

Where the template is bound to a vendor, it is offered on that vendor's invoices rather than waiting to be searched for. `⌘`+`K` finds any template by name.

Applying is recorded in the [audit trail](/docs/audit-trail) as `allocation.template_applied`, with the template and the weights it computed. Six months later, "where did this 40/30/30 come from" has a written answer.

## Fixed templates and derived templates

This is the distinction that decides whether a template can go stale.

**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 saved with a basis of unit count or square footage — carries the figures as they stood on the day you saved it, and is **recomputed from your property records every time it is applied.** It has to be. A portfolio that gained forty units since March has a different correct answer now, and applying the March percentages would charge the wrong buildings for eight months before anyone noticed.

## 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:

| Property    | Units when saved | Share of $9,600.00 |
| ----------- | ---------------- | ------------------ |
| Maple Court | 48               | $3,905.08          |
| Elm Terrace | 40               | $3,254.24          |
| Oak Ridge   | 30               | $2,440.68          |
| **Total**   | **118**          | **$9,600.00**      |

Elm Terrace converts four storage units into apartments and its record now reads 44. The next apply recomputes across 122 units and shows the change:

| Property    | Saved | Today   | Share of $9,600.00 |
| ----------- | ----- | ------- | ------------------ |
| Maple Court | 48    | 48      | $3,777.05          |
| Elm Terrace | 40    | **44**  | $3,462.29          |
| Oak Ridge   | 30    | 30      | $2,360.66          |
| **Total**   | 118   | **122** | **$9,600.00**      |

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

You then have three honest options, and no fourth:

- **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 way to handle it honestly is to recompute and say so.

A derived template also refuses rather than approximates. If a property on the template has lost its square footage — or is no longer in the workspace at all — the apply is refused and the message names the property. A missing figure is never read as zero.

## Managing templates

| Field   | What it is for                                                                                |
| ------- | --------------------------------------------------------------------------------------------- |
| Enabled | Turn a template off without deleting it. A disabled template stops being offered.             |
| Vendor  | Change or clear the binding at any time; it affects what is offered, never what was posted.   |
| Used    | A use count and a last-used date, so the templates nobody uses are visible and can be culled. |

Editing a template 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 — rewriting them from a template edited afterwards would rewrite history.

Deleting a template works the same way. The splits it produced stay exactly as they are.

## The 200-template cap

A workspace holds up to **200** templates.

Practically nobody reaches this. A portfolio needs one template per recurring distribution, and if you find yourself 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. See [plans and limits](/docs/plans-and-limits).

## Where to go next

- [Splitting an invoice](/docs/splitting-invoices) — the split a template is made from.
- [Allocation rounding](/docs/allocation-rounding) — why an applied template always totals exactly.
- [Rules reference](/docs/rules-reference) — the other half of "stop making the same decision twice".
- [Audit trail](/docs/audit-trail) — what an apply records.