Prepaid Electricity Meter RFQ Checklist for Utilities and Integrators

AI-generated illustrative scene of two project staff reviewing documents in a bright workshop; not a real project or a specific product model.
Illustrative discussion of metering project enquiry documents (AI-generated).

A useful prepaid electricity meter request for quotation (RFQ) describes the project, the electrical requirements, the payment workflow and the evidence needed to accept the proposed solution. A quantity and a request for the “best price” leave suppliers to make assumptions that can make their quotations difficult to compare.

For a utility, system integrator or distributor preparing a metering project, the aim is to give every supplier the same starting point. Use the checklist below to organise the request and require a written response against each requirement.

1. Describe the project before requesting a model

Start with the country, project location, purchaser's role and intended users. State whether this is a new installation, a replacement programme or an extension of an existing prepaid system. Separate the pilot quantity from any later rollout forecast.

Attach the tender or utility specification, including its revision date. Identify the project authority responsible for deciding which approvals and documents are acceptable. Where a requirement has not been decided, mark it as open and ask the supplier to state its assumption separately.

This avoids comparing a quotation for standalone meters with another quotation that includes a wider payment or management system.

2. Attach an electrical and installation schedule

Have the responsible project engineer specify the supply arrangement, phase and wiring requirements, operating voltage and frequency, measurement requirements and connection method. If the project includes different installation types, give each one a separate line in the schedule.

Describe the installation location and mounting arrangement. Include available drawings, enclosure dimensions, meter positions and any interface-unit requirements. State whether an enclosure and accessories are part of the RFQ or will be supplied separately.

Use the prepaid electricity meter category to identify products for further enquiry. A category listing is a starting point; the proposed model and configuration still need to be matched to the project schedule.

3. Explain how customers will buy and use credit

Describe the payment process from purchase to meter credit. Identify the existing or proposed vending platform, how customers receive credit information, and how that information reaches the meter or its user interface.

If the project requires STS, request evidence for the exact proposed product and the relevant vending or interface arrangement. The STS Association's product-certification guidance describes certification of payment-meter and vending systems, including their user interfaces. Ask the supplier to identify the certificate and product version that cover its offer.

Keep project approval requirements separate from STS evidence. Ask the project authority to confirm the full documentation required for the installation, rather than treating one certificate or a company logo as the complete approval package.

4. Assign the integration work explicitly

State whether remote reading, remote operations or integration with a head-end, billing or customer-management system is required. Name the existing systems and provide relevant interface specifications where available. Do not leave a requirement as simply “smart meter support.”

Ask each supplier to complete a responsibility schedule:

Work area: Vending

What the RFQ should identify
Existing platform and required payment workflow

What the supplier should state
Supported scope, interfaces and exclusions

Work area: Communications

What the RFQ should identify
Project network and coverage requirements

What the supplier should state
Proposed equipment, dependencies and test plan

Work area: System integration

What the RFQ should identify
Named target systems and interface documents

What the supplier should state
Work included and work by other parties

Work area: Installation

What the RFQ should identify
Site, mounting and accessory requirements

What the supplier should state
Supplied items and installation responsibilities

Work area: Acceptance

What the RFQ should identify
Required documents and test cases

What the supplier should state
Evidence, test procedure and responsible party

The purpose is to expose gaps before the price comparison, including tasks that require a third-party platform provider.

5. Request an evidence pack tied to the offer

Request the proposed model designation, configuration list, current datasheet, installation instructions, applicable certificates and a list of supplied accessories. Ask the supplier to give the document revision and explain how each document relates to the quoted product.

Put optional functions on separate lines. For each option, request its dependency, additional equipment, documentation and price treatment. Avoid allowing one brochure covering several variants to stand in for a clear statement of what will be delivered.

For existing systems, request a written account of the proposed migration and commissioning scope. Define responsibilities for key-management arrangements through the project's approved process; the RFQ can name the responsible parties without including operational keys or credentials.

6. Define the pilot and acceptance criteria

Write the expected result for each project test before samples are evaluated. Depending on the project, tests may cover credit purchase and entry, display information, vending integration, communications, installation fit and required management functions.

For every test, name the party that performs it, the records it produces and the person who accepts the result. Ask suppliers to identify any test equipment, system access or third-party participation needed. A demonstration of one function should not silently close the remaining requirements.

AI-generated illustrative scene with an open folder, project forms and a closed sample case; not evidence of an actual pilot or acceptance result.
Illustrative organisation of enquiry documents and acceptance records (AI-generated).

A practical RFQ summary to send

Include the following with the detailed specification:

  • Project country, location, authority and document revision.
  • Pilot quantity and separately identified rollout forecast.
  • Electrical schedule, mounting details and available drawings.
  • Vending workflow, required STS evidence and interface arrangements.
  • Communications and integration requirements, with named systems.
  • Exact deliverables, options, exclusions and responsibility schedule.
  • Required documentation, pilot tests and acceptance process.
  • Requested delivery destination, quotation validity and commercial response format.

Ask suppliers to return a compliance table using meets, does not meet, optional or clarification required, with a document reference for each material answer. Compare quotations against the same scope, including accessories, integration and commissioning.

When the information is ready, use Londian's project enquiry page to discuss the requirement. The RFQ should make clear what needs to be evaluated, rather than assuming that a product name alone defines the complete solution.

Get a quote
Email
Whatsapp