MassiveGL Posting Templates
Every ledger has a set of transactions it posts over and over. The accounts change, the amounts change, sometimes the counterparty changes—but the structure is always the same. A fee charge is always a debit to the customer account and a credit to fee income. A settlement is always the same four entries. A foreign exchange conversion follows the same arithmetic every time.
Freeform posting can handle all of these, but it puts the entire burden of correctness on the operator: right accounts, right sides, right layer, right formula—every time, by hand. Templates solve this. A template captures the invariant structure of a transaction and exposes only the parts that actually vary. Everything else is handled by the ledger.
What a template is
A template is a versioned posting pattern. It defines:
- Posting lines—the entries that make up the transaction, with accounts, sides, and layers
- Parameters—the variable inputs an operator or system provides at posting time
- Derived values—computed from parameters using an expression language
- Validations—rules that must pass before the transaction is accepted
When a template is used, the operator provides only the parameters. The rest is pre-wired. The ledger produces a balanced, validated transaction with a permanent link back to the template ID and version that created it.
Parameterizing accounts
The most visible use of parameters is amounts—but accounts can be parameterized too, and this is where templates become genuinely powerful.
A bill payment template might have a fixed debit to the customer's clearing account and a credit to whichever payee account the operator specifies. An accounts receivable payment template fixes the credit side to AR income and takes the debtor account as a parameter—so the same template handles every customer. A funds transfer template takes both the source and destination accounts as parameters, turning a two-sided entry into a single form with two lookup fields.
This means you can define one template for an entire class of transactions rather than one per account or counterparty. The structure is guaranteed; only the addressable parts are exposed.
The expression language
Amount modes give you four options for each posting line:
| Mode | What it does |
|---|---|
| Fixed | A constant hardcoded into the template |
| Parameter | A named value the operator provides |
| Formula | An expression derived from parameters, balances, or other values |
| Balance | The current balance of an account—for closing or sweep entries |
Formulas unlock the most interesting cases. A fee template can compute the charge automatically:
fee = round(amount * fee_rate, 2)
One posting line debits the customer account for amount + fee, another credits the service account for amount, and a third credits the fee income account for fee. The operator enters one number; the template derives the rest.
Foreign exchange works the same way. An FX conversion template takes the source amount and a rate parameter:
target_amount = round(source_amount * fx_rate, 2)
Debit the foreign currency account for source_amount, credit the local currency account for target_amount. No manual arithmetic, no rounding errors, no mismatched entries.
A revolving credit interest template can compute the monthly charge from the outstanding balance:
interest = round(outstanding * monthly_rate, 2)
Run this as a batch job at end of month across every eligible account—same template, different parameter values, thousands of balanced transactions generated without operator involvement.
Versioning and audit
Every edit to a template creates a new version. The original is never modified. Every posted transaction stores the template ID and the exact version number that produced it—FEE_CHARGE:3, FX_CONVERSION:1, REVOLVING_INTEREST:2.
If a fee rate changes, you update the template. Transactions before the change are still accurately described by the version that created them. There is no ambiguity about what formula produced a given entry, even years later.
Where templates fit in operations
Templates cover a wide range of use cases across the transaction lifecycle:
Operator-driven transactions—emergency card funding, manual adjustments, dispute credits, goodwill reversals. An operator opens the template palette (⌘K), selects the template by name, enters the variable parts, and posts. Accounts are pre-wired, amounts are validated, and the result is auditable.
Back-office workflows—fee collection, interest accrual, foreign exchange settlement, interbank reconciliation. These follow fixed patterns with computed amounts. Templates make them fast and consistent.
Batch and scheduled jobs—end-of-month interest posting, revolving credit charges, account maintenance fees, dormancy charges. A job iterates over eligible accounts, calls the template with the appropriate parameters for each, and posts. The template enforces structure; the job provides the data.
Integration points—payment processors, card networks, and external systems often need to trigger specific ledger entries. Templates give these integrations a stable, versioned contract. The external system provides parameters; the ledger handles the accounting.
Templates and dynamic rules together
Templates prevent structural errors at entry time—wrong accounts, unbalanced entries, missing fields. Dynamic rules prevent business logic violations at commit time—balance limits, date restrictions, amount caps.
They are complementary. A template guarantees the form of a transaction; a dynamic rule guarantees the outcome satisfies your business constraints. Together they give you both automation and control.