This is a guest post written by Ignacio Mas, a consultant on mobile money and technology-enabled models for financial inclusion.

In a recent study of business uses of M-PESA in Kenya funded by the Financial Sector Deepening Trust of Kenya, my former colleague Amolo Ng’weno and I found remarkably low use of M-PESA among formal Kenyan businesses. We collected a catalogue of reasons why, some having to do with entrenched business practices and some relating to limitations of the M-PESA service itself.

So what would a business-friendly mobile money service look like? I’d suggest the following key elements based on the pain points we kept hearing about from business people in Kenya.

Pain point #1: The money went to the wrong account. A customer might mis-type the destination phone number, or biller code when paying the electricity bill. The customer is unhappy: she thinks she paid but her electricity got cut-off, and she is placing irate calls to your staff. Or a customer might pay for goods at your store correctly, and subsequently claim to have made the payment in error. At the very least, your money will be frozen for a while pending some more or less diligent procedure by the mobile payment provider’s call center people; at worst, the payment will be reverted, and you will have been defrauded.

Solution: Checksum digits. Business users should have the option of getting unique biller codes or account numbers which are different from phone numbers, and these should incorporate checksum digits that allow immediate spotting of data entry errors. (Checksum digits must match mathematically the rest of the digits in the account number or biller code, and a mis-typed digit causes the checksum to not match and hence the transaction is immediately identifiable as not valid.) This solution should not be forced on individual users, for whom using their mobile number as the account number vastly simplifies operation of the service. But for business users, why should the corporate payment number be their phone number?

Pain point #2: What’s this payment for? This is a bit the opposite case: a payment went through to a business, but the business can’t figure out who it came from (the phone number does not appear to belong to any of the customers on its database) or what it is for (which of the open invoices from a given customer this payment is intended for).

Solution: Optional reference field. All money transfers should provide an optional field for references, so that senders can put in a customer number (when the money is not sent from their registered phone), an invoice number, or a description for the payment. This is generally done for bill payments, but why wouldn’t this be possible for any business (and some personal) transactions, too?

Solution for extra credit: Enable syntax checks on the reference field. Business customers might be given the possibility of specifying the required syntax on the payment reference field, such that if a paying customer does not enter enough information or it is not of the right nature, the transaction is immediately rejected (“invalid transaction reference, please enter it as [sample syntax]”).

Pain point #3: Customers insist on having a receipt. Customers like having a receipt in their hands, otherwise they fear being powerless in the event of a dispute, or they might need it to show it to their boss, their spouse or whoever. Without access to a receipt, many will keep paying at the company’s window.

Solution: Web-based receipts. Let customers have their receipts, but not necessarily at the point of transacting. The SMS receipt for the transaction contains a unique transaction ID. That, plus the customer’s phone number, might be credentials that can be typed into a dedicated receipts website which then displays the receipt in question. Let people find a cybercafe and print their receipts, if they so want them.

Pain point #4: I want to see all my transactions together. Regardless of how payments are received or made, enterprises want to have a single view of their business. They will not be happy to look up transactions that came or were made via mobile money in one system, and the rest on another system, with a different set of tools and configurations.

Solution: Application programming interfaces (APIs). Mobile money providers must make it easy and safe for businesses to export information on payments received via mobile money in formats that can be used with corporate accounting and enterprise resource management (ERP) systems. I know, easier said than done, but without good integration with existing corporate systems, the business will keep throwing antibodies at mobile money.

Pain point #5: My money is stranded in the mobile money account. Formal businesses tend to like their money sitting in a preferred bank account, and they are not so happy having to hold liquidity balances in a zero-interest mobile money account. Transferring money between the two may take days if they involve interbank settlements. That’s a treasury tax on the business’s operations.

Solution: Immediate liquidity facility. Mobile money providers might work with aggregators who have accounts in all major banks. They can then offer business users quasi-real time conversion of mobile money into bank money, because they can handle all such operations as intra-bank transactions, much like superagents do to offer immediate liquidity to cash merchants.

These solutions would make mobile money more easily acceptable by business users. But they have one added advantage: they can be used to have customers self-select themselves into higher-value business packages, which can drive much more nuanced differential pricing. You want a business customer number with a checksum digit, a syntax check on the reference field, a customer receipt printing capability, a set of corporate APIs and immediately liquidity? Let me tell you about our platinum service…