Posts tagged: audit trail

Voucher reconciliation is the day-close job of proving that the stock your platform holds, the sales your channel reports and the credits your charging system applied all describe the same vouchers. In an electronic voucher management system it sits right next to PIN security, because most of the gaps found at close come from one of two places: a counting fault somewhere in the pipeline, or a secret that left the building. This post walks through the mechanics: which records get matched, on which keys, with which time window, and what the leftovers look like.

For the wider platform scope, see the electronic voucher management system overview.

Voucher reconciliation starts with three ledgers

Every prepaid voucher programme produces three independent records of the same day. The IN or OCS writes a recharge CDR whenever a voucher or PINless top-up credits a subscriber. The EVD platform writes a sale ledger entry when a dealer sells. And the dealer wallet writes a debit for the value of that sale. Reconciliation is the join between them.

The charging side usually arrives as a file export rather than a live feed. On Ericsson-style charging the refill request goes over UCIP (an XML-RPC interface), and the fields worth keeping are the ones the request itself carries: subscriberNumber, originTransactionID, originTimeStamp, transactionAmount and transactionCurrency, plus the voucher serial when the refill was voucher-based. Other vendors name things differently, and the CDR export format can change between charging releases, so pin the field mapping in the interface document rather than in someone’s script. Diameter credit control (Gy/Ro, 3GPP TS 32.299) matters here mostly as context. It governs usage charging, not recharge, but the same OCS writes both kinds of record and the export often mixes them.

Standards writing points the same way. GovStack’s voucher and payment orchestration requirements ask for unique end-to-end identifiers, encrypted storage of sensitive voucher data, and reconciliation inside and across parties (voucher storage, audit, and reconciliation). GSMA’s analysis of airtime distribution costs explains why operators moved to electronic channels at all (GSMA on airtime distribution savings).

Before you join anything, normalise

Most false mismatches we chase at close are formatting, not fraud. The commonest is the MSISDN. A POS in Riyadh may send 0551234567, the USSD gateway may send 966551234567 and the charging export may hold +966551234567. Convert all three to E.164 before matching: strip the plus sign or a leading 00, drop the national trunk prefix (the leading zero) and prepend the country code. E.164 numbers are at most 15 digits, which also makes a cheap sanity check for garbage input.

Time is the second trap. Charging nodes usually log in UTC, POS terminals log in local time, and a terminal whose clock has drifted can be minutes out. Convert everything to UTC first. Then match within a window instead of on exact timestamps: we use T+15 minutes after the sale timestamp as a default, widened for channels known to batch-submit (some offline POS fleets upload hours later). A sale near midnight UTC whose credit lands after the cut-off belongs in tomorrow’s charging file, so carry unmatched rows forward one day before calling them exceptions.

A worked day-close (illustrative figures)

The table below shows one dealer, one denomination, one day. All figures are illustrative; they are not from any operator.

Read it right to left. The wallet has one more debit than the ledger has sales, which almost always means the terminal retried a sale after a timeout and the wallet service did not dedupe on the original transaction ID. The three sales with no credit need a look at the UCIP responses: a non-zero responseCode on the refill means charging refused it and the voucher should go back to available (or to the exception state if the PIN was already shown to a customer). See how unknown top-ups should be held and settled.

The unmatched-transaction query

A pseudo-SQL version of the report finance gets every morning. Table and column names are placeholders.

-- sales with no matching charging credit
SELECT s.txn_id, s.serial, s.dealer_id, s.msisdn_e164, s.sold_at_utc, s.amount
FROM evd_sale s
LEFT JOIN in_refill_cdr c
  ON (c.voucher_serial = s.serial OR c.origin_txn_id = s.txn_id)
 AND c.msisdn_e164 = s.msisdn_e164
 AND c.event_time_utc BETWEEN s.sold_at_utc
                          AND s.sold_at_utc + INTERVAL '15 minutes'
WHERE s.business_date = :close_date
  AND c.cdr_id IS NULL
UNION ALL
-- wallet debits with no sale
SELECT w.ref_txn_id, NULL, w.dealer_id, NULL, w.debited_at_utc, w.amount
FROM dealer_wallet_debit w
LEFT JOIN evd_sale s ON s.txn_id = w.ref_txn_id
WHERE w.business_date = :close_date
  AND s.txn_id IS NULL;

Each row it returns gets a reason code (timeout, double-submit, charging reject after local commit, clock skew, suspected fraud) and an owner. An unexplained row older than two business days should page someone.

What does a duplicate-PIN redemption look like in the logs?

