Reconciliation for ISPs and Subscriptions

An internet service provider in Nepal is, financially, a subscription business wearing a network operator's clothes. Thousands of customers each owe a recurring amount every month, and the entire health of the business depends on collecting those amounts, knowing exactly who has paid, and cutting off - or chasing - those who have not. The billing is predictable. The collection is anything but, because customers pay whenever and however they like: eSewa this month, a Fonepay QR the next, a bank transfer the month after.

Reconciliation for an ISP or any subscription business is the discipline of matching a chaotic stream of incoming payments back to a tidy list of accounts and their expected charges. This article covers how recurring collection actually behaves in Nepal, why failed renewals are the number that matters, and how to match payments to accounts reliably.

The shape of the problem

A retail shop reconciles anonymous sales. A subscription business reconciles against a known roster of accounts, each with an expected monthly charge. That difference defines the work.

• Every account has an expectation. Customer 4471 owes Rs 1,500 this month for their plan. Reconciliation is checking whether that expectation was met, not just whether money arrived.
• Payment timing is scattered. Due dates are nominal. Customers pay early, late, or in the grace period. A payment that arrives on the 3rd might be for last month's bill, this month's, or both.
• Amounts vary. Plan changes, prorations, arrears, and reconnection fees mean the amount paid does not always equal the base plan price. You reconcile against the account's actual expected charge, not a flat number.
• Channels are mixed and settle as lumps. eSewa, Khalti, and Fonepay each sweep many customers' payments into one bank credit, net of fees, on their own schedule.

Recurring collection is not automatic in Nepal

In markets with dominant card-on-file, subscriptions auto-charge and reconciliation is mostly about handling the failures. In Nepal, most recurring collection is still customer-initiated - the customer chooses to pay through their eSewa or Khalti wallet, or scans a bill via Fonepay, each cycle. That has two consequences.

First, non-payment is not an exception; it is a routine state you manage every single cycle. A meaningful share of accounts will not have paid by the due date, and that is normal operations, not a crisis.

Second, because the customer initiates, the payment does not carry your billing system's clean account reference unless you engineer it to. If the customer just sends Rs 1,500 from their wallet with no useful remark, you are left matching on amount, phone number, or timing - all imperfect.

Matching payments to accounts

With payments gathered and reconciled against the bank statement, the matching runs in tiers, from most to least reliable:

• Exact reference match. The payment carries the customer code. It applies straight to that account's open cycle. This should be the large majority if your billing embeds the reference.
• Identifier match. The payment carries a phone number or username that maps to an account. Reliable enough to auto-apply with a light review.
• Amount-and-timing match. An account is due Rs 1,500, a Rs 1,500 payment appears in the window, and no other candidate fits. A reasonable guess that a human confirms.
• Exceptions. Payments that match nothing, or match several accounts ambiguously. These queue for manual resolution.

The settlement lumps have to be decomposed first, of course - each eSewa or Khalti credit is a batch of many customers' payments, read the way an eSewa settlement report is read, and reconciled against the bank statement so you are matching real, settled money.

Failed renewals: the number that runs the business

For a subscription business, the health metric is not revenue collected - it is the gap between expected and collected, the failed renewals. Every cycle, some accounts do not pay. Reconciliation is what tells you exactly which ones, with certainty.

• Who has not paid. Accounts with an open cycle and no matched payment. This drives your dunning, reminders, and eventual service suspension.
• Who paid partially. An account that owes Rs 1,500 but only Rs 1,000 landed. Common, and easy to miss if you only check for the presence of a payment rather than the sufficiency of it.
• Who paid but was not matched. The dangerous one - the customer paid, the money is in your bank, but your reconciliation failed to attach it. If you suspend this customer for non-payment, you have a support crisis and a lost customer over your own matching error.

The reconciliation rhythm for a subscription business

The workable rhythm is a daily close that rolls up into a monthly billing cycle. Each day, new payments are gathered, decomposed from their settlement lumps, matched to accounts, and applied. Balances update. By the due date and grace period, the failed-renewal list is proven rather than guessed. This is the same proven-close discipline described in what a daily close is, applied to a recurring roster.

Rolled up, the month gives you clean figures: total expected, total collected, fees paid to providers separated out, and a trustworthy list of who to chase and who to suspend. Those clean, reconciled entries are what your accounting - a tool like Tigg, say - should be fed, rather than a raw dump of wallet credits that nobody has matched to a customer.

Doing this across thousands of accounts and three or four payment channels every cycle is exactly the kind of repetitive, high-volume matching that eats an accounts team's month. RakamHQ ingests the provider reports and bank statement, decomposes each settlement, and matches payments back toward the right account-month, so the failed-renewal list you act on is one you can actually prove - and no paying customer gets cut off for a reference that simply went missing.

Frequently asked

Why is recurring collection in Nepal not automatic?

Most recurring payments are customer-initiated through eSewa, Khalti, or Fonepay each cycle rather than auto-charged from a card on file. So non-payment is a routine monthly state to manage, and payments arrive without your account reference unless you engineer it in.

How do I match a wallet payment to a customer account?

Match in tiers: exact customer-code reference first, then a phone or username identifier, then amount-and-timing, then a manual exceptions queue. Embedding the account ID in bills, links, or QR codes moves most payments into the exact-match tier.

What is the key metric for a subscription business?

Failed renewals - the gap between expected and collected each cycle. Reconciliation tells you exactly who did not pay, who paid partially, and critically who paid but was not matched.

Can I suspend an account for non-payment automatically?

Not on a no-payment-recorded flag alone. First confirm the payment did not arrive unmatched, because cutting off a customer who paid on time over a missing reference is the fastest way to lose subscribers and generate support crises.

Keep reading

How Khalti Settlement and Payouts Work

Read

What Is a Daily Close, and Why Prove It?

Read

Reconciling School Fee Collection in Nepal

Read