Explode every bank lump into the payments inside it.
A single 'ESEWA STL' credit hides dozens of payments and a fee. RakamHQ decomposes each bank lump into the exact transactions it contains - the pass no accounting tool in Nepal performs.
A bank credit is a batch - many payments collapsed into one number, net of fees. Reading it means reversing that collapse. RakamHQ takes each settlement, gathers the verified payments that belong to its period, applies the provider's fee model, and checks they sum to the net credit.
This is the signature algorithm, and it is where money quietly hides. A settlement that 'looks about right' can conceal an overcharged fee or a payment that never arrived - decomposition is what turns 'about right' into proof.
What you get
- Every settlement fitted to the exact payments inside it
- Per-rail fee models reconciled to the net credit
- Handles payments that settle in a later batch
- Netted refunds shown explicitly inside the batch
- Residuals named and surfaced, never rounded away
- Expected-vs-arrived settlement calendar per provider
Settlement decomposition, in detail.
How a lump is decomposed
For each bank settlement, RakamHQ builds the candidate window of verified payments, applies the fee model - per-transaction where the rail reports it, derived where it does not - and fits it to the net credit. An exact fit becomes a proven batch. A small residual is explained; anything larger becomes a decomposition exception that shows the best fit and the exact residual amount, to the rupee.
Pooling and timing, made visible
eSewa settlements are merchant-initiated - money pools in your wallet until you sweep it - while Khalti and Fonepay settle on their own cadence. RakamHQ tracks each rail's timing, estimates the balance still pooled, and flags a settlement that arrives late or a wallet sitting idle. You see where money is on its way, not only where it has landed.
Expected versus arrived
Every provider has a rhythm, and RakamHQ learns it. It holds an expected-versus-arrived calendar per rail, so a settlement that is due but absent is visible the same day rather than at month-end. Each arrival is checked against the payments it should carry, and a batch that comes in light or heavy is surfaced with the difference named.
Netting, shown not fought
When a rail deducts a refund from a future settlement instead of reversing it, that deduction is shown explicitly inside the batch it lands in - 'reduced by refund #4521' - so a payout that looks short is understood as correctly reduced, with the refund and its evidence attached. No ghost debit, no unexplained gap.
Residuals named, never rounded
Decomposition either closes or it does not, and RakamHQ never pretends otherwise. When the payments and fee will not sum to the net credit, the residual is measured to the rupee, the closest fit is kept, and the gap is raised as an exception rather than rounded into the books. A settlement is marked proven only when the math actually closes.
FAQ
Settlement decomposition,
explained
Common questions about settlement decomposition. Want it run on your own data first? The concierge reconciliation is free.
It is reversing the collapse a bank credit performs - taking one 'ESEWA STL' lump and fitting it back to the exact payments and fee inside it. RakamHQ proves the batch sums to the net credit, so the number stops being a black box.
Get your free reconciliation.
Send us last month's eSewa report, Khalti export, bank statement and orders sheet. Within 48 hours we send back a one-page close - every payment matched, every fee computed, every settlement decomposed.
Files only · private upload link · nothing to install