Two redemption attempts on one serial, usually from different MSISDNs, close together. The first succeeds; the voucher server marks the serial used. The second comes back from charging with a “voucher already used” style response (the exact code depends on the voucher server; on Ericsson-style VS the voucher state is no longer available). In the EVD log it looks like this:

2026-09-30T18:02:11Z REDEEM serial=7741003921 msisdn=966551234567 result=OK   origin_txn=R-88120
2026-09-30T18:02:49Z REDEEM serial=7741003921 msisdn=966559876543 result=USED origin_txn=R-88131

One such pair is usually a customer who shared a photo of the receipt. Twenty pairs on one batch within an hour is a leaked batch file. Alert on the rate per batch, not on single events.

When that alert fires, blacklist the batch’s unredeemed serials straight away and tell the channel nodes holding it. After that, freeze reprints on the affected terminals, run an ad-hoc reconcile of the remaining inventory so the exposure is a number rather than a guess, and preserve the reveal and export logs.

Key handling

Voucher PINs are not card data, so PCI DSS does not formally apply to them. Its key-management requirements (in v4.0, requirements 3.6 and 3.7: documented key custodians, split knowledge, dual control, defined cryptoperiods and key retirement) are still the most practical template we know for PIN custody. Store PINs encrypted with AES under a data-encryption key, wrap that key with a key-encryption key held in an HSM (AES key wrap per NIST SP 800-38F / RFC 3394), and keep HSM administration away from application admins. ISO/IEC 27001 gives the management-system frame; Annex A control 8.24 covers the use of cryptography. None of this implies EVD System holds any particular certification, and you should ask any vendor, us included, for evidence rather than a logo.

Reveal is the other half. Log every reveal once (user, terminal, batch, timestamp and MSISDN where relevant) and require a second approver plus a reason code for any reprint.

Lifecycle states, and one transition we would remove

Every transition should leave an audit record, ideally in append-only (WORM-style) storage. Our opinion, which some vendors will dispute: there should be no path from Redeemed back to Sold or Available at all. Once charging has confirmed a credit, the fix for any error is a compensating adjustment on the subscriber balance, raised in charging, never an edit to the voucher’s state. Platforms that allow the reverse transition make every redemption deniable. Some vendors market flexible status changes as a feature (Comviva’s PreTUPS VMS page, for instance, describes changing voucher status “just in time” for stolen and damaged stock); for stock that has not been redeemed that is useful, so the question to ask is which transitions are allowed after redemption, and who approves them.

For how stock moves through resellers, see What is electronic voucher distribution (EVD)?.

Questions for a vendor demo

Ask them to run the unmatched report above on their own demo data, with a deliberately skewed terminal clock, and to push a reprint request through dual control while you watch. And ask who, by role, can export clear PINs from production; the right answer is nobody, and if the vendor needs to check, note that down.

If a vendor can only demo “generate PIN, show on phone”, that tells you most of what you need. How to choose an electronic voucher management system has the full evaluation grid.

EVD System

EVD System by MoboGage covers generation or intake, hierarchy allocation, multi-channel sale, the redemption path and the day-close pack described above. Talk to us via About MoboGage or the contact page (projects@mobogage.com, +91-9928 366 889). If you can, bring last week’s exception list.

Related reading: how the three ledgers fit together in an EVMS architecture; electronic top-up for telecom airtime covers the PINless side of the same close, and multi-tier reseller voucher distribution covers how dealer wallets are funded. Moving off a legacy platform? The EVMS migration playbook shows how lifecycle states and dealer balances carry across, and the EVMS glossary defines the terms used on this page.

FAQ

What is voucher reconciliation in telecom prepaid?

It is the daily match between voucher inventory states, channel sales with their wallet debits, and charging redemptions, so finance and fraud teams can close the day with every difference explained and owned.

How does PIN security relate to an electronic voucher management system?

An EVMS holds voucher secrets for their whole life. PIN security is the set of encryption, key custody, access, reveal and redemption controls that stop those secrets turning into unauthorised credit.

Can we reconcile if we only run PINless eTopup?

Yes, but the objects change. You match float debits and sales against charging credits by transaction ID and MSISDN rather than by voucher serial. Operators that still sell any PIN products usually keep EVMS-grade audit for those.

What should a day-close pack include?

Opening and closing inventory or float, sales by channel and dealer, redemptions, cancels and expiries, and an aged exception list with an owner and a reason code on every row.

How do we handle a compromised batch?

Blacklist the unredeemed serials in the batch, notify the channel nodes holding it, preserve reveal and export logs, and reconcile the remaining inventory immediately. Write the playbook before you need it.

Is encryption alone enough?

No. Encryption without role control, reveal policy, device hygiene and named reconcile owners still fails in ordinary operations.