How Pangoni reconciles M-Pesa and bank payments
From a slightly wrong payment reference to a clean tenant ledger: see which signals Pangoni uses, when it asks you to review a match, and how managed reconciliation handles the rest.
Pangoni reconciles payments by comparing each incoming credit with active tenancies using the payment reference, phone number, payer name, amount, timing, prior payment history and property scope. High-confidence matches post automatically. Uncertain matches are held with ranked suggestions and a plain-English reason, so nothing is silently guessed.
What payment reconciliation means in Pangoni
Reconciliation answers four questions for every credit: which tenant, which unit, which invoice and which period?
Rent rarely arrives in perfectly labelled rows. A tenant may pay from a relative's phone, type the wrong account number, combine rent and service charge, or send a bank transfer whose narration only says “RENT”. Pangoni turns those credits into traceable ledger entries without treating a plausible guess as a fact.
Every allocation is either supported by a high-confidence match or explicitly confirmed by a person. If the evidence is weak or contradictory, the payment stays held in the reconciliation queue.
Where Pangoni receives payments from
All supported payment sources enter the same reconciliation workflow and end in the same tenant ledger.
M-Pesa Paybill or Till
A C2B callback arrives moments after the tenant pays.
M-Pesa STK Push
Already tied to the tenant and invoice that started the request.
Connected bank feed
Credits from a supported connected account enter automatically.
Uploaded statements
M-Pesa or bank statement files are processed when uploaded.
Why STK Push is different: the payment request begins inside Pangoni against a known tenant and invoice. That known relationship means it does not need to be identified after the fact.
How Pangoni identifies the right tenant and invoice
Each incoming credit is compared with active tenancies. Independent signals are combined into one confidence score out of 100. The strongest evidence is a valid account or bill reference; amount and timing add context but do not override contradictory identity evidence.
KES 27,000
Ref: GREEN-B4
0722 000 000
03 Aug, 08:41
Posted oldest open invoice first, with any remainder retained as account credit.
Illustrative example. The score shown demonstrates the decision flow; individual scores depend on the evidence available for that transaction.
Unit codes, billing codes and house numbers, with tolerance for spaces, separators and case.
Normalised across Kenyan formats and checked against primary and saved alternate payer numbers.
Compared with tenant names while allowing for abbreviations and reordered Kenyan names.
Compared with rent, open balances and clean multiples of recurring charges.
Checks the due date, usual payment day and whether this payer has settled the unit before.
A payment received into a property-specific account is only compared with that property's tenancies.
What Pangoni does with bank statement narrations
Bank credits often carry less structure than M-Pesa. Pangoni parses EFT, RTGS, PesaLink and mobile-to-bank narrations for a sender and reference; recognises recurring standing orders after they are confirmed; and separates charges, interest, reversals and internal transfers from rental credits so they do not clutter the tenant-matching queue.
What happens at each confidence level
Pangoni uses four default confidence bands. The score controls whether a payment posts or waits for review; it does not hide the evidence behind the decision.
For example: “Reference matched Unit B4, but the amount is KES 3,000 short of the balance.” That tells the reviewer what agrees, what does not, and what to check next.
What you can do in the reconciliation queue
Held credits sit in one queue with filters for property, source, confidence, amount and age. Reviewers can resolve one payment or clear a band in bulk when the supporting reasons are consistent.
Confirm or reassign
Accept the suggested tenant, or search by tenant, unit, phone or reference and choose another.
Split the payment
Allocate across invoices, charge types or several units while retaining one parent transaction.
Part-allocate or hold
Post the known portion, retain a credit, or flag the payment with a note for a colleague.
Classify or reverse
Mark non-rental credits correctly, or reverse an allocation with a new audit entry instead of deleting history.
Pangoni learns from confirmed relationships. When a third-party phone number or recurring bank source is confirmed for a tenancy, that relationship can support a stronger match the next time it pays the same unit.
How common payment situations are handled
| Situation | Pangoni's handling |
|---|---|
| Tenant pays from a friend's or employer's phone | Uses reference, amount and timing; after confirmation, the number can be saved as an alternate payer. |
| Tenant overpays | Settles the invoice and retains the remainder as account credit for a future charge. |
| Tenant underpays | Part-allocates the payment; the invoice remains open for the balance. |
| Lump sum covers several months | Applies the allocation waterfall, starting with the oldest open arrears. |
| One transfer covers several units | Splits into linked allocations that trace back to the original credit. |
| Duplicate or reversed M-Pesa transaction | Checks the transaction reference to prevent double posting; reversals create traceable reversing entries. |
| Cash is paid at the office | Records it manually in the same ledger and reporting flow. |
Managed reconciliation: send statements, receive a clean ledger
Managed Reconciliation is for teams that do not want to work the queue themselves, lack a connected feed, or need to clean up historical statements before moving onto Pangoni. For the commercial overview and quote process, see the Managed Reconciliation service page.
- Send the statements. Upload official M-Pesa or bank statements in an agreed file format.
- Approve the scope and quote. Pangoni confirms the period, properties and transaction count before work starts.
- We reconcile and resolve exceptions. The matching engine processes the batch and the team reviews held items.
- Review the reconciliation pack. You receive allocated ledgers, a summary, exceptions and questions only you can answer.
- Approve posting. The reviewed results are posted to the live ledgers after sign-off.
Managed reconciliation pricing
Pricing is based on transaction volume per batch, not the number of units or the value collected. All prices below are exclusive of VAT.
| Transactions per batch | Rate | Example total |
|---|---|---|
| Up to 250 | KES 4,500 flat | KES 4,500 |
| 251–1,000 | KES 15 / transaction | 1,000 → KES 15,000 |
| 1,001–5,000 | KES 11 / transaction | 5,000 → KES 55,000 |
| More than 5,000 | From KES 8 / transaction | Custom quote |
Minimum and backlog rates
Every current-period batch is charged at the greater of its volume rate or the KES 4,500 minimum. Historical backlog transactions are KES 22 each because older tenant rosters, rent changes and references usually need more investigation.
Turnaround
Standard: 5 business days
Priority: 2 days, +40%
Same/next day: capacity permitting, +75%
Onboarding reconciliation credits
Credits are transaction-based and intended to remove the backlog barrier when a portfolio moves onto Pangoni. They are not a recurring monthly bookkeeping allowance.
| Plan | Onboarding credit | Standard-rate discount after credit |
|---|---|---|
| Starter | — | — |
| Growth | 500 transactions, valid 90 days | 15% |
| Enterprise | 10 backlog transactions per contracted unit, maximum 5,000, valid 90 days | 25% |
Credits cover reconciliation for up to 24 months of history. Reconstructing a missing historical tenancy roster is separate work and is scoped before reconciliation begins.
What remains traceable after a payment is posted
The ledger records what happened without erasing the path that led there.
Records whether the engine, an account user or Pangoni staff made the allocation.
A correction writes a reversing entry while the original remains visible.
Organisations can restrict who confirms, reassigns, reverses or classifies payments.
Frequently asked questions
Any automated system can produce an incorrect match, which is why Pangoni reserves automatic posting for the 95–100 band and keeps the decision traceable. If an allocation is wrong, reverse and reassign it; both entries stay visible.
Payments below the 95-point auto-match threshold are held. Scores of 75–94 show one strong candidate, scores of 40–74 show ranked suggestions, and lower scores remain unmatched until a user assigns or classifies them.
Confirm the payment against the correct tenancy. A confirmed payer relationship can help future payments from the same source match more confidently even when the reference remains poor.
No. You can upload supported bank statements for reconciliation. Connected feeds remove the upload step; availability depends on the bank and account setup.
Yes. Split the payment across invoices or charge types, or apply the organisation's allocation waterfall. Each allocation remains linked to the same source transaction.
Reconciled data can move through Pangoni's accounting integrations. See the integrations directory for current availability.
The service can work from available statements, but onboarding credits cover up to 24 months of history. Older or incomplete records are scoped separately because missing rosters and historical rent changes increase ambiguity.
Start with live payments or clean up the backlog first.
Use Pangoni's automatic reconciliation going forward, or ask for a managed reconciliation quote for existing M-Pesa and bank statements.