Receiving payments

Finance → Receivables → Payments → /payments · Receive Pay → /receive-pay

There are two surfaces for money coming in:

Receiving a payment at the counter

Receive Pay is built for someone taking money with a tenant in front of them.

1. Find the unit

   Search by unit name. The screen shows the outstanding items with their Due Amount.

2. Enter what was paid

   Paid Amount, Paid Date, Paid By, the Bank Account the money landed in, and any Notes.

3. Submit

   The payment is recorded against the unit's lease and becomes available for allocation.

Recording a payment from the Payments list

1. Add a payment

   Payments → Add.

2. Identify the payer

   Select the lease or unit. This determines whose balance the money lands on, so get it right — correcting the subject later is more work than choosing it now.

3. Enter the money

   Amount, paid date, payment type (mobile money, bank transfer, cheque, cash), and the receiving bank account.

4. Record the reference

   The Confirmation # — the M-Pesa code, bank reference or cheque number. This is what makes the payment reconcilable against a bank statement later. Do not leave it blank.

5. Save, then allocate

   Saving records the cash. It does not settle any invoice until it is allocated. See Allocations.

The payments list

Useful columns include:

On the Bank Statement view, money is split across Money In and Money Out — exactly one of the pair carries a figure on any row and the other is left blank, which is what makes it read like a statement.

Filter on Available Amount > 0 to find every payment still waiting to be allocated. That single filter is the fastest way to clean up a messy receivables position.

Holding a payment back from automatic allocation

Sometimes a payment should not be matched automatically — it is disputed, it is somebody else's, or it is waiting on a decision. Rather than switching automatic allocation off for the whole property, hold back the single payment.

Don't Auto-Allocate is available on the Suspense Account and Wallet Credits lists (tick the rows first) and on an individual payment's menu. You are asked for a note, because the person who finds the payment in three weeks is usually not the person who held it.

The payment record page

Every payment now has a page of its own at /payments/<uuid>, reachable by clicking the payment anywhere it is referenced. It is the surface to open when somebody disputes a payment, because it answers the whole question in one place instead of across five panels:

The older drawer is still what opens from a grid row; the page is where the drawer's open full page link takes you.

The code the payer actually holds

On a bank-relayed M-Pesa transfer — money that reaches you through a bank feed rather than straight from Safaricom — the Confirmation # is the bank's reference. The tenant has never seen it. What they have is the M-Pesa code on their own phone, and until recently that code existed nowhere on the record.

It is now captured as the M-Pesa Code, and it behaves as a real lookup key:

• On the grids it is a column on all three payment lists. It is hidden by default because the visible-column budget is spent, so switch it on from the column chooser, or filter on it without showing it.
• On the record it is printed only when it differs from the confirmation number. On a direct M-Pesa payment the two are the same string, and printing it twice would read as two facts.
• In the filter and in global search one box takes either code. Nobody handed a payment code knows which kind they were handed.

Refunds from a payment

Refunds are managed directly from the payment:

1. Open the payment and expand Refunds

   Existing refunds are listed with their amount, date and reason.

2. Add a refund

   Enter the refund amount, the bank account it is paid from, the refund date, and a reason.

3. Save

   Guards check that the amount is actually available and that a bank account is set before the refund can be recorded.

See Refunds for the full refunds ledger and its controls.

Bulk import of payments

Historical or bank-exported payments can be imported through Admin → Bulk Upload with the Payments type. The importer validates before committing and keeps a per-row outcome so you can see exactly what was created, skipped and rejected. See Bulk upload.

Reconciling to the bank

1. Filter by bank account and date range

   Work one account and one statement period at a time.

2. Match on confirmation number

   Not on amount. Amounts repeat; references do not.

3. Investigate anything unmatched

   Money in the bank with no payment record means a receipt was never captured. A payment record with no bank line means it was captured twice or against the wrong account.

4. Check the wallet position

   After matching, filter on available amount to confirm nothing is sitting unallocated.

Common problems

Next steps