ERPNext ↔ M-Pesa Integration (C2B, B2C, B2B)
Payments rails for ERPNext: deterministic matching, safe retries, and evidence you can reconcile. Built for callbacks, reversals, and finance-grade audits.
Why payments integrations break ERP projects
Payments don’t fail cleanly. They duplicate, arrive late, reverse, and trigger retries. Without deterministic rules and evidence, finance teams end up reconciling with guesswork.
Callbacks and job retries are normal. If the integration is not idempotent, the same payment becomes multiple ERP entries.
- Duplicate callbacks happen; a payment can be announced more than once.
- Timeouts cause replays: money moved, but ERP didn’t post (or posted twice).
- Duplicate entries create customer disputes and finance cleanup work.
If you can’t prove what happened, you can’t reconcile. Screenshots are not evidence, and ‘it should be paid’ is not a ledger.
- Weak matching rules lead to wrong invoices being closed.
- No event trail makes dispute resolution slow and manual.
- Failures hide in background jobs until customers complain.
Deterministic matching + idempotent retries + evidence trails
This integration is engineered for accounting reality: every event is traceable, replay-safe, and explainable under audit.
Every transaction is processed with deterministic keys and “already applied” checks, so retries do not create duplicate postings.
Payments are matched using explicit rules (references, invoices, customers) - not heuristic guesswork.
Each event stores payload + ERP outcomes + status so you can prove what happened and why.
What’s included (and how it stays correct)
We implement payment rails that finance teams can operate - not just callbacks that ‘post something’.
Customer payments are recorded with deterministic matching and status tracking so invoices, receipts, and ledgers remain correct.
- Deterministic invoice matching (avoid wrong invoice closures).
- Partial payments and overpayments handled explicitly.
- Status tracking (received, posted, reversed, failed) with reasons.
Refunds and disbursements are processed idempotently with evidence and controlled workflows to avoid double sending.
- Idempotent disbursement requests (no double payouts).
- Posting rules aligned with your accounting structure.
- Evidence logs per transaction for disputes and audits.
Vendor and business payments are executed under approvals and traceability so finance retains operational control.
- Approval workflows (who approved what, when).
- Deterministic posting to the right accounts and documents.
- Evidence and audit trails for vendor disputes.
A production payments rail needs visibility: what failed, why it failed, what was retried, and what is safe to retry.
- Automated reconciliation views (prove received vs posted).
- Failure categories with actionable context (not raw logs).
- Retry controls designed to be replay-safe.
The payment realities we design for
These are common in Kenya. Treating them as edge cases is how payment systems become unreliable.
Same transaction can be sent multiple times. Duplicates are treated as normal and harmless.
Payment succeeded but ERP didn’t post. We can safely replay from evidence without duplicating.
Reversals require traceable linkage to original events and clear accounting outcomes.
How we implement without disrupting finance operations
Payments touch trust. We roll out in phases with verification and guardrails.
We define deterministic matching, posting rules, evidence capture, and safe retry semantics.
- Confirm document mapping (Invoice, Payment Entry, Journal rules).
- Define reference strategy (invoice refs, account refs, customer refs).
- Set up evidence logging + reconciliation views.
Enable live C2B/B2C/B2B flows with monitoring, safe retries, and reconciliation proof.
- Enable C2B with posting verification and exception handling.
- Enable B2C/B2B with approvals and double-send prevention.
- Train finance on evidence trails + dispute resolution workflow.
Want payments you can reconcile, audit, and trust?
We’ll review your payment flow (collections, refunds, vendor payouts), your ERPNext accounting configuration, and your reconciliation requirements - then propose an implementation plan that is provable under audit and safe under retries.