Skip to main content
Admin → Payment Rules → /payment-rules · Allocation rules → /payment-allocation-rules Payment rules do two jobs:
  1. Matching — turn a bank or mobile-money reference into the right lease.
  2. Allocation order — decide which outstanding invoice a payment settles first.
Both are what let money arrive and be applied without a person reading each reference.

​
Matching rules

​
How matching works in practice

A tenant paying by mobile money types an account reference. If they type it exactly as instructed, matching is trivial. In reality they type it with spaces, with the unit name instead of the lease code, or with a previous tenant’s reference. Matching rules absorb that variation:
  • Replace value normalises the reference — stripping separators, correcting a known prefix.
  • Priority decides which rule wins when more than one could match.
  • Scope limits a rule to a bank account, branch, block, unit or lease, so a fix for one estate does not misroute another’s payments.
1

Publish one reference format and use it everywhere

On invoices, in reminders, on the notice board. Most unmatched payments are payers using a format nobody told them.
2

Watch what actually arrives

Review unmatched receipts weekly for a month after go-live. The patterns repeat.
3

Write narrow rules first

A broad rule with high priority can capture payments it should not.
4

Date-bound corrective rules

A rule fixing a legacy reference format should have an end date, not live forever.
A wrong matching rule attributes money to the wrong tenant. That produces an arrears case against someone who paid, and a credit for someone who did not. Test a new rule against known references before enabling it.

​
Allocation rules

Allocation rules decide the order in which a matched payment settles outstanding items — the default allocation behaviour, plus rules scoped by service type or context. Typical orderings: Rules can be scoped by service type, bank account and the position in the hierarchy, so a scheme with different priorities does not force a change everywhere.
Allocation rules drive the allocation engine, which is preview-first: you can see what a rule set would do before it does it, and revert a run that did the wrong thing.

​
Testing a rule change

1

Run an allocation preview

Not an execute. Read what would be allocated and what would be skipped.
2

Check a handful of leases by hand

Especially ones with mixed debt — rent, utilities and a penalty.
3

Execute, then check the run log

Allocated, skipped and error counts, with reasons.
4

Revert if it is wrong

Reversal is a first-class operation. Use it rather than unpicking allocations by hand.

​
Common problems

​
Next steps

Allocations

The engine these rules drive.

Bank accounts

Paybills and reference separators.