M-Pesa limits and large invoices
The M-Pesa limits that affect a Kenyan business collecting large invoices, and how to handle split payments, short references and bank transfer.
By Achekam · · 4 min read · For Running a business businesses in Kenya
A building contractor finishes a job and sends the client a substantial invoice. The client, used to paying everything by M-Pesa, tries to settle it from his phone and the payment fails. He tries a smaller amount, then another, and by the end of the week the invoice has a trail of part payments that nobody planned.
M-Pesa is built for everyday amounts, and its limits are generous for most retail sales. For larger invoices they shape how the customer can pay. A business that knows them can tell customers in advance how to settle a big bill, instead of sorting out the pieces afterwards.
Per-transaction, balance and daily limits
Safaricom's M-PESA Express documentation states a limit of Ksh 250,000 per transaction for a registered customer, a maximum account balance and daily transaction value of Ksh 500,000, and a minimum transaction of Ksh 1. Its B2C documentation gives the same Ksh 250,000 per-transaction ceiling and Ksh 500,000 balance and daily figures for payments to customers.
These are Safaricom's figures at the time of writing; check its pages before you print them on an invoice. In practice they mean three things for a large invoice:
- An invoice above the per-transaction limit cannot be paid in one M-Pesa payment.
- An invoice above the daily value cannot be paid in a single day from one customer's account.
- A customer whose balance ceiling is lower than the invoice has to fund and pay in stages.
Account reference length
The account reference matters as much as the amount. Safaricom says the AccountReference field in an M-PESA Express request is limited to 12 characters, and the transaction description to 13.
That is a reason to keep invoice numbers short and simple. A long reference with a year, a branch code and a sequence number risks being cut, and a reference customers have to type into a paybill payment is more likely to be mistyped the longer it gets. In Achekam, a paybill or till payment that quotes an open shilling invoice number as the account number is receipted automatically, while any other payment waits in a list for a person to allocate. Short, unambiguous invoice numbers mean more payments land on the right invoice without help.
Splitting a large payment
Where the customer prefers M-Pesa for a large bill, agree the split up front:
- Agree how many payments there will be and roughly when.
- Ask the customer to quote the same invoice number on every payment.
- Send a statement after each payment showing what is still due.
- Confirm the final payment and send a receipt for the whole invoice.
Sometimes the better answer is to change the invoice rather than the payment. Where the work allows it, invoice a large job in stages: a deposit when the order is placed, then an invoice at each agreed milestone. Each invoice is then a size the customer can settle in one payment, each has its own number to quote, and the business is paid as the work progresses instead of waiting for one large sum at the end. Agree the stages in the quotation so that nobody is surprised.
If you send payment prompts to the customer's phone, two details apply. Achekam's M-Pesa prompts request whole shillings only, so cents stay due on the invoice. And the same phone can be prompted only once a minute, so successive prompts for instalments need a short pause between them. When an STK push fails covers prompts that do not complete.
Part payments against one invoice in Achekam
Achekam records customer payments against one invoice or spread across a customer's invoices. A part payment leaves the invoice part-paid, and any extra is held on the customer's account.
When a payment comes through a gateway and is verified, it is recorded as a receipt against the invoice: the gateway's clearing account is debited, trade receivables are credited, and the invoice shows as paid or part-paid. The amount is checked against what the payment link asked for, and a repeated notification never pays twice. So a large invoice settled in several M-Pesa payments shows each instalment as it arrives, with the balance still due visible to everyone who opens the invoice, and the receipts already posted to the books.
Offering bank transfer instead
For the largest invoices, a bank transfer is usually simpler for both sides. In Achekam the pay page can show the business's bank details and a payment reference, and a staff member marks the payment received once it shows on the bank statement. Each bank account takes one currency, so show a shilling account for shilling invoices.
A workable house rule is M-Pesa for invoices below the per-transaction limit, bank transfer or RTGS above it, with M-Pesa instalments only by agreement. RTGS, cheques and other ways to pay explains the bank options.
Customer instructions on the invoice
Put the instructions where the customer will read them, on the invoice itself. A simple form of words:
How to pay. By M-PESA: paybill [number], account [invoice number]. Amounts above M-PESA's per-transaction limit can be paid in several payments, each quoting the same invoice number, or by bank transfer. By bank: [bank, account name, account number], reference [invoice number].
Then reconcile as usual: every instalment against its invoice, and every M-Pesa receipt traced through to the bank, as described in reconciling M-Pesa takings.
Safaricom's M-PESA Express documentation sets out how payment prompts work, the request fields and their limits, error codes and the steps to go live with a paybill or till.
General guidance only, not advice on your own circumstances. Tax and payroll rules change: check the current position with the authority or your adviser.
