Posting, Accounting and Statements. Translate payment events into customer accounts, internal ledgers, settlement accounts, fees, statements and reporting.
Block 14 · Chapter 69 of 75
A payment is not finished when a message is sent.
The customer account must be debited or credited. Internal control accounts must reflect the payment state. External settlement must be represented correctly. Fees and foreign exchange may create separate entries. Returns and reversals must correct the books without erasing history. Statements and corporate reports must tell the customer what actually happened. Reconciliation must prove that all of those views describe the same economic event.
This is where payment processing becomes accounting.
A useful rule is:
Every financial event should produce an explainable accounting event, and every customer-visible entry should be traceable back to the payment event that justified it.
This chapter explains the operating relationship among payment events, customer posting, internal ledgers, settlement accounts, suspense, fees, FX, statements, returns and reconciliation. Accounting examples are deliberately illustrative and fictional unless a paragraph identifies a regulatory, Payments Canada or Interac rule. Bank implementation choices are labelled as such. Banks use different charts of accounts, ledger platforms and booking models. The chapter explains the control logic, not a universal journal-entry standard.
Status note (checked 2026-10-05): Lynx and ACSS are current production systems. The Real-Time Rail (RTR) is not yet a production rail on this review date: Payments Canada says it is launching in Q4 2026 and that industry solution-assurance testing is under way. RTR statements below are therefore clearly marked as planned or as implementation design implications, not as current production capability or final operating rules.
What you should be able to do after this chapter
After working through this chapter, you should be able to:
- distinguish payment state from accounting state;
- explain customer ledger, settlement ledger and general ledger roles;
- separate authorization/reservation from actual posting;
- understand why batch-clearing positions and RTGS settlement produce different accounting evidence;
- explain the role of Bank of Canada settlement accounts for direct participants in Lynx and ACSS;
- describe how a settled Lynx payment should connect to customer booking and statement evidence;
- explain why a return is normally booked as a new corrective event;
- distinguish suspense from a final accounting destination;
- treat fees and FX as related but separately controlled events;
- use camt.053 and other reports as evidence without assuming every bank exposes identical statements;
- explain customer value date, booking date and statement date;
- design accounting idempotency and duplicate-posting controls;
- reconcile instruction, settlement, customer posting and GL;
- test end-of-day, weekend, return, duplicate and failure scenarios.
Chapter navigator
- From payment event to accounting event
- The ledger layers
- Customer debit and credit posting
- Settlement accounting across Canadian rails
- Fees, FX and ancillary postings
- Suspense and exception accounting
- Returns, reversals and corrective entries
- Statements and customer reporting
- General ledger and financial control
- Reconciliation and accounting closure
- Practical booking scenarios
- Implementation, testing and authoritative references
1. From payment event to accounting event
Payment systems and accounting systems answer different questions.
Payment system:
- Who pays whom?
- Through which rail?
- What is the payment status?
- Was it accepted?
- Did it settle?
- Was it returned?
Accounting system:
- Which account owns the value?
- What asset/liability changed?
- Which business date?
- Is the entry final or provisional?
- Which GL account balances it?
- How is it reported?
The two views must remain connected.
Example
Customer sends CAD 25,000 domestic wire.
Payment lifecycle:
- customer authorizes;
- bank validates;
- bank releases Lynx payment;
- Lynx settles;
- receiving bank credits beneficiary.
Accounting lifecycle at sending bank might include:
- reserve/earmark customer funds;
- debit customer deposit account;
- reduce settlement-account asset or recognize settlement outflow;
- book fee;
- update payment/settlement control accounts;
- report statement entry.
The exact debit/credit accounts depend on bank accounting design. The control principle does not.
Financial event boundary
An event should have:
- event ID;
- payment ID;
- amount/currency;
- accounting date;
- value date if relevant;
- posting template;
- status;
- ledger reference.
This prevents an application from posting by free-form instructions.
Payment status is not ledger status
A payment can be:
- externally settled;
- but customer posting pending.
Or:
- customer account debited;
- but external payment not yet released.
Those are different risk states and must be monitored.
2. The ledger layers
A large bank may have several ledger layers.
The accounts-touched diagram above maps each ledger layer below to the payment events that hit it; suspense is a corridor to age daily, never a home.
Customer subledger
Holds customer balances and entries.
Examples:
- chequing account;
- savings;
- corporate operating account.
This is what drives available/book balance and statements.
Payment operational ledger
Some payment hubs maintain an operational financial view:
- reserved;
- pending;
- settled;
- returned;
- fee;
- FX.
This is not necessarily the official GL.
Settlement account
Direct participants hold settlement accounts at the Bank of Canada for relevant Payments Canada systems.
The Bank of Canada’s settlement-account policy, last updated July 31, 2026, explains that it provides settlement accounts to:
- direct participants in Lynx;
- direct clearers in ACSS;
- direct participants in the planned RTR.
Payments Canada owns and operates the systems; final settlement occurs through accounts on the books of the Bank of Canada.
That distinction is fundamental.
General ledger
The GL records the bank’s financial position.
Payment activity can affect:
- customer deposit liabilities;
- cash/settlement assets;
- interbank receivables/payables;
- fee income;
- FX positions;
- suspense;
- provisions/write-offs.
Correspondent/nostro ledger
Cross-border payments may use correspondent accounts.
A SWIFT message can instruct a payment while the financial movement is represented by debits/credits on correspondent accounts.
Message delivery is not itself the accounting settlement.
Control accounts
Control accounts bridge systems.
Examples:
- payments pending settlement;
- outbound settlement control;
- inbound unapplied;
- returned payments;
- fee receivable.
Every control account needs a reconciliation owner.
3. Customer debit and credit posting
Customer posting rules should be event-driven.
Outbound payment
Possible sequence:
- check available balance;
- reserve amount;
- authorize payment;
- debit account;
- release externally;
- confirm settlement;
- convert reservation to final posting.
Banks choose different points for final debit.
The important control is that the ledger and payment state cannot contradict each other for long.
Available balance versus book balance
A reservation can reduce available funds before final booking.
Example:
- Book balance: CAD 20,000
- Payment reservation: CAD 5,000
- Available balance: CAD 15,000
If payment fails before release:
- release reservation;
- do not create false final debit.
Inbound credit
Possible sequence:
- bank receives payment;
- validates beneficiary account;
- confirms settlement/funds-availability condition;
- credits customer;
- sends notification/report.
For continuous/instant payment, these steps must happen quickly and reliably.
Posting idempotency
If the same settlement event is delivered twice, customer should not be credited twice.
Use an idempotency key such as:
- payment ID + event type;
- external transaction ID;
- settlement reference.
Ledger service records:
eventKey = LYNX_SETTLED:<paymentId>
posted = true
ledgerReference = 123456
Retry returns the same result.
Posting failure
If settlement succeeds but customer posting fails:
- payment is not failed;
- create posting exception;
- retry idempotently;
- hold in control/suspense as needed;
- alert operations;
- reconcile.
This distinction prevents duplicate external payment.
4. Settlement accounting across Canadian rails
Different rails produce different settlement evidence.
Lynx
Lynx is Canada’s production real-time gross settlement (RTGS) wire system. Payments Canada describes Lynx payments as fast, irrevocable and settled with real-time settlement finality.
Each payment settlement changes participant positions in central bank money according to the Lynx framework.
The Bank of Canada settlement-account policy and Payments Canada Lynx rules are authoritative.
Operational accounting should connect:
- original payment;
- Lynx settlement;
- customer debit/credit;
- settlement account movement;
- GL.
Payments Canada’s current Lynx ISO 20022 resource page lists the UG2026 core messages—pacs.008, pacs.009 core/cov and pacs.004—and the UG2025 reporting message camt.053. It also publishes corporate-to-bank guidance for pain.001, pain.002, camt.052, camt.053 and camt.054. These are message specifications and implementation guidance, not a universal customer-ledger posting policy.
ACSS
ACSS is Canada’s production retail batch clearing and settlement system. Payments Canada says direct clearers enter exchanged item totals and the system calculates net balances; settlement of the previous business day’s net balances occurs during the morning of each business day through Bank of Canada settlement accounts.
Individual AFT items contribute to clearing positions; settlement occurs on net obligations between direct clearers. The Bank of Canada’s access policy states that ACSS settlement-account holders meet those net obligations by Lynx payments; an ACSS applicant that is not a direct Lynx participant must arrange for a direct Lynx participant to perform that settlement.
This means accounting has two levels:
- item/customer postings;
- participant net settlement.
Reconciliation joins them.
A bank should not expect one Bank of Canada settlement debit per payroll item.
Indirect clearer
An indirect participant may settle through a direct/group clearer.
Its financial relationship is with the sponsor/group clearer under that arrangement.
Accounting must distinguish:
- customer item;
- sponsor position;
- sponsor settlement report;
- indirect’s own GL.
Interac
Interac services have their own operating arrangements and participant relationships. The Bank of Canada lists Interac e-Transfer and Interac’s Inter-Member Network among the payment systems it oversees; ACSS also clears electronic items such as Interac debit payments. A particular Interac product’s customer posting and settlement path must therefore be identified rather than inferred from the brand name.
From a bank accounting perspective, the design should still identify:
- customer debit/credit;
- network/settlement evidence;
- fees;
- exceptions;
- reconciliation.
Do not assume an Interac notification message is settlement evidence.
RTR planned model
As of 2026-10-05, RTR is planned rather than a current production rail. Payments Canada’s current system page says RTR is launching in Q4 2026 and that industry solution-assurance testing with participants is under way. The Bank of Canada has published a settlement-account access policy for the planned RTR.
The following are implementation design implications for a bank preparing for the target service, not published RTR production rules:
Continuous real-time settlement requires:
- real-time posting;
- continuous settlement ledger integration;
- 24/7 reconciliation/monitoring;
- accounting-date rollover without stopping payments.
The bank cannot rely on one nightly posting batch for a customer promise that is real time.
5. Fees, FX and ancillary postings
A payment amount is not always the only financial event.
Fees
Examples:
- wire fee;
- service-plan fee;
- urgent-payment fee;
- return fee where permitted/product applicable;
- correspondent charges.
Fee booking should carry:
- payment ID;
- fee type;
- amount;
- tax treatment if applicable;
- customer disclosure reference;
- reversal/refund rule.
Fee timing
Possible:
- at initiation;
- at release;
- on completion;
- monthly aggregation.
If payment fails, fee treatment must follow product terms.
Do not automatically reverse every fee when payment returns.
Foreign exchange
Cross-border payment may require FX.
Separate events:
- FX trade/rate;
- customer currency debit;
- payment-currency amount;
- correspondent settlement;
- charges;
- return/recovery FX.
A returned foreign-currency payment can create FX differences.
Example:
- Customer buys USD 10,000 at rate R1.
- Payment returns later.
- Bank converts USD back to CAD at R2 under product terms.
The return amount in CAD may differ from original debit.
Accounting and customer communication must explain why.
Charges in messages
Payment messages may include charge information.
Accounting still needs product-level rules:
- who bears charges;
- what bank charges customer;
- what intermediary deducts;
- what can be refunded.
6. Suspense and exception accounting
Suspense is necessary because real systems fail asynchronously.
It is dangerous when treated as permanent storage.
When suspense is appropriate
Examples:
- inbound settlement cannot be matched to customer;
- return received for closed account;
- posting service unavailable after settlement;
- amount/reference mismatch;
- manual investigation pending.
Suspense record
Should contain:
- suspense item ID;
- payment ID/reference;
- amount/currency;
- source;
- date;
- reason;
- owner;
- age;
- expected destination;
- case ID.
Ageing
Suggested operational buckets:
- same day;
- 1 business day;
- 2–5 days;
-
5 days.
The exact SLA is bank-specific.
What matters:
- old items escalate;
- high-value items escalate faster;
- fraud/compliance items follow specialist policy.
Unidentified incoming funds
Never force-post to a likely customer based on amount/name only.
Obtain sufficient evidence.
Suspense clearing
Clearing entry should reference:
- original suspense;
- destination account;
- investigator/approval;
- reason;
- case.
No manual journal should hide the original source.
7. Returns, reversals and corrective entries
Chapter 67 separated the concepts. Accounting implements them.
Return
Original:
Customer debit 10,000
Settlement outflow 10,000
Later return:
Settlement inflow 10,000
Customer credit 10,000
Conceptually two events.
Reversal
If an internal duplicate debit occurs:
Duplicate debit -10,000
Corrective reversal +10,000
External settlement may remain only once.
Recall request
No financial posting merely because recall request was sent.
Possible postings:
- case exposure/provision in separate risk system;
- no customer balance change;
- actual posting only when bank decides reimbursement or funds recover.
Customer provisional credit
Fraud/dispute policy may give provisional credit.
Record separately from recovery.
If later recovery arrives:
- do not credit customer twice;
- clear bank receivable/exposure.
Partial return
Support partial amount where applicable.
One original payment can have:
- multiple corrective entries.
Data model must not assume one return = full amount.
8. Statements and customer reporting
Statements are accounting outputs and payment evidence.
Statement line
Useful fields:
- booking date;
- value date;
- amount/currency;
- debit/credit indicator;
- transaction description;
- customer reference;
- bank reference;
- counterparty;
- fees where shown.
Statement date versus value date
Booking date:
when entry posted.
Value date:
economic date used under product/accounting rules.
They may differ.
Do not use one field to mean both.
camt.053
Payments Canada publishes a Lynx bank-to-customer statement specification for camt.053 (listed as a UG2025 reporting message on its current resource page). That specification applies to the Lynx context; it does not require every bank or customer channel to expose camt.053.
ISO 20022 statements can carry richer structured data, but:
- banks still choose customer implementation;
- not every customer consumes camt.053;
- a message standard does not define the bank’s full product statement policy.
Corporate reporting
Corporates need:
- payment status;
- debit/credit reporting;
- remittance;
- returns;
- bank charges.
Cash application depends on stable references.
Status versus statement
A status message says what payment process reports.
A statement says what account was booked.
They should agree but serve different purposes.
Example:
- payment status: RETURNED
- statement: original debit + returned credit
Do not delete original statement line.
Customer-readable descriptions
Raw technical reason codes should be translated.
But preserve original code for operations.
9. General ledger and financial control
Payment applications should not post uncontrolled GL entries.
Posting templates
Define templates for:
- outbound payment;
- inbound payment;
- fee;
- return;
- suspense;
- reversal;
- FX.
Each template has:
- allowed event;
- accounts;
- debit/credit logic;
- currency;
- balancing control;
- approval/version.
Balanced entry
Every journal must balance.
A distributed payment can have asynchronous subledger events, but financial control must prove final balance.
Business date close
Before closing payment-related GL:
- all settlement reports received;
- expected interface batches complete;
- suspense reviewed;
- unreconciled breaks recorded;
- high-value exceptions escalated;
- late returns accounted.
24/7 rails complicate “end of day.”
The bank may need:
- rolling operational reconciliation;
- accounting snapshots;
- continuous postings crossing midnight.
Manual journals
Manual payment journals are high-risk.
Controls:
- restricted roles;
- maker-checker;
- case/reference mandatory;
- amount limits;
- no free-form settlement account changes;
- monitoring;
- daily review.
Financial reporting
Payment balances feed:
- cash;
- deposits;
- fee income;
- FX;
- receivables/payables.
Operational misclassification can become financial-reporting error.
10. Reconciliation and accounting closure
Reconciliation is the proof that accounting reflects payment reality.
Four-way reconciliation
- customer instructions;
- external payment/clearing evidence;
- settlement evidence;
- ledger/GL.
Add:
5. return/corrective events;
6. statements/reports.
Example: Lynx outgoing
Expected:
- one customer debit;
- one Lynx settled payment;
- one settlement-account outflow;
- one GL booking;
- fee booking if applicable.
Break examples:
- customer debit but no settlement;
- settlement but no customer debit;
- two customer debits, one settlement;
- settlement amount differs;
- fee missing.
Example: AFT payroll
Reconcile:
- file control total;
- accepted items;
- clearing/exchange;
- settlement position;
- employee/customer postings;
- returns.
Item total and net settlement are different layers.
Reconciliation timing
High-value:
near-real-time/intraday checks important.
Batch:
cycle/day-based controls.
Real time:
continuous monitoring plus accounting period closure.
Break ownership
Each break needs:
- category;
- amount;
- age;
- owner;
- root cause;
- expected action.
Close criteria
Do not close because totals match if identities do not.
Two equal but offsetting errors can make total balance while individual customers are wrong.
Match at transaction level where possible.
11. Practical booking scenarios
The following are fictional, illustrative bank-implementation examples, not descriptions of a named bank’s internal process or a scheme-mandated journal-entry sequence.
Scenario A: domestic Lynx payment
Customer instructs CAD 500,000.
Illustrative sending-bank flow:
- reserve funds;
- pass controls;
- debit customer;
- release Lynx payment;
- Lynx settles;
- settlement account evidence received;
- fee posted;
- statement generated;
- reconciliation confirms one-to-one chain.
If Lynx release fails before settlement:
- bank corrects customer reservation/debit under its design;
- no false settlement posting.
Scenario B: AFT payroll with returns
Employer payroll:
- 2,500 items;
- total CAD 4.2 million.
Bank debits employer according to product model.
ACSS processes batch positions.
Three items return.
Accounting:
- original payroll remains;
- three return credits posted separately;
- employer report identifies affected employees;
- GL/reconciliation ties return population.
Do not reverse CAD 4.2 million payroll because three credits returned.
Scenario C: duplicate ledger debit
One Interac payment externally completes.
Customer account debited twice due consumer retries in posting adapter.
Reconciliation:
- external count = 1;
- ledger count = 2.
Action:
- reverse duplicate internal debit;
- incident ticket;
- customer communication;
- no external recall.
Scenario D: incoming payment cannot post
Lynx incoming settles.
Beneficiary account number fails internal mapping.
Action:
- route to controlled suspense;
- investigate;
- do not lose settlement evidence;
- either credit correct beneficiary under policy or return under applicable rules;
- reconcile suspense to final outcome.
Scenario E: cross-border return with FX
Customer sends USD 20,000 funded from CAD.
Payment returns USD 19,950 after charges.
Bank:
- receives return;
- identifies deducted charge;
- applies product FX treatment;
- credits customer;
- reports difference clearly;
- reconciles USD nostro and CAD customer account.
The original payment and return remain visible.
Deeper operating practice: designing a payment accounting model that survives exceptions
Payment accounting becomes robust when every posting answers four questions:
- Which business event caused this entry?
- Which external financial state supports it?
- Which customer/product rule explains it?
- Which independent reconciliation will verify it?
If a posting cannot answer those questions, it is difficult to audit and dangerous to repair.
Event-to-posting catalogue
Banks should maintain a governed catalogue of payment events and allowed accounting actions.
Illustrative examples:
| Payment event | Possible accounting action |
|---|
| Instruction accepted | no posting or reserve funds |
| Authorization completed | maintain reservation |
| External release | convert to pending payment control |
| Settlement confirmed | final customer/settlement booking as designed |
| External reject | release reservation / correct pending entry |
| Return settled | corrective incoming/outgoing posting |
| Fee assessed | separate fee posting |
| Fee refunded | compensating fee entry |
| FX executed | currency-position/customer entries |
| Manual adjustment | controlled journal linked to case |
The word possible matters. The exact booking point is product/bank-specific.
Reservation accounting versus final posting
A reservation reduces spendable balance without necessarily being a booked accounting entry in the same way as final debit.
This helps avoid overdrawing before payment release.
Example:
Book balance: CAD 100,000
Reserved payment: CAD 30,000
Available balance:CAD 70,000
If sanctions review rejects payment:
- reservation released;
- no external settlement;
- no false final debit.
If settlement succeeds:
- reservation is consumed/converted according to ledger design.
Debit-before-settlement risk
Some products debit customer before external settlement.
This creates a temporary state:
- customer money removed/earmarked;
- bank still owns external execution risk.
Controls:
- payment cannot disappear between debit and release;
- failed release produces timely correction;
- reconciliation identifies any debit without corresponding external outcome.
Metric:
customer debits with no external disposition.
This should be near zero outside controlled pending windows.
Credit-before-final-settlement risk
Some retail products may make funds available under product/risk rules before final interbank settlement.
This creates settlement/credit exposure.
The bank must understand:
- when customer credit becomes irreversible;
- whether settlement can fail;
- how exposure is funded;
- what recourse exists.
Training should not imply all customer credits wait for final settlement.
Accounting state machine
A simple accounting state can be:
NONE
RESERVED
PENDING_POSTING
POSTED
CORRECTION_PENDING
CORRECTED
SUSPENSE
This state is separate from payment state.
Example:
- Payment state: SETTLED
- Accounting state: PENDING_POSTING
That combination should alert operations.
Double-entry illustration
Suppose customer deposit account is a liability of bank.
An outbound payment may reduce that liability and reduce settlement asset.
Conceptually:
Dr Customer deposits liability
Cr Settlement cash / control
Exact accounts vary.
For inbound:
Dr Settlement cash / control
Cr Customer deposits liability
These illustrations explain economic direction only. Each institution follows its chart of accounts and accounting policies.
Control-account design
Control accounts are useful when interfaces are asynchronous.
Example:
- payment engine creates settlement event;
- settlement interface posts control account;
- customer ledger posts later;
- reconciliation clears control.
Control account should never become a hidden warehouse of unresolved items.
For every control balance, know:
- source population;
- clearing event;
- ageing;
- owner.
Intraday accounting versus end-of-day GL
Customer ledger may post continuously.
GL may receive:
- real-time journals;
- micro-batches;
- end-of-day aggregate.
If GL uses aggregation, reconciliation must still preserve transaction traceability.
Example:
- 100,000 AFT customer credits summarized into one GL journal.
Bank still needs evidence connecting:
- 100,000 item population;
- aggregate amount;
- GL journal;
- settlement position.
ACSS item-to-position accounting
ACSS is a key example.
Customer-level:
Clearing-level:
Settlement-level:
- net participant obligation.
GL must not require one settlement cash movement per item.
A strong hierarchy:
AFT items
↓ aggregate by stream/cycle
Clearing position
↓ net
Settlement obligation
↓
Bank of Canada / sponsor settlement
Reconciliation bridges levels.
Direct versus indirect settlement accounting
Direct clearer:
- owns settlement account relationship.
Indirect:
- owns bilateral financial relationship with sponsor/group clearer.
Indirect’s accounting should not pretend it has a direct Bank of Canada settlement account if it does not.
Evidence:
- sponsor statement/report;
- bilateral settlement account;
- item populations.
Lynx settlement accounting
Because Lynx settles individual payment obligations in real time, payment-level settlement evidence is stronger.
For each high-value payment:
- unique payment;
- settlement event;
- customer posting;
- settlement-account movement.
This supports tight intraday reconciliation.
Intraday loan/collateral accounting boundaries
Treasury may use intraday credit/collateral arrangements.
Payments operations does not need to own treasury accounting, but should know:
- liquidity source affects settlement ability;
- collateral events are not customer payment events;
- liquidity ledger and payment ledger should not be conflated.
RTR continuous accounting readiness
A 24/7 rail creates accounting challenges around midnight.
Example:
payment at 23:59:59 settles before date rollover.
Customer posting completes 00:00:01.
Questions:
- which business date?
- which statement date?
- which GL period?
- how reconciliation groups event?
Rules should be deterministic.
No nightly shutdown should be required to maintain accounting integrity.
Statement consistency model
Customer can see multiple surfaces:
- app transaction list;
- PDF statement;
- camt.053;
- corporate portal;
- API.
All should derive from same ledger truth.
Differences in formatting are fine.
Differences in amount/date/reference/status are defects unless product intentionally distinguishes fields.
Corporate remittance preservation
Corporate customers need references for cash application.
Payments process should preserve:
- end-to-end reference;
- invoice/remittance;
- payer/payee;
- structured references.
Accounting/statements should not replace useful remittance with generic:
“ELECTRONIC PAYMENT.”
Loss of reference creates manual reconciliation work even when money is correct.
Value date and interest
Value date may affect:
- interest;
- overdraft;
- cash management.
Bank product policy determines treatment.
If posting happens later than value date, ledger may need back-valued economic treatment.
Any backdating must be controlled and auditable.
Backdated corrections
Manual backdating can distort:
- interest;
- statements;
- financial period.
Controls:
- permitted roles;
- reason;
- approval;
- period-open checks;
- customer impact;
- reconciliation.
Fee accounting deep dive
A payment can have:
- product fee;
- network fee;
- correspondent charge;
- tax;
- FX margin.
Keep separate fee types.
If customer disputes:
- operations can explain which fee;
- finance can reconcile;
- product can analyze revenue.
Do not combine all deductions into payment amount.
Fee waiver versus fee reversal
Fee waiver:
- fee never charged or set to zero.
Fee reversal:
- charged then credited back.
These are different audit events.
FX accounting deep dive
Cross-border payment can create:
- customer buys currency;
- bank hedges;
- nostro settlement;
- return;
- re-conversion.
Return does not automatically cancel original FX trade economically.
Bank may have market gain/loss exposure.
Operations must not promise customer “same CAD amount back” unless product terms support it.
Multi-currency suspense
Incoming return in USD for customer CAD account:
- value arrives USD;
- account cannot accept USD;
- FX required;
- suspense until conversion/credit.
Case should show currency at each step.
Return before original ledger finalized
Race condition:
- original settlement posts;
- return arrives quickly;
- original customer ledger still pending.
Accounting engine should sequence safely.
Possible:
- original debit posts;
- return credit posts;
- net customer position correct.
Do not drop return because “original not found” if original event exists but downstream posting delayed.
Duplicate posting control
Use event uniqueness.
Example:
unique(eventType, paymentId, settlementReference)
If same event replayed:
- return existing ledger result.
For legitimate multiple events:
- each has different event ID.
Reversal authorization
Reversal should not be generic transaction type available to all staff.
Require:
- original posting ID;
- allowed reason;
- amount cannot exceed original unless explicit adjustment;
- currency match;
- approval;
- case.
Closed customer account
Returned funds arrive after account closed.
Options depend on bank policy:
- controlled suspense;
- bank draft/alternate payment;
- reopen? generally policy/legal decision.
Do not silently credit unrelated replacement account.
Deceased customer / estate
Payment return may arrive to account under estate handling.
Payments operations should follow legal/estate process.
Ledger automation should route restricted accounts to specialist queue.
Frozen or blocked accounts
Inbound funds to account blocked for legal/compliance reason:
- settlement may occur;
- customer availability restricted.
Statement/accounting must distinguish:
- received;
- not available due restriction.
Customer statement dispute
Customer says:
“I see two debits.”
Investigation compares:
- payment IDs;
- ledger references;
- external settlement count.
If duplicate internal debit:
If two separate authorized payments:
Statement regeneration
If statement corrected:
- preserve original issued statement where required;
- generate corrected record;
- audit version.
Do not rewrite history invisibly.
camt reporting consistency
Corporate reporting may include:
- booked entries;
- pending entries in other camt message types depending implementation;
- transaction details.
Payments Canada Lynx camt.053 specification provides message requirements for Lynx context.
Bank implementation must map internal ledger fields accurately.
Reconciliation rules for accounting
Rule 1: count
Expected vs posted.
Rule 2: amount
Sum.
Rule 3: identity
Transaction-level match.
Rule 4: state
Settlement and ledger consistent.
Rule 5: time
Date/cycle.
Rule 6: correction
Original + return/reversal linked.
Four common accounting breaks
Break A: settlement without customer debit
Bank financial loss/exposure.
Break B: customer debit without settlement
Customer harm.
Break C: double customer debit
Customer harm + GL imbalance/control break.
Break D: return settlement without customer correction
Customer/financial break.
All four should alert quickly.
Intraday proof
For high-value payment:
- settlement account balance;
- outgoing Lynx settlements;
- incoming Lynx;
- treasury transfers;
- ACSS settlement payments;
- other permitted movements.
Intraday reconciliation should explain balance movement.
End-of-day proof
End-of-day package can include:
- opening balances;
- transaction totals;
- settlement totals;
- closing;
- breaks;
- suspense;
- manual journals;
- high-value exceptions;
- sign-off.
Sign-off is not ceremonial.
Finance versus payments ownership
Payments operations owns:
- transaction lifecycle;
- external settlement evidence;
- operational breaks.
Finance owns:
- GL/accounting policy;
- period close;
- financial reporting.
Treasury owns:
Product owns:
A payment accounting process crosses all.
Accounting incident classification
Examples:
- incorrect customer balance;
- duplicate debit;
- delayed credit;
- GL imbalance;
- settlement-account mismatch.
Incident severity should consider:
- number customers;
- value;
- duration;
- regulatory impact;
- financial reporting.
Production monitoring
Useful alerts:
- settlement events not posted within threshold;
- customer debits with no external payment;
- duplicate event-key attempts;
- suspense growth;
- manual journal spikes;
- GL interface failure;
- statement generation mismatch;
- return without original match.
Accounting test catalogue
Outbound
- reservation;
- successful settlement;
- pre-release reject;
- external reject;
- ledger timeout;
- retry.
Inbound
7. valid credit;
8. closed account;
9. restricted account;
10. duplicate event.
Return
11. full return;
12. partial;
13. duplicate return;
14. return after customer reimbursement;
15. return to closed account.
Fees
16. charge;
17. waiver;
18. refund;
19. tax.
FX
20. conversion;
21. return same currency;
22. return with charges;
23. re-conversion.
Period
24. midnight;
25. holiday;
26. month-end;
27. year-end.
Resilience
28. ledger DR;
29. message replay;
30. GL outage.
Example: complete accounting evidence pack
For a CAD 75,000 Lynx payment:
Payment ID: PAY-1009
Customer instruction: authorized
Customer debit: LED-8871
Lynx settlement: SET-5510
Settlement account evidence: CAMT/statement ref ...
Fee: FEE-381
Statement entry: STM-998
GL journal: GL-771
Reconciliation: MATCHED
If later returned:
Return payment: RET-200
Return settlement: SET-6001
Customer credit: LED-9100
Case: INV-331
Reconciliation: ORIGINAL+RETURN MATCHED
Nothing is erased.
Final accounting principle
The ledger should tell the same story as the payment system, but from a financial perspective.
If the payment system says:
“settled and returned”
the ledger should not say:
“never happened.”
It should say:
“original financial event occurred; corrective financial event occurred.”
Role-based accounting responsibilities
A payment accounting process crosses organizational boundaries. Ambiguity here creates breaks.
Payment product
- defines when customer is considered charged/credited;
- fee terms;
- statement descriptions;
- cancellation/return commercial treatment.
Payments technology
- creates reliable events;
- enforces idempotency;
- preserves references;
- interfaces ledger.
Payments operations
- owns payment-state interpretation;
- exception initiation;
- manual correction requests.
Finance
- owns chart of accounts;
- accounting policy;
- GL close;
- period adjustments.
Treasury
- owns settlement liquidity and cash-position interpretation.
Reconciliation
- independently proves populations/balances.
Customer service
- explains entries using approved language.
No single team should be able to alter payment state and accounting state without independent control.
Posting authorization model
Automated posting should be rules-driven.
Manual posting should require:
- valid event/case;
- permitted account;
- permitted amount;
- reason;
- user entitlement;
- checker where required.
System should prevent:
- manual credit to settlement account without authorization;
- direct edits to immutable transaction history;
- posting without customer/payment reference.
Ledger-interface contract
A payment engine sends a posting request such as:
eventId
paymentId
eventType
account
amount
currency
bookingDate
valueDate
narrative
reference
Ledger responds:
accepted/rejected
ledgerReference
postingTimestamp
reason
Payment engine stores result.
If response lost, retry by eventId returns same ledgerReference.
This is idempotency in practice.
Booking-date controls
Booking date should derive from:
- event timestamp;
- product calendar;
- accounting period;
- correction rules.
Manual date override must be rare.
Errors can affect:
- interest;
- customer statement;
- liquidity reporting;
- GL period.
Month-end and year-end
Payment systems do not stop being operational because finance closes.
At period close:
- identify pending settlement;
- unresolved returns;
- suspense;
- manual journals;
- known incidents.
Finance may accrue/adjust under policy.
Payments should supply accurate operational state.
Settlement account statement ingestion
Automate:
- receive statement;
- validate file/message;
- sequence/control totals;
- load transactions;
- match;
- alert missing statement.
If statement does not arrive:
- do not assume zero movement;
- escalate.
Statement-sequence integrity
For statement/report feeds:
- detect missing sequence;
- duplicate file;
- overlapping date;
- truncated file.
Reconciliation quality depends on source completeness.
Ledger outage recovery
If ledger unavailable:
- stop unsafe customer-posting-dependent actions;
- persist posting events;
- know which events reached ledger;
- after recovery query/retry idempotently;
- reconcile full outage population.
Do not create new payment to fix a posting problem.
Payment-engine outage with ledger active
Opposite case:
- customer debit may have posted;
- payment event not progressed.
Recovery should detect orphan debit.
Metric:
ledger entry without payment progression.
GL-interface outage
Customer ledger and settlement continue.
GL feed fails.
Bank can continue under approved resilience policy, but:
- backlog tracked;
- financial reporting aware;
- replay idempotent;
- reconciliation after recovery.
Suspense taxonomy
Do not use one suspense account for everything.
Possible categories:
- unmatched incoming;
- return unmatched;
- customer-account blocked;
- FX pending;
- technical posting;
- investigation.
Separate categories improve ownership.
Suspense economics
A suspense balance is still bank money/customer money exposure.
Track gross, not only net.
Example:
+CAD 5 million unmatched credits
-CAD 5 million unrelated debit adjustments
net zero
Risk is not zero.
Ageing governance
Daily suspense report:
- amount;
- count;
- oldest;
-
threshold;
- high-value;
- customer-impact;
- owner.
Senior sign-off for old/high-value.
Ledger narrative quality
Narrative should:
- be understandable;
- preserve reference;
- avoid exposing internal system names;
- differentiate return/reversal.
Example:
“Returned wire – original ref ABC123”
better than:
“CR ADJ 00984”.
Corporate statement reconciliation
Corporate treasury may reconcile:
- payment status API;
- camt.053 statement;
- ERP.
If references differ across channels, customer has manual work.
Design consistent end-to-end reference.
Duplicate-statement entries
A statement generator can duplicate line even if ledger correct.
Reconcile statement entry IDs to ledger.
Customer sees duplicate despite no balance impact — still serious experience issue.
Back-valued credit example
Incoming payment settles Friday but posting outage delays customer credit until Monday.
Bank policy may require Friday value date.
Accounting must:
- post Monday booking timestamp;
- apply correct value date where policy requires;
- calculate interest/compensation if applicable;
- report transparently.
Exact treatment depends on bank/product/legal rules.
Fee-refund workflow
Customer complains wire delayed.
Bank decides fee refund goodwill.
This is not payment return.
Create:
- fee refund event;
- customer credit;
- link to complaint/payment.
Keep payment settlement unchanged.
Compensation
Compensation may be:
- fee refund;
- interest;
- fixed goodwill;
- scheme/rule claim.
Treat separately from payment principal.
Tax accounting
Some fees/taxes may have tax treatment.
Payment platform should identify fee type so finance can apply tax rules.
Do not bury tax in principal amount.
Cross-border nostro reconciliation
For outgoing USD:
- customer CAD/ USD debit;
- FX;
- nostro debit;
- SWIFT/message;
- beneficiary bank.
Reconciliation should match:
- nostro statement;
- payment records;
- fees.
Nostro break can reveal:
- duplicate debit;
- missing correspondent booking;
- wrong value date.
Cover payment considerations
Where correspondent models use separate cover/settlement legs, message and funds evidence may be in different paths.
Accounting must tie both to one customer payment.
Do not treat receipt of customer message as nostro settlement.
Returned cross-border funds
Return may:
- come from different correspondent;
- include charges;
- have different reference;
- arrive later.
Matching engine uses:
- original reference/UETR;
- amount;
- parties;
- narrative.
Manual review if ambiguous.
Accounting for fraud reimbursement
Separate:
- customer reimbursement;
- recovery receivable;
- recovered funds;
- write-off.
Illustrative:
Customer reimbursed 5,000
Recovery received 3,500
Residual bank loss 1,500
If customer reimbursement occurs before recovery, bank should not credit recovery again to customer unless policy says so.
Accounting for chargebacks/disputes
Card disputes use card-scheme processes different from AFT/Lynx returns.
The accounting principle still applies:
- original purchase;
- provisional credit;
- chargeback;
- representment;
- final outcome.
Do not force card dispute into wire-return model.
Audit lineage
Every ledger entry should be searchable back to:
- source system;
- payment;
- event;
- user/system;
- time;
- posting rule version.
Every payment should show related ledger entries.
Bidirectional lineage is powerful for investigations.
Accounting rule versioning
Posting template changes over time.
Store version used.
Example:
- fee mapping changed Jan 1;
- old transactions retain old mapping.
Without versioning, replay can create different accounting from original.
Replay safety
DR/backfill may replay historical events.
Ledger must detect:
- already posted;
- already reversed;
- already returned.
A replay should reconstruct, not duplicate.
Reconciliation control totals
At interface level:
- record count;
- debit total;
- credit total;
- currency totals;
- hash/file ID.
At transaction level:
Both needed.
Reconciliation sign-off roles
Operational recon analyst:
matches/breaks.
Payments ops:
explains payment state.
Finance:
accepts GL position.
Treasury:
accepts settlement account.
Segregation improves control.
Accounting KPI set
- posting STP rate;
- posting failure count;
- settlement-to-post latency;
- suspense count/value/age;
- duplicate posting attempts;
- manual journal count/value;
- GL break count;
- statement defect rate;
- return match rate.
Accounting control dashboard example
Green
- all settlement statements loaded;
- no high-value unmatched;
- suspense below threshold;
- GL balanced.
Amber
- delayed noncritical feed;
- low-value aged breaks.
Red
- settlement account mismatch;
- customer debit without external payment;
- duplicate postings;
- GL out of balance.
Accounting acceptance criteria for new payment product
Before launch:
- event catalogue approved;
- posting templates;
- fees;
- FX;
- suspense;
- return accounting;
- customer statements;
- GL mapping;
- reconciliation;
- DR replay;
- period close;
- audit lineage.
Practical scenario: inbound high-value posting outage
Incoming CAD 2 million settles.
Beneficiary ledger unavailable.
System:
- records settlement;
- creates pending credit;
- does not resend/return automatically;
- alerts;
- after ledger recovery posts once;
- statement generated;
- reconciliation clears.
If product/funds-availability obligation requires different action, bank follows applicable rules.
Practical scenario: wrong fee but correct payment
Payment principal correctly settles.
Fee engine charges CAD 50 instead of CAD 25.
Correction:
- payment remains complete;
- fee adjustment CAD 25;
- statement shows fee correction;
- root cause fee configuration.
Do not reopen payment settlement.
Practical scenario: return before statement issue
Original debit and returned credit occur same day.
Statement may show both separately.
Netting into no entry would hide history and confuse customer reference.
Practical scenario: month-end return
Original in August.
Return settles September.
Books:
- original August;
- return September.
Do not rewrite closed August period merely to make transaction appear net zero, unless accounting policy specifically requires adjustment.
Final operational checklist for each financial event
Before a posting is considered controlled:
- source event exists;
- event unique;
- amount/currency valid;
- account valid;
- booking/value date determined;
- posting rule version recorded;
- ledger reference returned;
- external settlement link where relevant;
- statement mapping;
- reconciliation rule.
Practitioner accounting walkthroughs
Walkthrough 1: customer debit succeeds, payment release fails
Evidence:
- ledger debit present;
- no external acceptance;
- no settlement.
Required result:
- correct customer debit according to bank design;
- no fake settlement entry;
- preserve failed payment record;
- reconcile correction.
This is a classic “money left my account” complaint where interbank payment never happened.
Walkthrough 2: external settlement succeeds, customer debit fails
Evidence:
- settlement outflow;
- customer account not debited.
Risk:
- bank has funded customer payment without reducing customer liability.
Required:
- urgent accounting exception;
- determine lawful/product-correct customer posting;
- financial exposure tracked;
- reconcile.
Walkthrough 3: incoming settlement succeeds, account closed
Evidence:
- central/external settlement inbound;
- beneficiary account cannot be posted.
Required:
- controlled suspense/return process;
- no loss of settlement identity;
- final action linked to original.
Walkthrough 4: customer reimbursed before recovery
Evidence:
- fraud provisional credit;
- later return.
Required:
- returned funds clear bank exposure;
- customer not double credited;
- case and ledger linked.
BA accounting requirements checklist
For each payment product document:
- debit trigger;
- credit trigger;
- reservation behavior;
- settlement event;
- return event;
- reversal eligibility;
- fee event;
- FX event;
- statement mapping;
- GL mapping;
- suspense route;
- reconciliation source;
- manual correction process;
- idempotency key;
- business/value date logic;
- DR replay behavior.
If any are undefined, implementation will invent behavior.
Accounting sequence diagram in words
Outbound:
Channel → Payment Hub: authorized instruction
Payment Hub → Ledger: reserve/debit
Payment Hub → Rail: release
Rail → Payment Hub: settlement result
Payment Hub → Ledger: finalize
Ledger → Statement: report
Recon → all sources: prove match
A failure at each arrow needs a defined response.
Statement design test
A customer statement should let an informed reader identify:
- original debit;
- return credit;
- fee;
- fee refund.
It should not require support to decode cryptic internal references.
Financial-integrity test conditions
At any checkpoint:
sum(customer postings)
+/- control accounts
should explain
external settlement + known timing differences
Differences require explicit breaks.
Payment accounting anti-patterns
- status-driven journal without event uniqueness;
- manual ledger fix with no case;
- deleting original entry;
- one suspense account for all products;
- customer statement generated from payment status rather than ledger;
- using net totals to hide transaction mismatches;
- assuming network message equals settlement;
- using current posting rules to replay old events without version.
Accounting operational review
Daily review can cover:
- high-value unmatched;
- settlement-account breaks;
- aged suspense;
- manual journals;
- posting failures;
- duplicate attempts;
- statement-generation failures;
- returns not matched.
Weekly:
- root causes;
- repeat products;
- automation opportunities.
Monthly:
- control effectiveness;
- audit issues;
- material loss/adjustments.
Data retention and audit
Retain according to legal/regulatory/internal requirements:
- event history;
- ledger references;
- message/reference;
- rule version;
- manual approval;
- reconciliation result.
The design objective is reproducibility: the bank can rebuild why the balance changed.
Accounting failure-mode matrix
| Failure | Financial risk | Primary control |
|---|
| Customer debited, payment not sent | customer harm | debit-to-release reconciliation |
| Payment settled, customer not debited | bank exposure | settlement-to-ledger reconciliation |
| Customer credited twice | customer overpayment | idempotent posting |
| Return received, not credited/allocated | trapped funds | return matching/suspense |
| Fee duplicated | customer harm | fee event uniqueness |
| FX return misapplied | P&L/customer dispute | currency-aware accounting |
| Statement duplicates line | customer confusion | statement-to-ledger reconciliation |
| DR replays old event | duplicate financial posting | immutable event key |
Ledger-interface design questions
Architects should decide:
- synchronous or asynchronous posting?
- what event confirms success?
- how are retries handled?
- how does payment hub query prior posting?
- what happens if ledger commits but response is lost?
- how are reversals authorized?
- what is the source of booking date?
- where is value date calculated?
- how is statement narrative generated?
- which system owns fee accounting?
The most important answer is usually idempotency.
Example of a lost ledger response
- Payment hub sends debit event E100.
- Ledger posts successfully.
- Network response to hub is lost.
- Hub retries E100.
- Ledger recognizes E100 already posted and returns original ledger reference.
Without idempotency:
- customer can be debited twice.
Accounting and customer status
Customer status should not be derived solely from ledger.
A debit can exist while payment is still under review.
Likewise payment can settle while statement generation is delayed.
Product should combine:
- payment state;
- accounting state;
- safe customer wording.
Accounting knowledge check
Does a customer debit prove interbank settlement?
No.
Does an external settlement prove beneficiary customer posting?
No.
Should a returned payment erase original debit?
No. Normally the return creates a separate corrective credit/event.
Can a fee refund be treated as payment return?
No. It is a separate commercial/accounting event.
Why reconcile transaction identity, not totals only?
Equal and opposite individual errors can net to zero.
Chapter 69 practical takeaway
Every balance change should have:
- source event;
- unique posting identity;
- accounting rule;
- ledger reference;
- reconciliation.
If the bank can produce those five elements, most payment accounting questions become explainable instead of forensic.
Full end-to-end accounting case
A fictional company, Maple Distribution, sends CAD 800,000 to a domestic supplier through Lynx and pays a CAD 35 bank fee.
A simplified event chain:
PAY-800 customer payment
RES-800 funds reserved
LED-1001 customer principal debit
FEE-1002 fee debit
SET-4400 Lynx settlement
STM-7001 customer statement entries
GL-9000 finance journal
REC-6000 reconciliation match
Two days later, the receiving bank returns CAD 800,000 because the beneficiary account cannot accept the payment.
New events:
RET-801 payment return
SET-4409 return settlement
LED-1015 customer return credit
CASE-300 return case
REC-6010 original + return reconciliation
The original debit and settlement are not deleted.
The CAD 35 fee is a separate commercial question.
If product policy says the fee is not refundable, it remains.
If the bank grants goodwill:
FEE-REF-77 +35 customer credit
Again, separate event.
Now add a technology defect: the return settlement event is replayed.
The ledger receives RET-801 a second time.
Idempotency detects the same event identity and returns:
already posted → LED-1015
Customer is not credited again.
This scenario demonstrates why a bank-grade model needs:
- immutable payment identity;
- separate fee identity;
- settlement identity;
- corrective identity;
- idempotent posting;
- reconciliation.
Accounting review questions
What if the original customer debit never posted but Lynx settlement did?
The bank has settlement outflow without matching reduction in customer liability. That is urgent financial exposure.
What if the customer was already reimbursed before return?
Returned value may belong against the bank’s recovery exposure rather than another customer credit.
What if return comes in a different currency?
Currency conversion and FX treatment become separate controlled events.
What if statement shows only net zero?
That hides the original payment and return. A transparent statement should preserve the economic history.
Accounting specification rule
For every new payment product, require the implementation team to produce a table with:
Event | Customer posting | Settlement posting | Fee | GL | Statement | Reconciliation
for:
- success;
- reject;
- return;
- reversal;
- timeout;
- duplicate;
- manual correction.
If that table cannot be completed, the accounting design is not finished.
Designing accounting around immutable business events
The safest design does not let applications issue arbitrary debit/credit commands. Instead, the application emits a business event and the accounting layer maps the event through an approved posting rule.
Example:
Business event: OUTBOUND_PAYMENT_SETTLED
Rule version: 5
Product: domestic-wire
Currency: CAD
Payment: PAY-991
The accounting engine determines the configured posting template.
Benefits:
- consistent journals;
- easier audit;
- safer change control;
- reliable replay;
- simpler reconciliation.
Posting-rule change lifecycle
When a rule changes:
- finance/product defines requirement;
- accounting design approved;
- effective date set;
- test cases prepared;
- old and new version coexist for history;
- production monitoring verifies outcomes.
Never modify historical events merely because the current rule is different.
Multi-ledger consistency
Some banks use:
- customer core ledger;
- payment subledger;
- finance GL;
- data warehouse.
Consistency should be eventual within controlled limits, not ambiguous.
Each interface has:
- producer;
- consumer;
- expected latency;
- completeness control;
- reconciliation.
A delay is acceptable only when the bank can still identify the authoritative balance and customer promise.
Accounting for indirect clearing relationships
An indirect institution may record a position against its sponsor rather than against a Bank of Canada settlement account.
Illustratively:
Customer items
→ internal clearing position
→ sponsor settlement account/statement
→ GL
The sponsor performs its own reconciliation to the external payment system.
This is why educational diagrams should not show every Canadian bank settling directly at the Bank of Canada.
Settlement-account versus nostro accounting
Domestic central-bank settlement and cross-border correspondent settlement are different.
Settlement account
- central bank;
- domestic FMI/payment-system settlement.
Nostro
- account held with correspondent;
- foreign/cross-border settlement.
Both require:
- balance;
- transaction matching;
- liquidity.
But legal/operational frameworks differ.
Accounting for rejected payments
A rejection can occur after customer funds were reserved but before final debit.
Treatment may be:
- release reservation;
- no statement entry.
If a booked debit already occurred under product design:
- corrective credit may be required.
The accounting system should know the exact point at which a temporary hold becomes a booked transaction.
Accounting for cancellation
A scheduled payment cancelled before booking may have:
- no financial entry;
- released reservation.
If fee was charged at setup:
- fee treatment follows product terms.
Again, cancellation is not automatically a financial reversal.
Accounting for failed beneficiary posting after settlement
Receiving bank may have settlement inflow but no valid customer account.
It needs a controlled internal holding position until:
- beneficiary resolved;
- payment returned.
The sending bank’s accounting remains based on its settled outflow until a return actually arrives.
Statement correction after operational error
Suppose the bank posts an incorrect description, while balance is correct.
Correction may require:
- statement narrative correction;
- no principal financial posting.
Not every customer-visible defect is a money movement.
Accounting and data warehouses
Analytics platforms often ingest payment and ledger data asynchronously.
They should not become the source for real-time corrective action unless designed for that purpose.
Operations should use transactional sources for live balance and settlement decisions.
GL aggregation controls
If 100,000 transactions become one GL journal, retain:
- source batch ID;
- transaction count;
- debit total;
- credit total;
- currency totals;
- hash/control total;
- posting date.
The GL journal should be reproducible from source population.
Unbalanced interface handling
If debit side posts but credit side fails in a downstream accounting interface, the system should not silently retry only one side without understanding atomicity.
Posting architecture should ensure:
- atomic double-entry where possible;
- compensating action where not;
- break detection.
Rounding and currency precision
Use currency-specific precision rules.
Never use binary floating-point for financial accounting amounts where decimal precision is required.
Store:
- decimal amount;
- currency;
- scale.
Rounding rules should be explicit for:
Accounting for payment limits and holds
A limit decision is not a ledger entry unless the product uses a financial reservation.
Do not confuse:
- customer transaction limit;
- credit limit;
- fraud limit;
- available balance.
They are separate controls.
Customer balance concepts
Banks may show:
- ledger/book balance;
- available balance;
- pending transactions.
Payment status should explain differences.
Example:
“CAD 5,000 scheduled payment is reducing available balance but has not yet settled.”
Exact UI depends on product.
Statement reference design
Use stable references.
A customer should be able to quote a statement reference to support and have support find the payment.
Reference should remain linked across:
- original;
- return;
- fee;
- investigation.
Reconciliation of fees
Fee reconciliation compares:
- product fee event;
- customer ledger fee;
- GL income;
- tax entries where applicable.
A payment can reconcile while fee accounting is broken.
Treat separate populations.
Reconciliation of FX
Compare:
- customer rate;
- dealt amount;
- payment currency;
- treasury/FX system;
- nostro;
- ledger.
A returned payment can require a second FX chain.
Accounting control testing with chaos/failure
Inject:
- duplicate settlement event;
- ledger response loss;
- GL response loss;
- delayed statement;
- return before original posting confirmation;
- DR replay;
- message out of order.
Expected result:
- no double posting;
- correct final balance;
- clear exception;
- recon closes after recovery.
Chapter 69 final practitioner checklist
For every payment state ask:
Customer
- What is booked?
- What is available?
- What will statement show?
Settlement
- What external value movement occurred?
Accounting
- Which posting rule executed?
- Which ledger reference proves it?
Correction
- Is a new compensating event required?
Reconciliation
- Which independent source confirms correctness?
That set of questions prevents accounting from becoming an afterthought to payment messaging.
12. Implementation, testing and authoritative references
Implementation principles
- accounting events are immutable;
- corrections are compensating events;
- payment and ledger identities are linked;
- posting APIs are idempotent;
- external settlement is never inferred from customer posting;
- suspense is governed;
- manual journals require approval;
- statements preserve original/corrective entries;
- reconciliation is transaction-aware.
Test scenarios
Test:
- debit before release failure;
- settlement before customer posting;
- posting retry;
- duplicate event;
- partial return;
- full return;
- fee reversal;
- FX return;
- closed account;
- suspense ageing;
- midnight accounting date;
- weekend/holiday;
- batch net settlement;
- high-value RTGS;
- real-time 24/7 posting;
- statement regeneration;
- manual journal;
- ledger outage and recovery.
Authoritative references
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.