Electric Metering & AMI · Lesson 6 of 6
Prepayment: credit in the meter, evidence in the log
A prepaid electricity account does not live in the billing system. It lives inside the meter as a credit balance, in energy or currency units, and the meter’s own relay enforces it: when the balance reaches zero the relay opens, and when credit is added it closes. Everything the cooperative builds around prepayment exists to load that balance safely, to protect the customer while it runs down, and to settle disputes from the meter’s own record rather than from memory.
After this lesson, you should be able to:
- Explain what a prepayment token is and why it works once, on one meter
- Choose between local token entry and remote token delivery for a given area
- Specify the customer interface unit, emergency credit and friendly hours as programme decisions, not meter defaults
What is physically and operationally happening?
A prepaid electricity account does not live in the billing system. It lives inside the meter as a credit balance, in energy or currency units, and the meter’s own relay enforces it: when the balance reaches zero the relay opens, and when credit is added it closes. Everything the cooperative builds around prepayment exists to load that balance safely, to protect the customer while it runs down, and to settle disputes from the meter’s own record rather than from memory.
Credit is loaded by a token, a numeric string generated by a vending system under the Standard Transfer Specification (the IEC 62055-41 family). The vending system encrypts the purchased amount with a key unique to one meter and stamps it with a time reference. The meter decrypts it, checks it against its own key and its record of tokens already used, and adds the credit. A token therefore works on exactly one meter and exactly once. The same mechanism carries management instructions: a key change, a tariff change, a maximum power limit, a clear tamper command. The utility manages the meter with the tool the customer uses to pay for it.
Vend
The customer buys credit at an office, an agent, a kiosk or a mobile channel. The vending system generates the token for that meter and records the sale.
Deliver
Locally, the token reaches the customer on a receipt or message and is keyed into the meter or its interface unit. Remotely, the head-end system pushes it over the AMI network.
Apply
The meter validates the token, adds the credit, writes the token log entry and reports acceptance or a rejection code on its display or interface unit.
Protect
Staged low credit warnings, emergency credit and friendly hours govern what happens as the balance falls, under the utility’s policy and the regulator’s rules.
Two delivery paths for one token
The local path works with an offline meter; the remote path only works while the meter is reachable. A programme needs both.
Two ways in, one meterIllustrative flow · sample token
Customer paysAt an office, an agent, a kiosk or on a phone. The vending system generates a 20 digit token for this one meter.
Path A · localWorks with no network at all
Receipt or phoneThe token reaches the customer5918 0264 7731
4402 6180
Keyed inOn the meter keypad or on the interface unit5918 0264 7731
4402 6180
Path B · remoteWorks only while the meter is reachable
Head end systemReceives the token from the vending system
AMI networkPushes it to the meter. No keypad entry.
The same meterValidates the token once only, and only on this meter, then adds the credit.


- Remote: credit added on arrival
- Local: credit added after entry
Specify both paths. The local path is the fallback for outages and dead spots; say which one is primary in each area.
- Credit addedThe accepted token raises the balance. On a time of use tariff it drains faster at peak hours.
- Low credit warningStaged visible and audible warnings on the meter and the interface unit.SetThe warning levels and how many stages
- Emergency creditA small negative balance keeps the supply on. The next purchase recovers it.SetThe amount allowed
- Friendly hoursNo disconnection at night, on Sundays or on holidays, even at zero credit.SetThe hours and the holiday calendar
- DisconnectionThe relay opens. Credit added closes it again.SetCustomer notice and reconnection rules
Each setting is a programme decision written from the regulator's prepaid service rules and the cooperative's own policy. The meter enforces it; it does not choose it.
OPTIONAL ENGINEERING DEPTHEngineering reasoning for this learning pathThe same design relationship, checks and evidence apply across all five lessons in this path.+
- Define the eligible population and time window
- Measure the result at the utility-use boundary
- Preserve identity, timestamp, status and acknowledgement
- 01Trace a reading and a return command across every interface
- 02Segment results by topology, terrain and service type
- 03Freeze KPI denominators, exclusions and acceptance gates
HES read exists but billing data is missing
Mapping, validation or export failure
Trace one interval and its acknowledgements
Aggregate KPI is strong but exceptions cluster
Topology or service-condition bias
Segment performance and compare cohorts
- Time-aligned HES and MDMS extracts
- Device-to-service identity map
- Exception ageing and closure register
A token is rejected at the meter
A customer buys credit through a mobile channel, keys the twenty digits into the interface unit and the unit shows a rejection code. The customer calls the cooperative.
- Confirm the meter number on the sale matches the meter number on the customer’s installation record
- Read the rejection code: a used token, a token for another meter and a key mismatch are different failures with different owners
- Check the meter’s token log for the last accepted token and its time reference
- If the key is the cause, issue the key change token and re-apply the credit token; if the sale was against the wrong meter, reverse and re-vend
“Prepayment needs AMI, because the system has to send the credit to the meter.”
Prepayment predates AMI and works with no network at all through the local path. AMI adds the remote path and the ability to read the credit register and token log centrally. A programme that relies only on the remote path has no fallback for outages and dead spots.
Check what you can explain without looking back.
Choose an answer and report your confidence. The confidence signal is stored only until you submit this page.
Why can a token bought for one meter not be entered on a neighbour’s meter?
An island barangay has patchy cellular coverage and meters on poles. What should the terms of reference require?
Where should the friendly hours policy come from?
Sources for further study.
International references support further study. They do not replace Philippine laws, regulations, utility requirements or project specifications.
01IEC 62055-41:2018 Standard Transfer Specification (STS)International Electrotechnical CommissionScope of the application layer protocol that carries prepayment credit and management tokens from a vending system to a payment meter.
Open source ↗02Guidelines for Smart Grid Cybersecurity, NISTIR 7628 Revision 1National Institute of Standards and TechnologyAMI actors, interfaces and cybersecurity considerations.
Open source ↗Read the complete technical paper →