Paying KRA from your M-PESA short code
What Safaricom's Tax Remittance API does, the KRA integration it needs first, why every payment quotes a PRN, and how to record tax payments either way.
By Achekam · · 4 min read · For Running a business businesses in Kenya
Most Kenyan businesses pay KRA from M-PESA the same way: someone generates a payment slip on iTax, picks up a phone, pays the government paybill and types the slip's reference as the account number. It works, but it depends on a person, a phone and careful typing every time.
Safaricom offers another route. Its Tax Remittance API lets a business's own system send tax to KRA straight from the business's M-PESA short code. For a business with high tax volumes and its own development team, that is an attractive idea. This article explains what the API does, what it needs before it can be used, and how tax payments should be recorded whichever route you take.
What Safaricom's Tax Remittance API does
Safaricom says its Tax Remittance API lets a business remit tax to the Kenya Revenue Authority in real time from its own M-PESA short code.
The key words are "its own short code". The payment comes out of the business's M-PESA account, not an individual's phone, so there is no personal wallet in the middle and no staff member paying company tax from a private line.
The prior integration with KRA it needs
Safaricom is clear that the API does not stand alone. Using it requires prior integration with KRA for tax declaration, payment registration number (PRN) generation and the exchange of other tax information.
That is the real hurdle. The API is the last step of a chain that starts with a system already connected to KRA: declaring the tax, obtaining the PRN and only then paying. A business that files on iTax by hand and generates its slips there has none of that chain in place, and for it the manual route remains the practical one. Before committing to a build, read about KRA's own developer platform in KRA's GavaConnect APIs and talk to both KRA and Safaricom about what the integration involves.
Three questions usually settle whether the build is worth it. How many tax payments does the business make in a month? Does it already have a system that declares tax and obtains PRNs without a person on iTax? And who will maintain the integration when KRA or Safaricom change something? If the honest answers are "a few", "no" and "nobody", the paybill route is the sensible one.
The PRN as the account reference
Safaricom says each Tax Remittance request quotes the PRN issued by KRA as the account reference.
That matches KRA's rule for every mobile money tax payment. KRA says the account number for such a payment is the Payment Registration Number, or the reference number on the payment slip generated from iTax, iCMS, EGMS or KESRA iStudent. No PRN, no payment: the reference is what tells KRA which tax, which period and which taxpayer the money is for. The PRN comes from a payment slip, so generate a fresh slip for each payment rather than reaching for an old reference.
Asynchronous results to your ResultURL
Safaricom says Tax Remittance results are sent asynchronously to the business's ResultURL. The request is accepted first, and the outcome arrives separately.
For the business's records, that means a tax payment sent through the API is pending until the result arrives. The system that sends it must listen for the result, match it to the original request and only then treat the tax as paid. A payment whose result never arrives must be checked, not resent, or the business risks paying the same tax twice.
KRA's single government paybill
On the manual side, KRA says all tax payments by mobile money must be made only through the Government PayBill number 222222, in line with Kenya Gazette No. 16008 of 2022 and a Presidential Directive making it the Government's single payment platform. KRA also says tax can be paid by dialling *222#, choosing "Pay KRA bill", entering the e-slip (PRN) number and paying with M-Pesa.
Some older KRA pages still show a previous paybill. Ignore them. If you build the API integration, confirm with Safaricom and KRA which receiving short code the request must carry, and keep KRA's public notice in mind as the authority on where mobile money tax payments go.
Recording the payment in Achekam with its PRN and a second check
Achekam does not file any payroll return with, or pay, KRA or any other authority. It prepares the documents and records what a person filed and paid. That holds whichever payment route you use.
When a Kenyan tax payment is recorded, Achekam takes KRA's own reference and receipt, the PRN, and never generates a payment reference itself. It refuses Kenya's discontinued paybill 572572, and it needs a second person to confirm the payment before it counts.
| Step | Where it happens | Who does it |
|---|---|---|
| Declare the tax and generate the PRN | iTax, or a KRA-integrated system | The person with filing permission |
| Pay against the PRN | Paybill 222222, *222#, or the Tax Remittance API | The payer, or the integration |
| Confirm the result | M-PESA confirmation or the ResultURL message | Finance |
| Record the payment with PRN and receipt | Achekam | A first person |
| Confirm the recorded payment | Achekam | A second person |
The second check is the cheapest protection a business has against paying the wrong PRN or recording the right payment twice. Who may move money from the short code in the first place is a portal question, covered in M-PESA portal roles and two-person control, and a short code must have been through Safaricom's Go-Live, described in taking M-Pesa live, before any production API will work.
Safaricom's Tax Remittance API page describes how a business remits tax to KRA in real time against a PRN, and the prior integration with KRA it requires.
General guidance only, not advice on your own circumstances. Tax and payroll rules change: check the current position with the authority or your adviser.
