Daily reconciliation answers a practical question: can the operator explain how each recorded payment relates to the intended subscriber service? The work becomes harder when support staff rely on customer screenshots, different teams use different time windows, or an unresolved transaction disappears into a chat conversation at the end of a shift.
This guide proposes a reconciliation workflow for an ISP using mobile-money collections. It describes records, responsibilities and checks rather than assuming a particular billing menu or payment integration. Adapt it to the collection product and controls actually approved for your business. Changes to payments, refunds and customer entitlement should remain within the authority assigned to the responsible staff.
Define the period and accounts being reviewed
Choose a clear reporting period and timezone. Record its beginning and end so that the same transaction is not unintentionally reviewed under different dates by different teams. If more than one merchant account, site or collection channel is used, list them explicitly.
Confirm which records are authoritative for each part of the review. A provider statement or transaction record supports the collection side; the billing system supports the subscriber and service side. A customer's receipt can help locate an item, but it should be checked through the approved merchant process rather than treated as the only evidence.
Safaricom describes business channels for accessing collections and statements in its M-PESA Business Channels guidance. Use the channel and permissions appropriate to the actual merchant account. This article does not assume that every collection product offers identical reference fields or reporting controls.
Preserve the source records before matching
Obtain the records through an authorized account and note when they were retrieved. Keep the original export or report in the operator's approved location. Work from a controlled copy or a supported reconciliation view so that annotations do not replace the original evidence.
Record the report filters, account and status scope used. A comparison between completed collections on one side and every attempted payment on the other will produce misleading differences. Resolve that scope question before treating a total as an unexplained loss.
Limit access to the people who need the records. Transaction reports may contain personal information that should not be forwarded to a general staff group or included in public troubleshooting examples. Use account and case references in routine handovers, with detailed evidence available through the authorized private channel.
Match the transaction to the intended subscriber
Use the identifiers supported by the collection flow and billing integration. These may include a provider transaction identifier and a recorded relationship to a subscriber or invoice. Confirm the intended match from the available evidence rather than relying solely on a similar name or a shared phone number.
Follow the payment provider's instructions for the actual product used. Customer-facing reference fields differ between payment methods. Do not tell every customer to enter an invoice reference into a field that their selected payment flow does not provide.
When the intended match is ambiguous, place the item in a review queue with a reason and an owner. Contact the customer through the approved support process when clarification is necessary. Avoid creating a second subscriber account or applying the same receipt to several accounts simply to make the unmatched list shorter.
Classify exceptions consistently
Use a small set of categories that tell the next person what needs to happen. Useful operational categories can include a missing billing record, an unclear subscriber match, a status disagreement, a suspected duplicate, or an item waiting for provider clarification.
For each exception, retain the transaction reference, the amount as recorded, the relevant dates and the current evidence. Add the next action, its owner and the planned follow-up time. Keep a distinction between an observation and a conclusion: “not found in the selected billing period” is different from “the payment was lost.”
If a record arrives later, update the existing exception rather than opening a disconnected second case. Link any supporting evidence and describe how the new information changes the conclusion. The aim is a traceable resolution history, not a spreadsheet that appears balanced because difficult rows have been removed.
Check service entitlement separately
After a payment is matched, compare it with the intended subscriber service. Review the relevant package and service period using the supported billing workflow. If the customer also reports an access problem, record that as a related service investigation with its own evidence.
Payment matching, subscription state and successful internet access are separate observations. A receipt does not prove that a device has authenticated, and a working device does not establish that the correct payment record has been matched. Keep those checks connected without treating them as interchangeable.
Use the operator's approved process for any correction. Record the reason, the person making the change and the intended effect. Do not ask the customer to pay again as a shortcut for diagnosing an unresolved transaction. Where a reversal or refund is appropriate, follow the authorized provider and business procedure rather than treating it as an ordinary data edit.
Compare totals with an explained scope
Once individual exceptions are understood, compare the relevant totals for the same accounts, period and statuses. Keep completed collections, reversals, adjustments and unresolved items distinct in the working record. Do not silently combine unlike categories to force agreement.
Document the difference and its current explanation. A timing difference may need a later review; a missing match may require account investigation; a suspected duplicate may require provider evidence. Assign each difference to an actionable category rather than reporting only a single unexplained number.
Safaricom's Buy Goods guide includes merchant statement and transaction-review information. Confirm the controls and roles applicable to your account before carrying out a provider-side action. This operational checklist is not a substitute for your organization's accounting policies or approval requirements.
Make corrections visible and reviewable
A correction should leave enough context for another authorized staff member to understand it. Link the original transaction, the affected subscriber record, the supporting evidence and the reason for the action. Record the outcome after the correction, not just the intention to fix it.
Where the operator requires a second review, arrange it through the normal approval process. Restrict permissions according to responsibility so that someone collecting evidence does not automatically gain authority to alter payments or customer access.
Keep temporary notes from becoming permanent exceptions to the normal workflow. If a workaround was necessary, name its owner and the condition for removing it. Check that the final record remains understandable after a shift change and that future staff will not repeat the same adjustment because they cannot find the earlier decision.
Give the next shift a concise handover
Summarize the completed review period, the accounts covered and the unresolved exceptions. Include the latest evidence checked, the next action for each open item and the person responsible. Keep the detailed transaction material in the approved private record rather than copying it into every message.
For a hypothetical example, a handover could state that a merchant transaction has been confirmed, the subscriber match remains uncertain, and support is waiting for an account clarification. Another could state that the payment is matched but a separate network-access incident remains open. Those descriptions tell the next team which work to continue.
Agree when an unresolved customer case will receive another update. A useful update explains the current state and the next step without promising a provider response or a financial outcome that has not been confirmed.
Improve the process from recurring exceptions
Review the categories that recur. If many customers use the wrong collection instructions, improve the instructions for that specific payment method. If staff repeatedly select different reporting periods, make the period and timezone prominent in the checklist. If handovers lack account context, improve the required fields.
Track changes against an observed baseline without inventing efficiency claims. Record what changed and whether the same exception became less frequent. Keep the process proportionate: the goal is a reliable explanation of collections and service records, not more forms for their own sake.
Contact CENTRANET to discuss your ISP billing workflow and the collection methods supported in your workspace. Bring the current process and anonymized exception categories so the review can focus on the actual gaps.