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.

13minutes3learning objectives3check questions
LEARNING OBJECTIVES

After this lesson, you should be able to:

  1. Explain what a prepayment token is and why it works once, on one meter
  2. Choose between local token entry and remote token delivery for a given area
  3. Specify the customer interface unit, emergency credit and friendly hours as programme decisions, not meter defaults
EXPLANATION

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.

01

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.

Token issued
02

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.

Local or remote
03

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.

Accepted or rejected
04

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.

Policy applied
TECHNICAL VISUAL · SYSTEM-SPECIFIC MODEL

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.

Single phase prepaid meter with a keypad on its face
Keypad meter, token keyed on its face
Split prepayment meter for sealed installation
Split meter, sealed away and paired to an interface unit
  • 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.

As the credit runs downFour settings the cooperative decides
  1. Credit addedThe accepted token raises the balance. On a time of use tariff it drains faster at peak hours.
  2. Low credit warningStaged visible and audible warnings on the meter and the interface unit.SetThe warning levels and how many stages
  3. Emergency creditA small negative balance keeps the supply on. The next purchase recovers it.SetThe amount allowed
  4. Friendly hoursNo disconnection at night, on Sundays or on holidays, even at zero credit.SetThe hours and the holiday calendar
  5. 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.

READING NOTEIllustrative flow. Which paths are available, and which is primary, depends on the meter model, the communications architecture and the vending integration.
OPTIONAL ENGINEERING DEPTHEngineering reasoning for this learning pathThe same design relationship, checks and evidence apply across all five lessons in this path.
DESIGN RELATIONSHIPEnd-to-end success = field exchange × transport × platform processing × downstream acceptance
  • Define the eligible population and time window
  • Measure the result at the utility-use boundary
  • Preserve identity, timestamp, status and acknowledgement
ENGINEERING CHECKS FOR THIS PATH
  1. 01Trace a reading and a return command across every interface
  2. 02Segment results by topology, terrain and service type
  3. 03Freeze KPI denominators, exclusions and acceptance gates
FAILURE ANALYSIS
Observed signalPossible causeDiscriminating test

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

PROJECT EVIDENCE TO COLLECT
  • Time-aligned HES and MDMS extracts
  • Device-to-service identity map
  • Exception ageing and closure register
WORKED EXAMPLE

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.

  1. Confirm the meter number on the sale matches the meter number on the customer’s installation record
  2. Read the rejection code: a used token, a token for another meter and a key mismatch are different failures with different owners
  3. Check the meter’s token log for the last accepted token and its time reference
  4. 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
INTERPRETATION

Most rejections are identity or key problems, not meter faults. The token log is the evidence that settles who is owed what, which is why the log depth and export are specification items.

COMMON FAILURE OR MISCONCEPTION
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.

RETRIEVAL PRACTICE · 3 QUESTIONS

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.

OBJECTIVE · Explain the token

Why can a token bought for one meter not be entered on a neighbour’s meter?

How confident are you?
OBJECTIVE · Choose a delivery path

An island barangay has patchy cellular coverage and meters on poles. What should the terms of reference require?

How confident are you?
OBJECTIVE · Set customer protections

Where should the friendly hours policy come from?

How confident are you?
Answer every question and confidence prompt.