Cargolake
Help & Guides/Finance

Posting rules

How business events become journal entries automatically — sources, conditions, lines and account resolution.

A posting rule turns a business event into a journal entry. When an invoice is issued or a cheque bounces, the rules decide which accounts are debited and credited and for how much.

This is the piece of configuration that makes the ledger self-maintaining. It is also the piece where a mistake is replicated across every transaction until someone notices, so it repays care.

What a rule holds

FieldNotes
SourceWhich event it responds to.
Scope kindGlobal or Tariff.
Scope IDWhich tariff, when scoped to one.
DescriptionWhat the rule does.
Valid from / Valid toThe period it applies.
ActiveWhether it is in force.
ConditionsWhich events it matches.
LinesThe debits and credits it produces.

Sources

SourceEvent
InvoiceA customer invoice.
Vendor invoiceA supplier invoice.
PaymentA payment.
ChequeA cheque event.
Custody payment — processCustody cash advanced.
Custody payment — submitCustody submitted.

Custody appears twice because advancing the cash and submitting the reconciled spend are different accounting events. See Custody payment requests.

Scope

Start global and add tariff-scoped rules only where a specific charge genuinely posts differently. A forest of narrow rules is far harder to reason about than a few broad ones.

Conditions

Conditions decide whether a rule matches an event:

PartMeaning
Attribute keyWhich field on the event to look at.
OperatorEQ NE IN NIN GT GTE LT LTE LIKE EXISTS
ValueWhat to compare against.
QuantifierANY, ALL or NONE — for attributes holding several values.

The field schema screen documents which attributes are available per source. Consult it rather than guessing: a condition on a key that does not exist never matches, and the rule simply never fires — silently.

Lines

Each line produces one journal line:

FieldNotes
Line numberOrder within the entry.
Dr/CrDebit or credit.
GL accountThe account, when fixed.
Custom functionHow to derive the account, when it is not fixed.
Amount sourceWhere the amount comes from.
Dimensions from contextWhich analysis attributes to carry through from the event.

Amount sources

SourceAmount
Line netThe net value.
Line VATThe tax.
Line grossNet plus tax.
FixedA constant.
Percent of netA percentage of net.
Percent of grossA percentage of gross.

A typical invoice rule debits receivables with line gross, credits revenue with line net, and credits the tax account with line VAT. Those three together balance; any two of them do not.

Resolving the account dynamically

Rather than naming a fixed account, a line can resolve one from the event:

FunctionResolves to
Extract from bank accountThe GL account linked to the bank account.
Extract from clientThe customer's account.
Extract from vendorThe vendor's account.
Extract from treasury accountThe treasury location's account.
GL accountA directly specified account.

This is what keeps the rule set small. One payment rule serves every bank, because the account comes from whichever bank was used — see The chart of accounts for how those links are set.

Validity dates

Valid from and valid to let a rule change on a date without deleting the old one. When a VAT rate or an account mapping changes, close the old rule with a valid to and create the successor from the following day.

Never edit a rule that has already posted. Historic entries were produced by what the rule said at the time, and editing it destroys the ability to explain them.

Testing a new rule

  1. Check the field schema for the attribute keys you are using.
  2. Confirm the lines balance for a representative event.
  3. Set validity from a future date, then post a test transaction and inspect the resulting journal lines — each shows the rule that produced it.
  4. Check dimensions carried through, or your analysis will have a hole exactly where the new rule fires.

When an expected journal does not appear

Work down this list:

  1. Is the rule active?
  2. Is the event date within valid from / valid to?
  3. Does the source match the event?
  4. Do the conditions match — particularly attribute keys and quantifiers?
  5. Is the scope narrower than you think — a tariff rule where a global one was intended?
  6. If the rule fired but the entry is wrong, look at the amount source first. It is the commonest error, and net-versus-gross is the commonest form of it.

Last updated 15 September 2026