/tps/allocation-reports
Payments collected against a Boma Yangu tenant purchase scheme have to be reported back to the Boma
Yangu API: the scheme’s own records need to know how each payment was split between principal,
interest and other components. That reporting is automatic — this console is where you confirm it
actually happened.
Only payments received into a Boma Yangu collection account generate an allocation report.
Payments on other accounts are ordinary TPS payments and never appear here.
How a report is produced
1
A payment lands on a Boma Yangu account
The pay-to account identifies it as in scope.
2
Allocation runs
The payment is allocated across the contract’s schedule — principal, interest, and any other
component. See Allocations.
3
A report is queued
The resulting split becomes an allocation report addressed to the Boma Yangu API.
4
The queue is drained
A background job submits queued reports and records the outcome against each one.
Reading a report’s status
Only acknowledged means the scheme’s records agree with yours. Sent without an acknowledgement
for an extended period is worth chasing — it usually points at the far side, not at Nyumba Zetu.
Working the queue
Filter by status and start from the failures.1
Read the failure reason on the report
Open the report to see what the API returned. Most failures are data, not transport — a contract
reference the scheme does not recognise, or an amount split it rejects.
2
Fix the cause, not the report
If the allocation itself was wrong, correct it in
Allocations first — retrying an incorrect report just re-sends the same
wrong figures.
3
Retry
Failed reports carry a Retry action. It resubmits the report as it stands.
4
Escalate dead reports
A dead report has exhausted its retries. Treat it as a data or integration problem, not a
transient one.
Boma Yangu deduplicates on its side, so re-sending a report that may already have landed is safe.
A retry cannot double-report a payment.
Shadow mode
The feature can run in shadow mode: reports are produced and recorded exactly as they would be, but nothing is submitted. This is how the integration is validated against real payments before it is switched on for an organisation. In shadow mode the console is still the right place to look — the reports and their computed splits are real, only the delivery is withheld.Common problems
Related
TPS overview
How ownership plans work end to end.
Contracts and billing
Schedules, instalments and generation.
Allocations
How a payment is split before it is reported.
Admin console
Platform-wide integration job queue.