Utility Collection Through PAD. Follow mandate evidence, billing, PAD presentment, debit outcome, NSF or return, dispute handling and utility cash application.
Block 15 · Chapter 72 of 75
A utility bill looks like a simple monthly debit. Behind it is a controlled mandate-to-cash process.
The utility first needs valid authority to debit the customer's account. It calculates the bill, gives the customer the required information or notice under the applicable agreement, creates a pre-authorized debit (PAD), submits the collection through its financial institution, receives value through the retail batch clearing and settlement framework, applies cash to the customer's utility account, handles insufficient-funds and other returns, and deals with disputes or reimbursement when the debit was incorrect or unauthorized.
The most important distinction is:
The utility's right to collect money under the service contract, the customer's PAD authorization, the payment item sent through the banking system, and any reimbursement or return are four related but separate things.
Cancelling a PAD agreement does not automatically cancel the underlying utility contract or amount owed. A returned debit does not prove the bill itself was invalid. A reimbursement to the customer does not erase the original billing event. Good operations keep these layers separate.
At the 5 October 2026 course baseline, Payments Canada Rule H1 is the governing PAD rule. Administrative amendments took effect on 27 July 2026; the paper-PAD eligibility change takes effect on 1 December 2028, not immediately. For a Personal PAD at set intervals, a variable amount normally requires written pre-notification at least 10 calendar days before the debit unless the agreement validly waives or reduces that period; the first PAD also requires a confirmation at least 10 days beforehand unless that period is waived or reduced by agreement. A Personal PAD claim for an incorrect or unauthorized debit generally has a 90-calendar-day recourse period; a Business PAD claim under H1 generally has 10 business days, so this chapter does not apply the consumer period to business accounts. For an NSF return, the biller may present the same debit once more within 30 days of the original transaction date, for the exact same amount and without adding a fee. Production implementations must use the current Rule H1 text, Standard 007 and the sponsoring financial institution's procedures.
This chapter follows one fictional utility from customer agreement through billing, collection, clearing, settlement, cash application, returns and disputes.
What you should be able to do after this chapter
After working through this chapter, you should be able to:
- explain the difference between a utility contract and PAD authorization;
- identify the participants in a PAD collection;
- describe the mandate/agreement lifecycle under Rule H1 at an operational level;
- explain how variable utility bills interact with notice and authorization requirements;
- trace an AFT debit/PAD from biller submission through ACSS and customer posting;
- distinguish a successful customer debit from final cash application at the utility;
- explain insufficient-funds returns and the permitted same-debit re-presentment rule;
- explain customer recourse for incorrect or unauthorized PADs;
- distinguish cancellation, return, reimbursement and collector recovery;
- design utility cash-application and reconciliation controls;
- identify fraud, data-quality and operational risks in PAD collections;
- describe how a service provider may act on behalf of a payee without becoming the customer;
- design functional and technical requirements for mandate evidence, payment processing and disputes;
- build realistic testing for recurring, variable, one-time and sporadic PAD scenarios.
Chapter navigator
- The utility collection story
- Participants and responsibilities
- PAD agreement and mandate evidence
- Billing, notice and payment creation
- Bank submission, AFT debit and ACSS processing
- Customer debit, settlement and utility cash application
- NSF, returns and re-presentment
- Disputes, reimbursement and cancellation
- Accounting, reconciliation and reporting
- Fraud, compliance and implementation controls
- End-to-end utility scenarios
- Testing, takeaways and authoritative references
1. The utility collection story
Maple Light Utilities is a fictional electricity and water provider serving 260,000 residential and small-business customers.
About 170,000 customers pay by PAD.
Each month the utility:
- calculates usage;
- generates invoice;
- determines payment due date;
- creates PAD collection population for customers with valid agreements;
- submits debit instructions to its bank;
- receives settlement/funding under its banking arrangement;
- applies cash to customer utility accounts;
- processes returns;
- handles disputes.
This is not one batch with one outcome.
A file of 170,000 PADs can contain:
- 164,000 successful debits;
- 4,000 insufficient-funds returns;
- 500 account-closed returns;
- 300 cancelled/invalid authorization disputes;
- 1,200 other timing/data exceptions.
The utility must therefore reconcile at account level.
Why utilities are a natural PAD use case
Utility bills are recurring obligations.
The amount may vary every month based on:
- consumption;
- taxes;
- rates;
- adjustments;
- credits.
PAD lets the payee initiate collection under previously established authority.
The utility benefits from:
- predictable collections;
- lower manual payment handling;
- automated cash application.
The customer benefits from:
- automatic payment;
- no need to initiate every bill.
But because the payee initiates the debit, authorization and recourse controls are essential.
2. Participants and responsibilities
Customer / payor
Owns:
- agreement to PAD;
- account information supplied;
- review of statements;
- cancellation request where needed;
- dispute/reimbursement request when applicable.
Utility / payee
Owns:
- service contract;
- bill amount;
- PAD agreement;
- notice obligations;
- debit creation;
- customer service;
- cash application;
- mandate evidence.
Payment service provider
A utility may use a third party for:
- billing;
- payment file creation;
- collection processing.
Rule H1 contains requirements relevant when a payee uses a separate payment service provider. The utility/payee remains accountable for the PAD relationship required by the rule.
Payee's financial institution / sponsoring member
Receives debit instructions from the utility or provider, validates the customer/product arrangement, and processes eligible AFT/PAD items.
Payor's financial institution
Receives debit item and attempts customer-account posting.
Possible:
- debit succeeds;
- insufficient funds;
- closed account;
- account/routing exception;
- dispute/reimbursement.
Payments Canada / ACSS
Publishes the PAD and retail batch rules/standards and operates ACSS.
Clearing participants
Direct/indirect structure determines:
- exchange;
- clearing position;
- settlement.
The utility normally does not manage the inter-clearing-participant settlement itself.
3. PAD agreement and mandate evidence
Rule H1 makes the PAD agreement central.
The agreement is not merely a checkbox stored somewhere in a website.
The utility needs evidence that supports:
- who authorized;
- account;
- payee;
- type/frequency;
- amount or variable method;
- timing;
- cancellation;
- recourse;
- required disclosures.
Personal and business PAD
Rule/scheme classification: Rule H1 distinguishes Personal PADs (including utility bills), Business PADs (commercial activity), Funds Transfer PADs (the same individual moving funds between accounts), and Cash Management PADs (same or closely affiliated businesses moving funds). A residential or small-business utility collection is normally a Personal PAD or Business PAD based on the payor's activity; it is not a Funds Transfer or Cash Management PAD merely because money moves between accounts. The category controls agreement wording, transaction coding and recourse. Personal and Business PADs have different extended-recourse periods: generally 90 calendar days for Personal PADs and 10 business days for Business PADs. Confirm the classification and bank implementation against current Rule H1 and Standard 007.
Recurring fixed amount
Example:
- condominium water service CAD 85 monthly.
Agreement can identify:
- amount;
- frequency;
- dates.
Recurring variable amount
Typical utility:
The agreement and notice process must support variable debits.
The bank should not assume every PAD must have identical amount.
Sporadic PAD
A sporadic debit occurs only when the payor authorizes each debit according to the rule requirements.
Do not model sporadic as an ordinary recurring PAD with no per-debit authorization.
One-time PAD
A one-time PAD must be identified as one-time in the agreement. After the successful initial PAD, that agreement is no longer valid for another debit; a subsequent debit requires a newly authorized agreement. The system should distinguish:
- one-time;
- recurring;
- sporadic.
Mandate evidence
Useful data:
AgreementId
CustomerId
Payor name
Account / routing
PAD category
Frequency
Variable/fixed
Agreement accepted at
Confirmation sent at
Notice preference
Cancellation status
Effective from/to
Evidence/document version
Digital authorization
A digital journey should capture:
- authenticated customer;
- terms version;
- timestamp;
- account;
- consent evidence.
A database boolean alone:
padEnabled = true
is weak evidence.
Account changes
If customer changes bank account:
- update authorization/evidence according to product/rule;
- verify account;
- preserve old mandate history;
- effective-date new account.
Never overwrite old account and lose historical proof.
4. Billing, notice and payment creation
The utility billing system produces the amount.
Example customer:
- energy: CAD 122.60;
- water: CAD 41.25;
- taxes/fees: CAD 15.40;
- prior credit: -CAD 10.00;
- total due: CAD 169.25.
The payment system should receive the amount, not recalculate the utility bill.
Notice
Rule/scheme requirement: For a Personal or Business PAD issued at set intervals, a variable amount normally requires written pre-notification of the amount or change at least 10 calendar days before the debit. The payor and payee may validly waive or reduce that period in the PAD agreement; the agreement must preserve evidence of that choice. The first PAD also requires a confirmation of the agreed details at least 10 days beforehand unless that confirmation period is waived or reduced by agreement. Utility must store the notice or confirmation content, delivery channel, date, amount or changed date, debit date, and any waiver/reduction evidence. Timing distinction: the current FCAC consumer page says a bank should send written confirmation at least 3 days before a first electronic or telephone withdrawal, while Rule H1's payee-side confirmation requirement is at least 10 calendar days unless validly waived or reduced. Those are not interchangeable controls; production must apply the payee's Rule H1 obligation and the sponsoring FI's documented procedure. Do not invent one notice period for every PAD scenario.
Billing date versus debit date
Store separately:
- invoice date;
- due date;
- PAD debit date;
- bank processing date;
- customer booking date.
Customer changes billing plan
If customer changes:
- due date;
- budget billing;
- account;
- PAD status,
the utility must update future collection instructions and applicable agreement evidence.
Cancellation received after file creation
Important timing issue.
Customer cancels PAD agreement after utility has generated file but before debit date.
Utility should have process to:
- identify unreleased debit;
- suppress where operationally possible;
- follow Rule H1/product handling;
- document cancellation.
If debit already processed, post-event handling differs.
5. Bank submission, AFT debit and ACSS processing
The utility submits a PAD/AFT debit population to its bank.
Submission controls
At file level, use the bank's supported AFT channel and current Standard 005 file rules:
- originator/creditor identifier;
- file ID and creation date;
- count;
- total amount;
- due/value date;
- duplicate and control-total check.
At item level, use the bank's supported AFT or ISO AFT mapping. Standard 007 defines the three-digit transaction-code and 900-series return-reason-code vocabulary; do not invent local codes in the outbound file.
At item:
- payor routing/account;
- amount;
- transaction type;
- customer account reference;
- due date.
Bank validation
Checks may include:
- utility customer entitlement;
- file format;
- transaction codes;
- account/routing;
- dates;
- duplicate;
- risk/compliance;
- originator limits.
The bank does not re-underwrite every utility invoice.
AFT debit
A PAD is represented operationally as a debit collection within the AFT/retail batch framework.
The payee initiates the debit under authority.
The payor's bank receives and posts or returns according to rules/account conditions.
ACSS
Debit items contribute to clearing positions. Current production model: Payments Canada's retail batch system is made up of ACSS and USBE. ACSS calculates net balances across participants; direct clearers maintain settlement accounts at the Bank of Canada, and the previous business day's net balances settle in the morning of each business day. ACSS clears electronic items including PADs, direct deposits and Interac debit items. These are participant-level facts, not a promise about a utility's commercial credit or availability terms.
The utility's cash receipt from its bank should not be confused with individual customer account posting at the exact same instant. A utility normally receives a bank/product report and account credit through its payee FI; it does not directly manage each inter-participant settlement entry.
Direct/indirect
As with payroll:
- direct clearer manages external settlement;
- indirect participant uses sponsor/group clearer.
The utility sees its banking relationship, not the whole settlement chain.
6. Customer debit, settlement and utility cash application
A successful collection has several stages.
- utility created valid PAD;
- bank accepted;
- item exchanged;
- receiving/payor FI posts debit;
- clearing/settlement completes under ACSS;
- utility's bank credits/funds utility under product model;
- utility applies payment to customer bill.
Cash application
Utility must match bank result to:
- customer utility account;
- invoice;
- billing cycle.
Stable reference is essential.
Without it:
- cash is in bank;
- utility account still appears unpaid.
That can trigger incorrect dunning or service-disconnection process.
Utility accounting
Illustratively:
- reduce accounts receivable;
- increase cash/bank;
- account for returns later.
Exact accounting follows utility policy.
Bank accounting
Bank tracks:
- customer/payee credit;
- clearing position;
- settlement;
- returns;
- fees.
7. NSF, returns and re-presentment
Insufficient funds is common in debit collection.
Payments Canada's current consumer and business guides state:
- if there are insufficient funds (or the item is otherwise dishonoured under the applicable process), the biller can try the same debit one more time;
- it must be within 30 days of the original transaction/withdrawal date;
- it must be for the exact same amount, with no added business NSF fee.
Under Rule H1, a PAD can be dishonoured for reasons such as NSF, stop payment or account closed no later than the applicable next-business-day timeframe. A payor FI's cutoff and the payee FI's file/reporting schedule are product-specific and must be obtained from the bank. This is a valuable concrete rule, not a generic retry loop.
What “same debit” means operationally
Do not:
- add NSF fee to re-presented debit;
- change CAD 169.25 to CAD 194.25;
- treat it as the same debit.
If utility wants to collect an additional charge, that requires separate authority/process according to agreement and rules.
Return lifecycle
Original:
PAD-1001 CAD 169.25
Return:
RET-501
Original PAD: PAD-1001
Reason: insufficient funds
Amount: CAD 169.25
Re-presentment:
PAD-1002
Related original: PAD-1001
Amount: CAD 169.25
Attempt: second
Use a new transaction identity while preserving relationship.
Other returns
Possible:
- account closed;
- invalid account;
- authorization/dispute-related;
- other standard reasons.
Use current Standard 007/Rule H1 as applicable.
Utility treatment
For NSF:
- mark payment returned;
- restore receivable;
- decide whether to re-present;
- notify customer;
- do not disconnect immediately if law/product policy requires other steps.
Payment rule and utility service regulation are separate.
8. Disputes, reimbursement and cancellation
Payments Canada's consumer guidance describes a 90-calendar-day route for a Personal PAD claim, measured from the withdrawal date. Rule H1 provides a generally 10-business-day extended-recourse period for a Business PAD. The customer's financial institution applies the category, claim reason, declaration and current Rule H1 process; do not label every PAD dispute "90 days."
That recourse exists because the payee initiated the debit.
Incorrect PAD examples
- wrong amount;
- wrong date;
- debit after agreement cancelled;
- no valid authority;
- duplicate debit.
Customer's FI
When customer raises claim:
- obtains required declaration/process;
- evaluates under Rule H1;
- reimburses where conditions met;
- uses inter-member recovery process.
The exact operational process follows current Rule H1 and bank procedures.
Reimbursement versus return
Customer can be reimbursed before utility has completed its own accounting recovery process.
Keep separate:
- customer reimbursement;
- return/interbank adjustment;
- utility receivable;
- dispute case.
Cancellation
Payments Canada guidance emphasizes:
- agreement should specify cancellation;
- customer can revoke a PAD authorization; the payee must cease issuing PADs within the agreement's stated period, which cannot exceed 30 calendar days;
- cancelling PAD does not cancel underlying contract or amount owed.
This is crucial for utilities.
Customer may cancel automatic debit but still owe CAD 169.25 and must pay another way.
Utility customer service script concept
Correct:
“Your automatic debit authorization has been cancelled. Your utility balance remains due; please choose another payment method.”
Incorrect:
“Your bill is cancelled.”
Debit after cancellation
If utility debits after valid cancellation:
- customer may have recourse;
- utility should investigate mandate state;
- bank processes claim under rules.
Root cause can be:
- cancellation not propagated;
- file already created;
- stale mandate cache;
- date/effective-date defect.
9. Accounting, reconciliation and reporting
PAD reconciliation needs to handle success and returns.
The billing-to-collections diagram above turns the expected-versus-actual population below into a closed loop: expect, observe, prove, then chase only the difference.
Utility expected population
The following is a fictional, illustrative Maple Light Utilities population, not a Canadian industry statistic:
170,000 PADs
CAD 31.2 million
Bank initial processing:
169,500 accepted
500 rejected before release
Later returns:
4,800 returned
CAD 782,000
Utility net cash outcome must reconcile.
Receivables reconciliation
For each customer:
Invoice
→ PAD created
→ bank accepted
→ debit outcome
→ return if any
→ cash application
→ customer balance
Bank settlement reconciliation
Bank:
- debit item population;
- clearing position;
- settlement;
- customer/payee account;
- returns.
Return reserve
Some utility banking arrangements may credit collections before all return risk has expired.
Commercial settlement/availability terms vary.
Do not assume utility can treat all credited funds as economically final immediately.
Reporting
Utility needs:
- accepted/rejected;
- returns;
- reason;
- reference;
- settlement/account statement.
Customer statement
Customer sees:
- utility PAD debit;
- reference;
- date;
- amount.
If reimbursement:
10. Fraud, compliance and implementation controls
Fraudulent PAD originator
Risk:
- malicious entity attempts unauthorized debits.
Bank controls:
- onboarding;
- originator due diligence;
- limits;
- monitoring;
- return/dispute rate.
Utility account takeover
Attacker changes:
- refund destination;
- PAD account;
- customer profile.
Use:
- strong authentication;
- step-up;
- notifications.
Insider fraud
Utility employee could:
- change mandate/account;
- create unauthorized collection;
- suppress cancellation.
Use:
- segregation;
- approval;
- audit.
Duplicate collection
Causes:
- billing rerun;
- file replay;
- technical retry.
Controls:
- unique bill/payment ID;
- file hash;
- idempotency.
Amount anomaly
Utility bills vary naturally.
Fraud/anomaly rules should consider:
- seasonal patterns;
- meter adjustments;
- rate changes.
A high winter electricity bill is not automatically fraud.
Compliance
Banks, utilities and PSPs apply only the obligations that attach to their role and status under applicable law, scheme rules and contracts:
- AML/ATF and sanctions controls;
- operational and third-party risk;
- privacy and security;
- records and investigations.
FINTRAC's EFT reporting definition expressly excludes transfers carried out by direct deposit or PAD; do not treat an ordinary domestic PAD batch as an international EFT report merely because it is electronic. A reporting entity remains responsible even when a service provider submits a report on its behalf. PAD mandate evidence and AML authorization are different concepts.
For an RPAA-regulated PSP, current Bank of Canada supervision also covers operational-risk management, incident response, safeguarding end-user funds and required reporting. This is a PSP obligation, not a blanket rule that every utility customer or biller is an RPAA PSP.
Architecture
Utility billing
→ PAD mandate store
→ Collection engine
→ Bank channel/API
→ AFT validation
→ ACSS / sponsor (current production batch rail)
→ Payor FI
→ Returns
→ Utility cash application
→ Reconciliation
RTR boundary: This chapter is an ACSS/AFT PAD story. The Real-Time Rail is a separate modernization programme and is not the production rail for this PAD flow; current Bank of Canada material describes RTR as planned/design work. Do not substitute RTR instant posting, 24/7 cutoffs or RTR finality for the ACSS batch facts above.
Mandate service
Functions:
- create;
- confirm;
- update;
- cancel;
- evidence;
- effective dating.
Collection engine
Uses only active mandate.
Prevents:
- amount/date outside allowed configuration;
- duplicate invoice collection;
- collection after cancellation effective.
Bank originator controls
Bank monitors:
- volume;
- return rate;
- disputed rate;
- amount changes;
- originator behavior.
Return processor
Automatically:
- matches original;
- restores receivable;
- triggers customer workflow;
- decides re-present eligibility.
Dispute case management
Links:
- original debit;
- mandate;
- statement;
- customer claim;
- reimbursement;
- utility response.
11. End-to-end utility scenarios
Scenario A: normal monthly utility PAD
Customer:
- bill CAD 169.25;
- valid recurring variable PAD.
Utility:
- generates bill;
- gives required notice under agreement/rule;
- submits debit.
Bank/ACSS:
Customer FI:
Utility:
- receives bank reporting;
- applies CAD 169.25 to invoice.
Reconciliation:
Scenario B: insufficient funds
Customer account lacks funds.
Payor FI:
Utility:
- restores receivable;
- notifies customer.
Utility decides to re-present:
- same debit;
- same CAD 169.25;
- once;
- within 30 days.
Second attempt succeeds.
Scenario C: amount incorrect
Utility system bug bills CAD 1,692.50 instead of CAD 169.25.
Customer notices debit.
Customer contacts FI within applicable recourse period.
FI processes claim under Rule H1.
Utility:
- reverses erroneous receivable/payment;
- corrects invoice;
- root-cause fix.
Scenario D: customer cancelled PAD
Customer cancelled authorization last month but file-generation cache still marks active.
Debit occurs.
Customer disputes.
Investigation:
- cancellation evidence;
- effective date;
- file creation;
- Rule H1 claim.
System defect:
- mandate cache not invalidated.
Scenario E: service provider file duplicate
Utility PSP submits same file twice after timeout.
Bank duplicate control catches:
- same hash/file population.
Second file blocked.
If duplicate escaped:
- duplicate debits become high-severity incident;
- reimbursement/recovery coordinated.
Detailed monthly operating cycle
A utility PAD operation normally has several clocks.
Billing close
The utility finalizes:
- meter/usage;
- rate;
- tax;
- prior credits;
- adjustments.
The billing system creates the customer receivable.
No payment has happened yet.
PAD eligibility selection
Collection engine selects customers with:
- active PAD agreement;
- correct effective date;
- eligible billing account;
- valid bank details.
Customers excluded:
- cancelled mandate;
- manual hold;
- dispute;
- alternate payment already received.
This selection should be reproducible.
Notice and due-date control
For variable PADs, the utility must apply the agreement and current Rule H1 notice requirements.
Store:
- notice generated;
- delivery channel;
- date;
- bill amount;
- due/debit date;
- permitted waiver/reduction evidence where applicable.
If notice fails:
- do not simply ignore the control because the debit file is ready.
File build
The collection engine creates items and control totals.
Bank release
Bank validates:
- originator;
- file;
- item;
- date;
- duplicates;
- limit/risk.
Post-processing
Utility receives:
- acceptance;
- returns;
- bank statements.
Cash application closes receivables.
PAD agreement versus service contract
A common customer misunderstanding is:
“I cancelled the PAD, so I cancelled the bill.”
Operational model:
Utility service contract
│
├── creates invoice / debt
│
└── payment method = PAD agreement
Customer can change payment method while debt remains.
This distinction matters in:
- customer service;
- collections;
- disputes;
- legal treatment;
- accounting.
Mandate state machine
A robust mandate can use:
DRAFT
PENDING_CONFIRMATION
ACTIVE
SUSPENDED
AMENDED
CANCELLED
EXPIRED
Every collection checks state/effective date.
Do not simply store:
active=true
with no history.
Mandate versioning
Example:
- Version 1: bank account A;
- Version 2: account B effective October 1;
- Version 1 remains historical.
If September debit is disputed, the system can prove which mandate version applied.
Notice evidence
For a variable utility bill, evidence might contain:
BillId: INV-882
Amount: 169.25
NoticeGenerated: 2026-09-01
DeliveryChannel: e-bill
DebitDate: 2026-09-18
AgreementVersion: PAD-44-v3
Do not rely on a generic “notice sent” flag.
Service provider model
A payment service provider may:
- host mandate;
- generate file;
- transmit;
- return data.
Controls:
- utility-payee identity preserved;
- agreement tells customer about arrangement where Rule H1 requires;
- provider cannot silently change amount/account;
- provider activity auditable.
If the provider is a PSP subject to the Retail Payment Activities Act (RPAA), the Bank of Canada’s retail-payments supervision page identifies registration, operational-risk management, incident response, end-user-funds safeguarding and mandatory reporting as PSP responsibilities. Those duties attach by RPAA scope; do not assume that every utility or outsourced biller is a regulated PSP. If the payee FI is a federally regulated financial institution, OSFI’s third-party-risk guideline says the FRFI retains accountability for outsourced activities and third-party data/risk.
Utility billing adjustment after file created
Customer calls before debit:
“Meter reading was wrong.”
Utility corrects bill.
If PAD file not released:
- suppress/change item through controlled regeneration/re-approval.
If already released:
- do not edit historical item;
- decide refund/credit/next bill according to state.
Partial bill dispute
Customer disputes CAD 20 of CAD 169.25.
Whether the utility changes debit depends on:
- billing policy;
- PAD agreement;
- timing.
Payment system should not invent partial amount automatically.
Budget billing
Some utilities smooth payments to fixed monthly amount.
Then:
- bill/consumption and PAD amount may differ intentionally;
- account balance carries variance.
Reconciliation must compare PAD to budget-payment schedule, not monthly consumption invoice only.
Multiple utility services
Customer may have:
One consolidated PAD may cover multiple receivables.
Cash application should allocate transparently.
If return:
- restore all underlying allocations.
Corporate customer PAD
Business PAD agreements may have different terms/recourse from personal PADs.
System should classify:
Do not apply consumer workflow blindly to business account.
Funds Transfer PAD
Rule H1 also covers Funds Transfer PAD categories.
A utility collection should not be mislabeled as funds transfer simply because money moves between accounts.
Correct classification drives recourse/terms.
Validation before bank submission
Utility-side:
- active agreement;
- invoice;
- amount;
- date;
- no duplicate;
- account data.
Bank-side:
- originator entitlement;
- file integrity;
- rules;
- routing;
- risk.
Defense in depth reduces return rate.
Duplicate detection keys
Possible:
- customer ID;
- invoice ID;
- debit date;
- amount;
- file ID.
A customer may legitimately have two invoices same amount.
Therefore duplicate decision should include business identity.
Originator limits
Bank may set:
- daily amount;
- item count;
- return-rate monitoring.
A sudden 10x collection volume may indicate:
- billing event;
- acquisition;
- file duplicate;
- fraud.
Bank can pre-coordinate expected peaks.
ACSS position impact
Large utility collection creates net inflow expectation for payee side and debit position for payor institutions.
Returns later alter position.
Treasury/reconciliation need:
- gross debit population;
- returns;
- net cash.
Customer available balance
At payor bank:
- PAD debit reduces account balance if posted.
If insufficient:
- item returned according to rules/process.
The utility should not assume a bank will create overdraft unless customer account/product permits.
NSF operational decision
After first NSF, utility has choices:
- re-present once under rule conditions;
- request alternate payment;
- defer to next bill;
- collections process.
The payment rule permits a specific re-presentment; it does not force the utility to use it.
Re-presentment control
System should enforce:
Original returned reason = NSF/eligible
Attempt count = 1
Second attempt date <= rule window
Second amount = original amount
If amount changes:
- treat as new debit with applicable authorization/notice.
NSF fee
If utility charges customer an NSF fee under contract/law:
- it is not automatically part of same re-presented PAD.
This prevents rule violation where “same debit” must remain exact amount.
Return-rate analytics
Monitor by:
- reason;
- customer segment;
- billing cycle;
- bank;
- amount;
- mandate age.
High unauthorized-return rate can indicate mandate defects.
High NSF can indicate customer affordability pattern but should not trigger unfair automated treatment without appropriate policy.
Customer reimbursement workflow
Example:
- customer sees CAD 500 debit;
- says authorized maximum was CAD 150;
- contacts FI;
- FI follows Rule H1 claim process;
- customer reimbursed if requirements met;
- inter-member/payee recovery follows;
- utility receivable restored/investigated.
The utility should not leave invoice “paid” after recovered debit is removed.
Customer dispute evidence pack
Utility should produce:
- agreement;
- version;
- notice;
- bill;
- debit record;
- cancellation history;
- customer communications.
Bank should preserve:
- statement debit;
- claim;
- reimbursement;
- return/recovery.
Cancellation timing matrix
| State | Operational treatment |
|---|
| mandate active, future debit not built | stop future collection |
| file built, not released | suppress item if controlled |
| released, not posted | depends on processing state |
| debit posted | cancellation prevents future, current may need dispute/refund |
| mandate cancelled | no new debits should be created |
Cancellation after service termination
Customer moves house.
Processes:
- final bill;
- final authorized PAD if agreement supports;
- service termination;
- mandate cancellation.
Do not let billing and mandate effective dates drift.
Refunds
If utility owes customer money:
- refund is a credit payment;
- not a negative PAD.
Use bank's supported credit/refund rail.
This preserves payment semantics.
Cash application architecture
A utility cash application service needs:
BankTransactionId
CustomerAccountId
InvoiceId
Amount
PaymentMethod=PAD
DebitDate
ReturnStatus
AppliedAmount
UnappliedAmount
If return:
- reverse cash application through a linked event.
Unapplied cash
Possible when:
- reference missing;
- customer closed utility account;
- amount cannot map.
Use controlled suspense/unapplied cash queue.
Do not apply to “closest” customer based only on name.
Dunning interaction
Collections/dunning process should consume payment state.
If PAD submitted but not yet final:
- avoid premature late notice.
If returned:
- open receivable;
- customer notification.
Service disconnection
Utility disconnection is governed by utility/regulatory/customer policy, not Payments Canada payment rules.
Payment chapter should not infer disconnect timing from PAD return.
Accounting example
Invoice:
Accounts receivable +169.25
Revenue/tax etc per utility accounting
PAD success:
Cash/bank +169.25
Accounts receivable -169.25
PAD return:
Accounts receivable +169.25
Cash/bank -169.25
Illustrative only.
Bank accounting example
Payee FI:
- credits utility under account/product model;
- settlement/clearing;
- return debit when applicable.
Payor FI:
- customer debit;
- clearing position;
- return/reimbursement.
Exact GL varies.
Reconciliation equation
At utility:
Opening receivable
+ new bills
- successful cash applications
+ returned PADs
- adjustments/credits
= closing receivable
At bank:
accepted debit items
↔ clearing/exchange
↔ settlement
↔ customer/payee ledger
↔ returns
Break examples
- bank says accepted, utility missing cash;
- utility applied payment, bank item returned;
- customer reimbursed, utility still paid;
- duplicate file;
- return unmatched.
Each needs owner.
Customer reporting
Utility portal should show:
- bill;
- scheduled PAD;
- paid;
- returned;
- payment required.
Do not show “paid” permanently if PAD later returns.
Bank statement reference
Customer should recognize:
- utility name;
- amount;
- date.
Clear reference reduces disputes.
Fraud scenario: unauthorized originator
A criminal entity obtains collection capability.
Bank originator controls should detect:
- unusual volumes;
- high return/unauthorized claims;
- suspicious onboarding.
Fraud scenario: compromised utility billing
Attacker increases thousands of bills.
Bank may see unusual amount distribution.
Utility's internal billing controls remain primary.
Fraud scenario: customer account substitution
Attacker changes PAD account to another person's account.
Controls:
- authenticated account change;
- validation;
- mandate amendment evidence.
Operational incident: mandate database outage
Collection engine cannot confirm active agreements.
Safe response:
- do not create debits from stale unknown state unless resilience design explicitly proves data.
Recover:
- restore;
- identify affected population;
- reconcile.
Operational incident: cancellation feed delayed
Customer cancellations exist in CRM but not collection engine.
Risk:
- unauthorized post-cancellation debits.
Control:
- event integration monitoring;
- cutoff reconciliation between CRM mandate state and collection population.
BA requirements: mandate domain
Document:
- agreement types;
- required fields;
- versioning;
- notice;
- cancellation;
- recourse;
- PSP relationship.
BA requirements: payment domain
Document:
- file format;
- bank cutoffs;
- states;
- returns;
- retry eligibility;
- reporting.
BA requirements: receivables domain
Document:
- cash application;
- unapplied;
- return restoration;
- customer portal.
Developer controls
- effective-dated mandate;
- immutable agreement versions;
- idempotent debit creation;
- duplicate prevention;
- precise decimal money;
- reliable event delivery;
- return matching;
- audit.
Tester matrix
| Test | Expected |
|---|
| active variable mandate | debit created correctly |
| cancelled mandate | no new debit |
| notice missing | hold/reject per rule/product |
| duplicate invoice | one debit |
| NSF | return matched |
| valid one-time re-present | accepted |
| changed amount re-present | blocked as same-debit retry |
| second retry after re-present | blocked |
| unauthorized claim | dispute workflow |
| refund needed | credit/refund process, not negative PAD |
Performance
Test:
- monthly peak;
- billing cycle concentration;
- returns burst after cycle;
- mass cancellation event.
DR
Restore must preserve:
- mandate versions;
- cancellation timestamps;
- debit attempt count;
- return links.
Losing attempt count can cause prohibited extra re-presentment.
Operations runbook
Before file:
- active mandates;
- notice;
- invoice;
- totals.
After bank:
Customer disputes:
- retrieve evidence;
- coordinate bank.
Month close:
- cash application;
- unapplied;
- returned receivables;
- reconcile.
Final practitioner questions
For any debit complaint:
- Which utility invoice?
- Which PAD agreement version?
- Was agreement active?
- Was notice handled correctly?
- Which debit transaction?
- Did it return?
- Was customer reimbursed?
- Does utility receivable reflect outcome?
- Was mandate cancelled for future debits?
Operating ownership matrix
| Activity | Utility | Utility PSP | Payee FI | Payor FI |
|---|
| Bill amount | owns | may calculate under contract | no | no |
| PAD agreement | owns accountability | may capture/store | relies on originator arrangement | handles customer recourse |
| Debit file | creates/approves | may generate/transmit | validates/processes | receives/posts |
| Customer debit | no direct ledger control | no | sends collection | posts or returns |
| Return | updates receivable | may route data | receives/matches | creates under applicable rules |
| Dispute evidence | provides mandate/bill | provides retained evidence | coordinates originator side | handles payor claim process |
| Cash application | owns | may operate | provides reporting | no |
The table prevents a common design mistake: assuming the bank validates whether the utility bill itself is commercially correct. The payee owns the bill; the bank owns payment processing and rule-based controls.
Mandate evidence versus bank account validation
A valid-looking account number does not prove that the account holder authorized a PAD.
A mandate store must answer:
- who consented;
- to which payee;
- for what type of debit;
- under which terms;
- when;
- whether cancelled.
Account validation answers a different question:
- can the payment be routed/posted?
Both are needed.
Customer onboarding flow
For a new utility customer:
- create utility account;
- choose PAD as payment method;
- present agreement;
- capture consent;
- confirm/store evidence;
- validate account data;
- activate mandate;
- schedule first eligible debit according to agreement/rules.
The first debit should not be created before the mandate is effective.
Paper versus digital agreements
Rule H1 supports agreements through permitted forms/processes. Utilities may use:
- paper (but paper PADs cease to be eligible for Exchange on 1 December 2028 under the current H1 amendment);
- online;
- telephone/electronic processes under applicable requirements.
The evidence model should be channel-neutral.
Paper:
- scanned/signed document;
- date.
Digital:
- authenticated consent;
- terms version;
- timestamp.
Telephone:
- recording/confirmation/evidence as required by process.
Production teams must follow current Rule H1 details for the chosen authorization method.
First debit controls
The first debit is high-risk because:
- new account;
- new mandate;
- data-entry errors.
Monitor:
- first-debit return rate;
- unauthorized claims;
- invalid account.
High first-debit return rate may indicate poor onboarding.
Variable bill controls
Utility bills fluctuate.
A bank should not reject a valid debit simply because it differs from last month.
A utility risk engine can compare:
- historical consumption;
- seasonal range;
- meter read;
- adjustment.
Payment processing should focus on mandate/rule/product limits.
Large adjustment bill
Suppose billing correction produces CAD 2,400 instead of typical CAD 180.
Utility should:
- apply customer-notice/billing policy;
- verify PAD agreement supports amount treatment;
- potentially obtain additional confirmation under its process.
Do not assume a recurring variable mandate automatically makes every amount operationally appropriate.
Negative bill / customer credit
If customer has net credit:
- do not create negative PAD.
Use:
- carry-forward credit;
- refund via supported credit payment method.
Payment data should use correct direction.
Multiple PADs to same customer account
Customer may pay:
- electricity;
- water;
- rental property.
Each debit should carry distinct reference.
Duplicate control should not block two legitimate debits from same originator merely because account/date are same.
File segmentation
A large utility may create files by:
- billing cycle;
- region;
- bank product;
- business/personal PAD.
File segmentation should not lose customer-level identity.
Bank acceptance reports
A bank can return:
- file accepted/rejected;
- item errors;
- scheduled processing.
Utility should not mark invoice paid at file acceptance.
Cash application waits for appropriate bank/settlement outcome.
Settlement timing and receivables
Some utilities may update “payment pending” before final outcome.
Recommended customer-account states:
BILLED
PAD_SCHEDULED
PAD_SUBMITTED
PAYMENT_PENDING
PAID
RETURNED
DISPUTED
The utility portal should avoid showing “paid” permanently before return risk/process is understood.
Return code governance
Maintain a reference table:
ExternalReturnCode
Description
NormalizedReason
RetryEligible?
CustomerMessage
ReceivableAction
Update when Payments Canada standards change.
Retry eligibility engine
For NSF:
- current consumer guidance allows one same-debit retry under conditions.
For other returns:
- do not assume retry is allowed.
The engine should base decision on:
- reason;
- mandate;
- rule;
- attempt history.
Attempt history
Store:
OriginalDebitId
AttemptNumber
AttemptDate
Amount
Outcome
ReturnReason
A DR restore must preserve this history.
Re-presentment example
Original:
- Sept 10;
- CAD 169.25;
- NSF.
Second:
If second returns NSF:
- no third “same debit” re-presentment under the cited consumer guide rule.
Utility may pursue other collection methods.
Customer payment plan after return
Customer calls:
“I can pay half now.”
That is a new collection arrangement.
Do not convert one returned PAD into two automatic debits unless customer authorizes according to applicable terms.
Business customer dispute
A small-business utility account uses business PAD.
Customer says debit was wrong.
The bank/utility must apply business PAD terms and current Rule H1, not automatically the consumer workflow.
Training and case screens should show PAD category.
Recourse-period implementation
The case system should calculate the period from the debit/withdrawal date and show the PAD category:
- Personal PAD: generally 90 calendar days for the applicable incorrect, unauthorized, cancellation or missing-notice claims;
- Business PAD: generally 10 business days for the corresponding extended-recourse claims;
- Funds Transfer/Cash Management: category-specific exceptions apply, including cases with no extended recourse.
Store debit date, claim date, category, reason and declaration. If outside the rule-based period, the bank may still offer ordinary complaint, legal, goodwill or fraud-investigation routes, but the system must not misstate the H1 recourse period.
Statement evidence
Customer statement is important because it proves:
- debit date;
- amount;
- payee descriptor.
Claim case links statement transaction to mandate.
Refund versus reimbursement
Refund
Utility voluntarily returns money, perhaps billing correction.
Reimbursement
Customer's FI credits under PAD recourse process.
These can lead to same customer balance effect but have different process/ownership.
Preventing double credit
If utility already refunded CAD 169.25 and bank also processes PAD reimbursement:
- duplicate customer benefit risk.
Case management should identify related refund/reimbursement where possible.
Utility collections fraud analytics
Metrics:
- unauthorized claim rate;
- return rate;
- duplicate rate;
- average debit;
- amount spikes;
- new mandates;
- account-change rate.
A sudden unauthorized-claim spike can indicate:
- mandate capture defect;
- originator compromise;
- bad data migration.
Originator monitoring by bank
A bank supporting PAD originators should monitor:
- return rates;
- dispute rates;
- volume growth;
- high-risk changes;
- customer complaints.
This protects both the bank and payment system.
PAD data migration
Utilities replacing billing systems must migrate:
- mandate status;
- agreement version;
- account;
- notice configuration;
- cancellation date;
- attempt history.
A migration that copies only “active mandates” but loses evidence creates future dispute risk.
Migration reconciliation
Before cutover:
Source active mandates = target active mandates
Cancelled mandates remain cancelled
Agreement documents/evidence retained
Upcoming debits match expected billing population
Cutover freeze
During migration:
- freeze mandate changes briefly or dual-write;
- reconcile last changes.
Otherwise customer cancellation may be lost between systems.
API design between billing and collections
Example request:
InvoiceId
CustomerId
MandateId
Amount
DebitDate
Reference
Collection service responds:
- accepted;
- validation error;
- duplicate.
It should not accept a mandate ID that is not active/effective.
Event model
Events:
- MandateActivated;
- MandateAmended;
- MandateCancelled;
- InvoiceIssued;
- PadScheduled;
- PadSubmitted;
- PadReturned;
- CustomerReimbursed.
Event history helps investigations.
Customer communications
Useful messages:
- “Your automatic payment of CAD 169.25 is scheduled for Sept 18.”
- “Your automatic payment was returned. Your balance remains due.”
- “Your PAD agreement has been cancelled; future bills require another payment method.”
Avoid:
- “Your utility account is cancelled” when only PAD cancelled.
Dunning guardrail
Before collections/dunning:
- check PAD in-flight;
- check recent return;
- check dispute;
- check reimbursement.
Do not send overdue warning while a valid payment is still pending under bank timing.
Complaint handling
A PAD dispute may become formal complaint.
Link:
- payment case;
- complaint;
- mandate evidence.
Operational resolution and complaint closure can have different deadlines.
Record retention
Retain mandate/payment evidence per:
- Rule H1;
- applicable law;
- bank/utility policy.
Do not invent retention period if not verified.
Utility implementation test: cancellation race
Timeline:
- 09:00 customer cancels;
- 09:05 billing batch starts;
- 09:10 collection engine builds file.
Expected:
- cancellation event visible;
- debit excluded.
If the file snapshot was legally/operationally finalized before cancellation:
- product process must define handling.
Test exact boundaries.
Utility implementation test: duplicate billing run
Billing job accidentally reruns.
Second run creates same InvoiceIds.
Collection idempotency:
- rejects second debit population.
Utility implementation test: return feed replay
Return feed delivered twice.
Cash application:
Utility implementation test: customer changes bank
New account effective next month.
Current month's debit:
- old account if agreement/effective dates say so.
Next:
No ambiguous overwrite.
Utility implementation test: one-time PAD
One-time mandate:
- debit successfully processed;
- mandate cannot silently generate second monthly debit.
Utility implementation test: sporadic authorization
Each debit must have required payer authorization under rule.
No schedule based only on old permission.
Operations dashboard
Show:
- scheduled debits;
- submitted;
- returns by reason;
- disputes;
- reimbursed;
- re-presentments used;
- cancellations;
- unapplied cash.
Reconciliation close
Month close:
- invoice population;
- successful PAD cash;
- returns;
- refunds;
- reimbursements;
- unapplied;
- closing A/R.
The collection story is finished only when bank cash and utility receivables agree.
PAD operations ownership at scale
A large utility collection programme needs clear ownership because a customer complaint can cross four organizations.
Utility billing team
- invoice correctness;
- meter/rate calculation;
- bill adjustment.
Utility payments team
- mandate status;
- debit scheduling;
- bank file;
- return processing;
- cash application.
Payee financial institution
- originator service;
- file/payment processing;
- rule-based collection handling;
- return reporting.
Payor financial institution
- customer account debit;
- return;
- Rule H1 customer claim/reimbursement process.
Payments Canada
- rulebook/system framework, not the customer's dispute desk.
This ownership prevents a bank from being asked to decide whether the customer's electricity usage was correct and prevents the utility from deciding a bank-account reimbursement claim on behalf of the payor FI.
Utility customer journey from signup to cancellation
A realistic journey is:
- customer opens utility account;
- selects PAD;
- utility captures agreement;
- first bill issued;
- notice/confirmation process applied;
- debit scheduled;
- customer account debited;
- utility receives cash;
- next bill repeats;
- customer later cancels PAD;
- utility switches payment method while service contract continues.
Every step should leave evidence.
Mandate/account validation controls
Utilities may use bank-account validation tools depending on bank/product.
Validation can help confirm:
- account/routing format;
- institution reachability.
It does not replace the payor's authorization.
A system should never mark a mandate as valid merely because an account number is syntactically valid.
Account ownership risk
A customer may accidentally provide:
- spouse's account;
- old account;
- business account.
The utility should follow its onboarding process and Rule H1 requirements for the payor/account relationship.
A bank should not invent ownership verification it does not actually perform.
Effective dating in detail
A mandate record can include:
validFrom
validTo
accountVersion
agreementVersion
cancellationReceivedAt
cancellationEffectiveAt
When a debit is generated, the collection engine stores which version was used.
Later dispute:
Scheduling engine
Inputs:
- invoice due date;
- active mandate;
- notice status;
- business calendar;
- utility policy.
Outputs:
- planned debit date;
- collection batch.
Do not let individual application jobs calculate dates differently.
Billing-cycle changes
A customer changes billing date from 15th to 28th.
The utility should:
- update billing schedule;
- update next PAD date;
- apply notice/agreement requirements as needed;
- prevent both old and new debit from being generated.
Customer changes payment method
PAD to card/manual.
Controls:
- cancel mandate/future debits;
- preserve old mandate evidence;
- clear scheduled but unreleased collections where applicable;
- communicate.
Reinstating PAD
A previously cancelled mandate should not necessarily be reopened by simply toggling a flag.
Obtain the required new or renewed authorization under product/rule procedure.
Closed utility account
Customer moves.
Final bill:
- may use valid existing PAD if terms/rules permit;
- or alternate payment.
After final collection:
- mandate cancelled/expired;
- no future debits.
Deceased customer / estate
A utility account can continue temporarily under estate arrangements.
Mandate authority may change.
Route to legal/customer-service procedure rather than automatically continue a previous customer's authorization indefinitely.
Bank-account closure return
Payor account closed.
Payor FI returns item.
Utility:
- restores receivable;
- flags mandate/account data;
- asks customer for a new payment method.
Do not keep re-presenting to a closed account.
Invalid account-number return
This is typically a data problem rather than insufficient funds.
Action:
- correct mandate/account data through authorized process;
- do not retry the same invalid data.
Duplicate debit customer complaint
Customer sees two identical utility debits.
Investigation compares:
- invoice IDs;
- debit transaction IDs;
- utility collection file IDs;
- bank postings.
Possible:
- utility generated twice;
- bank duplicated;
- two legitimate utility accounts.
Do not assume the two debits are duplicates simply because amount/date match.
Incorrect amount complaint
Customer says:
“Bill was CAD 169.25, debit was CAD 196.25.”
Evidence:
- invoice;
- mandate;
- submitted debit;
- bank statement.
If the utility file amount itself was wrong:
If statement display is wrong but actual debit right:
Unauthorized debit complaint
Customer says:
“I never authorized this utility.”
The payor FI's Rule H1 process is primary.
The utility should be able to produce:
- agreement;
- confirmation;
- account;
- date.
The utility should not pressure the customer to withdraw a legitimate claim merely because its billing system shows a balance.
Complaint outside the Rule H1 period
The cited consumer guide's 90-day route is for the applicable Personal PAD recourse claims. Business PADs generally use the 10-business-day H1 period, and Funds Transfer or Cash Management PADs have category-specific exceptions. If a customer complains later, the bank or utility may still have ordinary complaint, legal, goodwill or fraud-investigation routes depending on the circumstances. Do not falsely say “nothing can be done” merely because the specific rule-based reimbursement window is exceeded.
Return versus chargeback language
PAD returns and reimbursements should not be called card chargebacks.
Different rails have different rights and processes.
Using the wrong term confuses operations and customers.
Customer communication after NSF
A useful message can say:
- debit returned for insufficient funds;
- outstanding utility balance;
- whether or when the utility plans to re-present;
- alternate payment options.
If the utility intends the one allowed same-debit re-presentment, tell the customer clearly.
Avoiding surprise re-presentment
Even when permitted, customer experience improves if the utility communicates the exact amount and planned date.
This can reduce a second NSF and support fair customer treatment.
Re-presentment and bank fees
The customer's bank may apply account fees according to its account terms for NSF activity.
The utility should not assume or promise the bank's fee outcome.
Collection portfolio analytics
A utility can segment:
- successful first-time debits;
- NSF;
- account closed;
- unauthorized claims;
- duplicate;
- re-present success.
This helps customer service, payment-method strategy, fraud and operational quality.
Return-rate root-cause example
Return rate rises from 2% to 8% after a new billing-system release.
Analysis shows transit numbers lost leading zeros.
This is not a customer-affordability problem.
Immediate response:
- stop affected population;
- repair mapping;
- customer remediation.
Originator-bank risk management
The payee FI can use return and dispute trends to manage originator risk.
High unauthorized claims can trigger:
- investigation;
- limits;
- enhanced monitoring;
- originator remediation.
The exact commercial/risk response is bank-specific.
Utility PSP oversight
If a third-party processor sends on behalf of the utility:
- contract;
- security;
- reconciliation;
- incident notification;
- audit rights;
- exit plan.
Outsourcing file creation does not remove utility responsibility for accurate bills and mandates.
Third-party outage
A PSP outage occurs before file transmission.
The utility should know:
- which files were built;
- which were transmitted;
- which were acknowledged.
After restore:
- do not resend files of unknown state until the bank state is confirmed.
Cash-application break scenario
Bank report says CAD 169.25 was collected.
The utility cannot match the reference.
Actions:
- hold as unapplied;
- search invoice/customer;
- do not mark an arbitrary account paid.
If unresolved:
Reimbursement reconciliation
When the payor FI reimburses, the utility/payee side may later see a return or adjustment.
The utility must restore the receivable exactly once.
If it already manually refunded the customer:
- investigate potential double financial adjustment.
Month-end example
Opening A/R: CAD 40m
New bills: CAD 30m
PAD cash: CAD 24m
Other payments: CAD 4m
PAD returns: CAD 0.7m
Credits: CAD 0.3m
Closing receivable must reconcile under the utility's accounting policy.
Payment operations supplies trustworthy PAD populations.
Bank reconciliation control
For a collection batch:
submitted count/value
= accepted + rejected
Then:
accepted population
↔ clearing/exchange
Then:
settlement / customer-payee account
↔ returns
Any unmatched returned debit remains a break.
Operational sign-off
At cycle close:
- all expected bank reports received;
- no missing files;
- returns loaded;
- cash applied;
- unapplied reviewed;
- high-value disputes flagged;
- mandate cancellation feed healthy.
PAD migration acceptance criteria
If the utility moves to a new platform:
- all active agreements copied;
- cancelled agreements remain cancelled;
- agreement versions accessible;
- future debit schedules identical;
- prior attempt counts preserved;
- return links preserved;
- no duplicate file sent at cutover.
PAD security controls
Sensitive information includes:
- customer account;
- agreement;
- billing.
Controls:
- encryption;
- least privilege;
- privileged-access logging;
- no production account data in unsecured test environments.
Masked testing
Use synthetic or masked account data.
Test routing rules in an approved test environment.
Do not copy full customer bank details to developer laptops.
Monitoring integrations
Alert when:
- mandate cancellation events stop flowing;
- billing file count deviates materially;
- bank acknowledgements are delayed;
- return feed is missing;
- cash-application backlog grows.
Customer-harm indicators
Monitor:
- duplicate debits;
- debit after cancellation;
- wrong amount;
- repeated NSF re-presentment beyond policy;
- delayed reimbursement.
These are more meaningful than system uptime alone.
Final utility incident scenario
A release defect causes 5,000 cancelled mandates to remain active in a collection cache.
Before bank submission, a reconciliation compares:
- CRM cancelled population;
- collection file.
The mismatch triggers a hold.
No unauthorized debits occur.
The control succeeds because mandate state is reconciled to the outgoing payment population before the bank sees it.
That is the essence of PAD control: authorization evidence must drive every debit, not merely exist somewhere in an archive.
Final bank-readiness review for PAD collections
Before launching or migrating a PAD collection service, verify:
- mandate types and Rule H1 treatment are documented;
- every debit references the applicable mandate version;
- cancellation effective dates are enforced before file creation;
- variable-amount notice logic is tested;
- duplicate invoice/debit prevention is idempotent;
- NSF re-presentment counts and amount rules are enforced;
- return reasons drive the correct receivable action;
- incorrect/unauthorized claim evidence can be retrieved;
- customer reimbursement cannot create duplicate utility refunds;
- cash application and bank settlement reconcile;
- DR preserves mandate, cancellation and attempt history.
PAD customer-harm scenario: stale cancellation cache
A customer cancels PAD on Monday. The collection engine holds a Sunday snapshot and tries to create Friday's debit.
A robust design checks the authoritative mandate state again before release or consumes the cancellation event reliably. The debit is excluded.
This scenario shows why authorization cannot be treated as static master data. It is effective-dated payment authority.
PAD customer-harm scenario: same debit plus fee
The original CAD 169.25 debit is returned NSF. The utility wants to recover CAD 25 NSF fee as well.
The current consumer guidance permits one re-presentment of the same debit within the stated conditions, which means the re-presented debit remains CAD 169.25. Any additional utility fee requires its own lawful/contractual payment treatment and must not be hidden inside the “same debit.”
PAD quality gate
At the end of a billing cycle the utility and its bank should be able to explain:
- how many mandates were eligible;
- how many debits were submitted;
- how many were rejected before processing;
- how many returned and why;
- which were re-presented;
- which customers were reimbursed;
- whether utility receivables and bank cash agree.
If those numbers cannot be reconciled at customer level, the collection cycle is not truly closed.
Practical production acceptance workshop
Take one variable utility bill and trace it through every system.
The utility should show:
- service contract;
- invoice;
- active mandate version;
- notice evidence;
- scheduled debit.
The bank should show:
- collection instruction;
- AFT/clearing state;
- customer-account debit or return.
The utility should then show:
- cash application;
- receivable balance.
Next, simulate an NSF return and verify:
- receivable reopens;
- one same-amount re-presentment is controlled under the cited rule conditions;
- a second failed re-presentment does not generate another automatic same-debit retry.
Finally simulate customer cancellation before the next cycle and prove the debit population excludes the cancelled mandate.
PAD handover documentation
A production runbook should include:
- Rule H1 source;
- mandate types;
- notice handling;
- cancellation effective dating;
- file states;
- return reasons;
- NSF re-presentment logic;
- dispute/reimbursement routing;
- cash application;
- reconciliation;
- incident contacts.
Final learning check
Remember:
- utility debt and PAD authorization are separate;
- every debit needs applicable authorization evidence;
- NSF re-presentment is tightly controlled, not a generic retry loop;
- cancellation stops future PAD authority but does not erase the underlying bill;
- the cycle closes only when bank cash, returns and utility receivables reconcile.
12. Testing, takeaways and authoritative references
Functional tests
- recurring fixed PAD;
- recurring variable PAD;
- sporadic PAD authorization;
- one-time PAD;
- account change;
- cancellation;
- duplicate;
- NSF return;
- one permitted re-presentment;
- attempted third presentment;
- amount changed on re-presentment;
- unauthorized debit claim;
- debit after cancellation.
Mandate tests
- missing evidence;
- expired/cancelled agreement;
- wrong customer;
- terms version;
- effective-date overlap;
- provider arrangement.
Payment tests
- invalid routing;
- closed account;
- duplicate file;
- file-control mismatch;
- return matching.
Reconciliation tests
- accepted less rejected;
- returns;
- customer reimbursement;
- utility receivable;
- bank statement.
Resilience tests
- mandate service down;
- billing file replay;
- bank acknowledgement lost;
- return feed delayed;
- DR with cancellation records.
Final takeaways
A PAD collection is safe only when the bank and utility can prove:
- valid authorization;
- correct bill;
- correct debit;
- correct settlement/cash application;
- correct handling of returns and disputes.
The most important practical distinction is:
The payment method can be cancelled or reimbursed without erasing the underlying utility debt or contract.
Authoritative references
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.