Payroll Payments. Trace employer payroll through validation, AFT processing, settlement, employee credit and exception handling.
Block 4 · Chapter 18 of 75
Payday is the most unforgiving date in retail payments. A supplier paid a day late phones accounts payable. An employee paid a day late phones everybody — the employer, the bank, the union, and, in the age of screenshots, social media. There is no quiet payroll failure. Every payroll run is thousands of individual promises that must all be kept on the same morning, and the bank sits in the middle of every one of them: receiving the employer's file, validating it, releasing it into clearing, funding settlement, and answering when anything goes wrong.
Two status facts anchor everything that follows. First, Canadian payroll travels as AFT credit transactions cleared through ACSS, a live batch deferred net settlement system, with ACSS settlement account holders meeting net positions by Lynx payments to Bank of Canada settlement accounts. Second, timing in this chapter is always relative — files move according to the destination branch's AFT serviceability and exchange window, settlement follows on a later business morning, and employee availability depends on settlement plus receiving-bank posting. No exact times appear here, because exact cutoffs vary by bank, by clearer, by file type and by day. Binding times come from your bank's published schedules read together with the published system closure calendar.
What you should be able to do after this chapter
After working through this chapter, you should be able to:
- explain in plain language how employer payroll becomes employee pay — calculation, file, validation, release, AFT exchange, settlement, posting — and who owns each stage;
- name the participants in a payroll run — employer, payroll processor or bureau, originating bank, direct, group and indirect clearers, clearing and settlement agents, receiving banks, employees, Payments Canada and the Bank of Canada — and state what each owns;
- describe what a payroll file contains and what the bank must validate before release — employee master, account and routing data, amounts and control totals, funding, approvals — and why repair-or-reject happens before release;
- trace AFT credit transactions from release through daytime exchange windows, clearing and position calculation to morning settlement, without confusing exchange, clearing, settlement, posting, availability and finality;
- explain why the employer prefunds the run and what happens to timing when funding, approval or the file itself arrives late;
- describe the data each payroll credit needs — institution, transit and account structure, file and item references, return linkages, remittance and advice detail — and why bad data must be repaired before exchange;
- explain business-day, window and cutoff discipline in relative terms and tell an employer when value is this-window batch versus next-window batch versus a same-day-final alternative;
- describe the functional roles of Rule F1 and Rule F4 for AFT — legacy Standard 005 file exchange and ISO 20022 message exchange — without quoting the rulebook;
- place fraud, authorization, sanctions and record-keeping controls at the correct point in the flow — before release wherever prevention is the goal;
- distinguish direct deposit advices from the payment itself, and explain off-cycle and bonus runs as the same rails run on a compressed timetable with the same controls;
- classify rejects, returns, reversals and adjustments in payroll, and describe recovery that preserves the original item's identity and still gets the employee paid;
- explain posting, accounting, funding, reporting and four-way reconciliation from gross pay to net pay to bank debit to employee credit;
- describe what a bank must do to offer payroll services, test changes and stay resilient, including bureau arrangements and contingency paths;
- work through fictional but realistic Canadian cases — a mid-size manufacturer's payday, a failed employee account, an off-cycle correction — and extract the control lesson from each;
- describe year-end reporting at a functional level — what totals the payment chain must be able to evidence — without giving tax advice;
- navigate confidently to the authoritative references for ACSS, AFT rules, Bank of Canada oversight and payroll reporting obligations.
For a roughly 60-minute core session, spend about 10 minutes on Section 1 with the payroll-cycle diagram, 15 minutes on Sections 2–4 with the cycle, validation-gates and timeline diagrams, 10 minutes on Sections 5–6 with the reconciliation diagram, 10 minutes on Sections 7–9, 10 minutes on the fictional cases in Section 11, and 5 minutes on takeaways and references in Section 12.
Chapter navigator
- Business context and customer need
- Participants, responsibilities and system boundaries
- Initiation, validation and bank processing
- Clearing, settlement and finality
- Data, identifiers, messages and references
- Rules, cutoffs, service levels and customer impact
- Fraud, compliance and operational controls
- Exceptions, investigations and recovery
- Posting, accounting, liquidity, reporting and reconciliation
- Bank implementation, testing and resilience
- Practical Canadian examples
- Key takeaways and authoritative references
1. Business context and customer need
Every second Friday, a mid-size manufacturer with six hundred employees expects six hundred credits to land before branches open. Nobody at that company thinks about clearing systems. The payroll manager thinks about whether the file was accepted. The controller thinks about whether the funding left the right account. Each of the six hundred employees thinks about one thing only: is my pay there. When it is, nobody calls. When even a dozen credits are missing, the payroll manager's phone does not stop, the bank's service team inherits the queue, and the employer's trust in the bank takes the damage — regardless of where in the chain the failure actually happened.
Payroll is different from every other batch flow the bank handles, and the difference is worth stating plainly. A supplier payment run can tolerate a repair cycle; the supplier's receivables team will chase the reference and apply cash a day later. A consumer bill collection can tolerate a retry; the biller's policy already contemplates it. Payroll tolerates nothing. The amounts are the employee's rent and groceries. The date is fixed by employment terms and by expectation hardened over years. The population is the employer's entire workforce at once, which means a single flawed file is not one customer event but hundreds — all arriving on the same morning, all angry at the same time. This is why payroll chapters in banking courses always return to the same discipline: validate before release, respect the window, reconcile every position, and communicate timing honestly at intake rather than apologetically after pay date.
The employer's needs from the bank are straightforward to list and demanding to deliver. The employer needs a reliable channel for getting the pay file to the bank — a business portal upload, a host-to-host feed from its HR or enterprise system, or a payroll bureau acting on its behalf. The employer needs the bank to catch errors while they are still cheap: a closed account, a wrong transit number, a total that does not balance, a file submitted after the window that cannot make pay date. The employer needs certainty about funding: how much will leave the account, when, and what happens if the balance is short. The employer needs each employee to be told what landed and why — the direct deposit advice, the pay stub in its modern electronic form — with amounts that match the credit exactly. And the employer needs a repair path for the inevitable exceptions: the new hire whose banking details arrived late, the termination processed after the file closed, the bonus approved after the regular run. Every section of this chapter equips you to serve one or more of these needs.
It helps to see where payroll sits on the Canadian payments map before going deeper. Payroll travels as AFT credit transactions — push payments originated by the employer's bank on the employer's instruction — cleared through ACSS in batch and settled on a deferred cycle. That makes payroll the mirror image of pre-authorized collections, which pull funds on claimed authority and carry return rights shaped by that pull. It makes payroll utterly unlike a Lynx wire, which settles individually in real time with immediate finality at wholesale pricing; payroll buys low-cost scale and structured exception handling at the price of deferred settlement and return exposure. It makes payroll unlike Interac e-Transfer, which serves person-to-person immediacy on its own infrastructure. A banker who can place the Friday pay run on this map in thirty seconds — batch push, Canadian dollars, deferred settlement, advice-driven reconciliation — has the single most valuable skill this chapter teaches. The rest is execution.
The economics of payroll for the bank deserve an honest paragraph. Payroll files are large, regular and operationally intense: hundreds or thousands of items per employer, every pay cycle, each requiring validation, screening, release, tracking, posting evidence and reconciliation, with service peaks compressed into narrow windows before pay dates. The revenue per item is modest — batch pricing, not wire pricing — while the cost of failure is severe in service workload and client trust. Banks offer payroll services anyway, because the operating account relationship is among the stickiest a business ever buys, and a bank known for flawless paydays wins accounts it would never win on price alone. Understanding this bargain explains why this chapter treats validation and communication as revenue protection rather than back-office overhead.

The diagram above is your anchor for the whole chapter. Read it left to right for flow — calculation, intake, validation, release, exchange, settlement, posting — and note the ownership line under each stage. Every later section is a deeper pass over one box or one arrow in that picture. When a payroll incident lands on your desk, start by locating it on this diagram before doing anything else: the box tells you the owner, the arrow tells you what evidence should exist, and the two together tell you who to call first.
2. Participants, responsibilities and system boundaries
A payroll run involves more parties than the two the employee imagines. The employee imagines the employer paying them. In reality the money passes through a chain of systems and institutions, and the bank professional must keep every link straight — because every payroll investigation walks this chain backwards, and confusing any two links sends the investigation to the wrong party for a day. This section names each participant, states what each owns, and draws the boundaries that matter operationally.
Start with the employer, the originator of the economic event. The employer calculates gross-to-net pay, assembles the pay file, authorizes it, funds it and warrants the instruction to its bank. The employer's responsibility does not end at upload: until the file is validated, released and confirmed, the employer owns the repair of every reject, and after settlement the employer owns the re-payment of every legitimately returned credit. Employers that treat upload as completion — that never check acceptances, never confirm totals, never reconcile — are the source of the classic late-discovery incident, where a rejected file sits unread while pay date passes. The bank's onboarding job is to make this ownership explicit before the first live run: who prepares, who approves, who funds, who watches confirmations, who repairs.
Between the employer and the bank often sits a payroll processor or service bureau: the company that runs calculations, prints or transmits advices, and delivers the bank file. Bureaus originate scale — one bureau may file for hundreds of employers — which concentrates both efficiency and risk. The boundary that matters is this: the bureau's involvement never moves the bank's duty to validate, screen, approve, release and warrant. The bank stands behind what it introduces into clearing regardless of whose software assembled the bytes. Each bureau relationship should therefore be written down before volume flows: who authenticates the file, who validates content, who handles rejects and returns, who reconciles, who may change banking details and under what verification. Every painful payroll incident involving a bureau features a handoff where both sides assumed the other owned a step — usually banking-detail changes, usually discovered after pay date.
The originating bank — the employer's bank — carries the heaviest operational load in the chain. It receives the file, authenticates the sender, validates every item, screens for fraud and sanctions, confirms funding, obtains or verifies approvals, assigns the file to a clearing window, releases it with the bank's implied warrant, tracks acceptances and rejects, manages returns, posts the funding debit, reports to the employer and feeds every event into reconciliation. When the employer asks "where is my payroll," it is this bank that answers, even for failures that happened downstream — which is why this bank keeps the release record, the window assignment and the gateway acknowledgements that every later inquiry starts from.
Banks participate in ACSS in distinct capacities, and the capacity determines what the originating bank can promise about timing. A direct clearer exchanges files directly, enters volumes and values into the clearing calculation, holds a settlement account at the Bank of Canada, funds its net position on settlement mornings, and can act as clearing and settlement agent for others. A group clearer is a direct clearer acting for a group of member institutions under group clearing arrangements. An indirect clearer participates through a direct clearer as its clearing and settlement agent: the agent exchanges on its behalf, includes its items in positions and settles for it, under an agreement with defined cutoffs, funding, return-handling and reporting duties. The practical consequence for payroll is direct: an indirect bank's payroll cutoff, late-file ability, return turnaround and incident communication are all bounded by its agent's timetable. An employer whose bank participates indirectly is not getting a worse service — but the service timetable has an extra constraint, and the bank must set file deadlines with that constraint visible rather than improvising around it on a Thursday evening.
Receiving banks — the employees' banks — own the last mile. Each receiving bank accepts the credits destined for its accounts, posts them according to its posting policy, makes funds available under its availability terms, issues or supports the statements and notifications the employee sees, and returns items it cannot post with the applicable reason. The receiving bank does not decide pay amounts, does not advise on employment terms and does not owe the employer anything. Its obligations run to its own customer, the employee, under its account terms and the rulebook's return provisions. When an employee's credit is missing, the investigation must cross from the originating side to this side with precise references — which is why reference discipline in Section 5 matters so much.
Employees are beneficiaries with expectations and, in exception cases, duties: providing correct banking details on hiring, reporting changed details through the employer's verified channel, and checking advices rather than assuming. Banks never control this link directly, but employer onboarding should cover it, because a surprising share of payroll returns trace to banking details the employee supplied incorrectly and nobody verified.
Payments Canada sits in the middle as owner and operator of ACSS: the rulebook anchored by By-law No. 3, the exchange and clearing infrastructure, and the published operating framework including the business-day and closure calendar. It holds no employer or employee accounts, does not decide whether an individual payroll credit posts, and does not guarantee any employee payment. The Bank of Canada wears two hats that must never be blended: it provides settlement accounts on whose books ACSS obligations are finally settled, with ACSS settlement account holders meeting net settlement obligations by Lynx payments (an ACSS account holder that is not a Lynx direct participant must use a Lynx direct participant); separately, it oversees ACSS under the Payment Clearing and Settlement Act. Final Canadian-dollar batch settlement uses the Bank of Canada's books; assurance that batch risk is governed comes from oversight.
Responsibility, in short, is a chain with no gaps. The employer calculates, authorizes and funds. The bureau, where present, processes under a written allocation of duties. The originating bank validates, screens, approves, releases and warrants. The clearing layer exchanges and positions. The settlement agent moves value finally. Receiving banks post and report. Agents stand in for their sponsored institutions at the clearing and settlement steps. Every investigation in Section 8 walks this chain backwards, which is why learning the chain once, here, pays for itself in every later section.
3. Initiation, validation and bank processing
Every payroll run starts in the same place: a calculation becoming a file becoming an instruction entering the bank's payment operations. The channel varies — a business portal upload by the payroll manager, a host-to-host feed from the employer's enterprise system, a bureau transmitting on behalf of dozens of employers — but the bank's job converges on the same discipline: turn an instruction into releasable, warranted AFT credits, or reject it with a reason while rejection is still cheap. Items rejected inside the bank cost a phone call and a same-day fix. Items rejected in clearing cost a business day. Items released with bad data cost an investigation, returns, re-payments and a damaged client relationship. The whole economics of this section is that ordering.
Initiation captures five facts plus authority: who pays whom, how much, in what currency and from which account, by when, with what references, and under what authority. A payroll file carries employee account details, net amounts, the pay date as due date, the employer's funding account and the employer's authorization evidenced through entitlements and approvals. The bank's first processing job is normalization: whatever the channel delivered becomes one internal instruction record per employee credit plus a file-level record with a durable identifier that survives every later stage. Without that internal anchor, the bank cannot track, investigate or reconcile — it can only guess. Control totals arrive with the file — item counts and summed amounts — and the bank checks them immediately, because a truncated or corrupted file that passes intake poisons everything downstream.
Validation is where most preventable payroll failures are caught, and it must complete before release. The gates run in an order that matters, shown in the chapter's validation diagram. First, the employee master: is each payee an active employee in the expected pay group, are starters verified, are leavers removed, are there duplicates the calculation created by accident. Second, account and routing data: is the institution, transit and account triple present, well-formed and reachable, with special attention to changed banking details, which fraudsters love and operations teams must re-verify through a known channel. Third, amounts and totals: does gross-to-net tie out per employee, do control totals balance to the file, do individual amounts and the file total sit within plausible bounds against history — a file for twice the usual total is either a bonus run someone forgot to announce or an error someone is about to release. Fourth, funding: is the employer's account open and enabled, and do available funds or an agreed credit arrangement cover the full run under this bank's product terms. Fifth, approvals and controls: dual approval captured, fraud scoring complete, any applicable sanctions screening disposed, cutoff logic assigning the file to this window or the next.

Between validation and release sits the control stack, and its order matters as much as its contents. Authentication and entitlement confirm the sender may instruct for this employer. Limits against approved thresholds catch the anomalous run. Fraud scoring weighs takeover signals, new-payee patterns and changed-detail risk. The bank's sanctions-screening control may use dispositions such as pass, documented false-positive clearance, or true-hit hold with escalation; the exact workflow is bank-specific and must comply with applicable law. Record-keeping capture preserves what future reporting, disputes and audits will need. Cutoff logic assigns the instruction to today's window or the next. Only after all of these does the bank release. Screening after release is recovery, not prevention, and batch recovery runs on return cycles measured in days — days the employee does not have.
Release commits the file to the clearing path: the AFT credits are delivered through the bank's gateway into ACSS exchange, directly for a direct clearer or through its agent for an indirect clearer, with the bank's warrant implied — the bank stands behind the items it introduces, including data quality, under the rulebook. The bank records release time, window assignment, gateway acknowledgement and the external references at release, because every inquiry for the rest of each item's life starts from that record. For an indirect clearer, release also means handoff into the agent's timetable: the agent's cutoff, not the bank's internal readiness, decides which window the items enter, and the agency agreement should say so explicitly enough that front-line staff never have to improvise.
After release the bank tracks acceptances and edit rejects, watches for returns on their own cycles, manages repair queues, posts the funding debit, generates employer reporting and feeds every event into reconciliation. Amendments after release are narrow by design: pre-settlement correction where permitted, never silent editing of a settled item. The original identifier follows every return, re-origination and adjustment. Two principles decide whether this survives reality. First, route by policy rather than habit: a payroll file that missed its batch window and cannot make pay date needs an honest conversation about alternatives — a same-day-final rail where eligible and accepted, or a revised pay-date commitment — not a batch release with a wish attached. Second, fail visibly and early: a bank that rejects with a reason, a repair path and a next-window promise creates one call; a bank that accepts everything and fails in clearing creates six hundred calls on Friday morning.
Off-cycle and bonus runs deserve a paragraph here because they stress this pipeline exactly where it is thinnest. An off-cycle run — a missed employee, a correction, a termination payment — and a bonus run — variable amounts, sometimes a different pay date — travel the same rails with the same gates and the same warrant. What changes is the timetable: compressed preparation, approvals chased rather than scheduled, funding confirmed in hours rather than days, and validation running against a thinner history baseline that makes anomaly detection harder. The control response is not to skip gates but to staff them: pre-agreed off-cycle procedures, named approvers reachable on short notice, funding pre-positioned or confirmed before the file closes, and explicit employer acknowledgement that compressed timetables narrow the repair window. The rails do not know the run is special. The discipline must.
4. Clearing, settlement and finality
If Section 3 is about the bank's decision, this section is about the system's promise — and the most expensive misunderstandings in payroll come from blending six events that are genuinely different. Exchange delivers items and data between participants. Clearing validates, sorts and positions those items by stream and window. Settlement moves value finally between settlement accounts. Posting debits and credits customer accounts on the bank's books. Availability tells the employee the funds may be used. Finality tells the system the value movement cannot be unwound through the settlement mechanism. Every rail combines these differently, and the professional who blends them misleads employers, misstates funding and mishandles exceptions. Learn the six words, use them exactly, and half of payroll confusion disappears.
Payroll credits move through ACSS as AFT transactions exchanged between direct clearers during daytime batch windows. Functionally, two rule families govern this exchange: Rule F1, which governs AFT transactions exchanged as Standard 005 files between financial institutions for clearing and settlement, including exchange procedures, processing, settlement of obligations between direct clearers, and exception handling; and Rule F4, which governs AFT transactions exchanged using ISO 20022 messages, the structured-message counterpart for institutions on the modernized path. A bank professional does not need to quote either rule — but must know which one the bank's payroll flow runs under, because file formats, field definitions, edit rules and return mechanics follow from that answer, and because the long coexistence of legacy files and ISO 20022 messages is where truncation and mapping risk concentrates. The detailed message mechanics belong to the programme's AFT and ISO 20022 coverage; this chapter's lesson is architectural: payroll release commits to one of these rule families, and everything downstream — edits, returns, settlement entries — speaks its language.
ACSS defers settlement by design, and the deferral shapes every payroll commitment. Participants exchange AFT credits during daytime batch windows, each direct clearer enters the volumes and values of the items for which it is owed funds, and those entries combine to determine net balances: a single net amount each direct clearer owes to the system or is owed by it. Settlement of the previous day's net balances then occurs during the morning of the following business day, when ACSS settlement account holders meet their net obligations by Lynx payments and the resulting debits and credits across Bank of Canada settlement accounts extinguish the balances. Thousands of employee credits collapse into one funding event per clearer. That collapse is the efficiency of batch — and the reason treasury teams forecast payroll settlement as part of net positions rather than item by item, as Section 9 explains.
Finality in this model is positional and rule-governed, not per-item and instant. When the morning settlement completes, interbank positions are settled finally in central-bank money — yet return rights for the underlying employee credits survive for defined reasons and timeframes: closed or invalid accounts, credits the receiving side cannot post, duplicates and errors the originating side must correct through defined mechanisms. A payroll credit can post to the employee while its interbank position settles later; a collection debit can post to the biller while the payer retains return rights. That is the batch bargain stated precisely: efficiency and reach at the cost of deferred finality and return exposure. Each half without the other misleads — and payroll, with its fixed pay date, is where the bargain's cost is most visible when returns arrive after employees have been told they were paid.
Contrast this with real-time gross settlement, because employers sometimes ask why payroll cannot simply be made final today. In Lynx, each payment settles individually in real time across Bank of Canada accounts, with no netting and no deferred position; once settled, a Lynx payment is final and irrevocable through the system, and recovering a misdirected payment requires a new payment with the beneficiary's agreement. ACSS inverts every one of those properties: items accumulate, positions net, settlement follows in a later window, and defined returns remain available afterwards. A late batch instruction cannot be made today-final merely by paying more; it needs a currently offered eligible rail, such as a bank's Lynx wire service, with its data requirements, price and irrevocability accepted explicitly. The channel may only offer what operations confirms for this file, this amount, this employer, this business day. Never promise same-day finality on batch timing. The Real-Time Rail is not a current production payroll rail in this chapter. Payments Canada currently describes RTR as launching in Q4 2026, with industry solution-assurance testing and participant onboarding underway; any RTR payroll example must therefore be labelled planned/launch-phase capability, not an available substitute for today's AFT service.

The timeline above deserves a slow read, because it answers the employer question behind half of all payroll discussions: when must the file be in, and when will employees see pay. The employer file arrives according to the destination branch's serviceability code and the bank's exchange schedule — relative days, not a quoted hour, because the applicable cutoff comes from the bank's schedule and, for indirect clearers, the agent's timetable behind it. Exchange and clearing fill the days between. Settlement completes on the cycle's morning leg and receiving banks post. Employee availability follows settlement plus receiving-bank posting — not the moment the file was sent, not the moment exchange confirmed delivery. A missed release window can shift the cycle, and a holiday week can shift it further, so every communication for that week should state the confirmed due date and posting expectation rather than explaining the shift after employees complain.
5. Data, identifiers, messages and references
If clearing is the road network, data is the addressing — and payroll fails far more often from bad addressing and thin references than from system outages. Six hundred credits depend on six hundred account triples being correct, six hundred amounts tying to six hundred calculations, and one file's control totals balancing to the penny. The bank's data discipline, captured in three verbs — capture completely, validate early, preserve identity end to end — determines whether exchange, settlement, posting and reconciliation succeed or generate exceptions. This section maps what each payroll credit needs, which references must survive the whole journey, and where the legacy-to-ISO-20022 coexistence changes the payload without changing the discipline.
Domestic routing starts with the Canadian account identifier triple: institution number, transit (branch) number and account number, governed by national routing conventions and validated against the Financial Institutions File and related references that establish reachability. Every payroll credit depends on this triple being correct, because exchange sorts on it: the system must know which clearer serves the destination account before it can position the item. Reachability is therefore a data question before it is a rail question, and an unreachable or malformed destination must be rejected or repaired in the bank's processing — never released to see what happens. Each rail prices that error differently: batch charges it as a return cycle measured in days, a wire would charge it as a new payment. The cheapest place to fix addressing is always before release, which is why Section 3 put routing validation where it did. New-hire banking details and changed details deserve explicit verification against a known-good source, because they are the highest-risk data in the file and the favourite target of the fraud Section 7 describes.
Each AFT payroll file then adds its batch layer on top of the triple: batch headers identifying the originator and the run, item records carrying employee credits with amounts and due dates, and control totals that must balance — the control discipline that lets operations detect a truncated or corrupted file before it poisons clearing. Transaction codes identify what kind of item each record is; return reason codes identify why an item came back. Both code sets are defined by the system's standards, and using them exactly — rather than approximating with free text — is what makes returns machine-processable instead of manually researched. None of this requires quoting any standard. It requires respecting that the standards exist, using current published versions, and validating against them before release.
Messages and files are the carriers, and Canada is living through a long coexistence that payroll operations must engineer for daily. Legacy AFT files under Standard 005 sit alongside ISO 20022-message AFT under Rule F4, with richer structured data on the modernized side, meeting at mappings where truncation and repair risk concentrates. The bank's processing must validate against the destination's schema, map explicitly, log what was truncated or enriched, and carry the original employer and employee references forward. A legal-name field that fits in the new format but truncates in the old one, a reference the employer needs for advice matching that one schema carries and the other drops — these are the unglamorous mapping decisions that decide whether reconciliation in Section 9 runs straight through or becomes a research project. Coexistence is a multi-year condition to be engineered for, not a cutover to wait out.
References are what let humans and systems agree they are discussing the same credit, and five must survive every payroll journey. The bank's internal instruction identifier anchors tracking from intake through investigation. The file and batch references anchor the employer's view of the run — which pay date, which file, which item within it. The clearing trace anchors the system's view through exchange. The return linkage anchors the round trip when a credit comes back, so the return finds its original without manual matching. The employee remittance — employee identifier, pay-period reference, advice linkage — anchors the advice matching that tells the employee what this credit is. Drop any one and a different team pays: drop the internal identifier and investigations stall; drop the file reference and the employer cannot tie reporting to the run; drop the clearing trace and operations cannot match system reports; drop the return linkage and returns become research projects; drop the remittance and the employee phones the payroll manager, who phones the bank.
Two practical consequences follow. First, master-data quality is a payroll control: clean employee banking masters, disciplined hire-and-change procedures and validated account details prevent more exceptions than any downstream repair process. The employers with the smoothest paydays are rarely the ones with the best bank; they are the ones with the cleanest employee master. Second, evidence preservation starts at origination: calculations, approvals, validation results, screening dispositions and release records must be retained retrievably for the full window in which returns, disputes, audits and year-end reporting can arise. Storage is cheap. Reconstruction is expensive. Audit findings are most expensive.
6. Rules, cutoffs, service levels and customer impact
Employers experience rules as promises: will pay land Friday, when can employees use the funds, what will it cost, what reference will appear, what happens if a credit fails. The bank experiences rules as windows, obligations and evidence. This section connects the two — and it does so without stating a single exact cutoff time, because exact times vary by bank, by clearer, by file type and by day, and they move with holidays and calendars. This chapter speaks only in relative windows, and any study note, job aid or employer script that quotes a specific hour from this chapter is misusing it. Binding times come from your bank's published schedules read together with the published system closure calendar. That sentence is worth memorizing.
The rulebook layering is straightforward in shape, and shape is all a payroll chapter requires. By-law No. 3 establishes the system's legal foundation for payment items and ACSS. Rules under it govern what may be exchanged, participant conduct, stream requirements, returns and adjustments, and the obligations of each capacity. Functionally for payroll, Rule F1 governs AFT transactions exchanged as Standard 005 files — exchange procedures, processing, settlement of obligations between direct clearers, exception handling — while Rule F4 governs AFT transactions exchanged using ISO 20022 messages. Standards govern the technical detail: file layouts, encoding, transaction codes, return reason codes. Functionally, every operational question has a binding answer in the published framework, and past practice is never a substitute for checking the current version. The detailed map of which rule governs which mechanic belongs to the programme's AFT and rulebook coverage; here, know the layers, know which family your payroll flow runs under, and keep the habit of checking currency.
Business days anchor everything in payroll. The system operates Monday to Friday excluding holidays, with closures published in the system closure calendar. A Wednesday-evening file does not miss by minutes; it misses the business-day window and belongs to the next one. A pay date that falls after a Monday holiday does not compress the week; it shifts value dates, settlement mornings and return clocks, and every employer communication for that week should reflect the shift proactively. The intake logic that assigns each file to a business-day window at receipt — and communicates that window honestly at receipt — is the single most employer-visible control in this chapter. Channels must never promise what the rail calendar cannot deliver, which means channels and operations must share one clock: the channel may only offer what processing confirms for this file, this amount, this employer, this business day.
Relative windows within the cycle differ by function in ways the timeline diagram makes visible: file intake and validation days when the employer can still repair cheaply, the release window when the file commits to clearing, daytime exchange windows when credits move between clearers, the settlement morning when nets are extinguished, and post-settlement periods when posting, advices, reporting and returns flow. Release before the applicable cutoff means this cycle; after means the next; and late-but-urgent batch is a contradiction the bank should resolve honestly — by offering a same-day-final rail where the payment is eligible and the employer accepts the cost and irrevocability, or by agreeing a revised pay date — not by improvising around the window. For payroll specifically, the honest late-file conversation has a fixed shape: which employees are affected, what the next achievable pay date is, whether any interim support the employer can offer its staff is needed, and what changes so the next run is not late the same way.
Service levels bundle timing with certainty, information and recourse, and the bank's advisory job is to match the payroll event to the bundle. Batch offers low-cost scale with structured returns — at the price of deferred settlement and return exposure. Same-day-final rails offer immediacy and irrevocability — at wholesale pricing with no unilateral recall. The honest conversation compares bundles, not speeds, and selling one at the other's price creates the exact complaints payroll operations dreads: the employer who heard batch timing described as guaranteed Friday finality, and discovers the difference through a return.
Employer communication must reflect finality honestly, using the six words from Section 4 exactly. Sent means released from the bank's processing. Accepted means clearing took it. Settled means interbank value moved finally. Posted means the employee account was credited. Available means the employee may use the funds, subject to the receiving bank's terms. Final means the value cannot be unwound through the settlement mechanism. A payroll posted must always be stated with return-rights awareness in the background: the credit the employee sees can still return for defined reasons, and the employer still owes the pay if it does. Most payroll complaints are vocabulary failures wearing operational costumes: the employer heard sent and understood final, and nobody corrected the translation until employees checked their accounts.
7. Fraud, compliance and operational controls
Controls fail most often not by absence but by placement. A sanctions check that runs after value has settled, a fraud hold that triggers after employees have been told funds are available, a banking-detail verification that starts only after a diversion has cleared — each is a control that exists and still loses, because it runs on the wrong side of the event it was meant to govern. This section places each control family at the point in the payroll flow where it can still change the outcome. Prevention sits before release, detection sits across processing and clearing, and evidence sits everywhere.
Payroll fraud has a shape distinct from other batch fraud, and it attacks at four points. First, initiation: takeover of employer credentials or social engineering of the payroll manager redirects the file or the funding — met with strong authentication, device and behaviour verification, entitlement discipline, and callbacks to known contacts for high-risk changes such as new bureau instructions or changed settlement accounts. Second, the file itself: fictitious employees added to the master, inflated amounts, duplicate runs — met with originator onboarding, segregation between calculation and approval, dual control over file release, and anomaly checks against history that flag the unfamiliar totals a ghost-employee scheme produces. Third, banking-detail diversion: fraudulent change-of-details requests, often by email impersonating employees, redirecting credits to mule accounts — met with verification of every change through a known-good channel, cooling discipline on changed details for high-risk cases, and scoring of incoming credits on the receiving side, since mule networks collect batch credits and move them on within hours. Fourth, the advice layer: forged advices used to support lending or rental fraud — met with advice integrity controls the next section's discussion of advices returns to. Each of these is a before-release control first and an investigation second, because batch recovery runs on return cycles and the diverted funds do not wait.
Authorization controls in payroll look different from the pull-side mandate evidence that collections chapters emphasize, but they are no less real. The employer's authority to instruct, the individuals entitled to approve, the bureau's authority to transmit — each must be established at onboarding, evidenced per run, and preserved for dispute and audit. Dual approval over file release is the headline control: no single person should be able to create and release pay. Amount thresholds that route large or unusual runs to additional approval, segregation between master-data maintenance and payment approval, and time-bound emergency authorities for off-cycle runs complete the picture. Overrides — manual releases, verbal instructions, after-cutoff exceptions — must themselves be controlled, dual-approved, time-bound and reviewed, because the history of payroll losses is largely a history of overrides that bypassed the order, usually under time pressure, usually on a Thursday.
Sanctions, watchlist and related screening gate release. Parties and where applicable remittance text are checked before processing releases to any rail, with three dispositions: pass, false-positive release with documented reason, or true-hit hold with escalation. Payroll files contain hundreds of parties, and a single true hit must hold the tainted items without stranding the clean run — which means the screening process needs item-level hold capability and an employer communication plan that explains a partial hold without leaking the screening reason. Complete, untruncated data matters enormously: truncated employee information creates multi-day false-positive queues and the temptation to release and check later that precedes every screening failure. Log what was checked, when, against which lists, by whom, with what disposition. That log is the difference between a defensible process and an anecdote.
Anti-money-laundering and record-keeping obligations attach to payroll events without being payment approvals. Client identification for the employer, transaction records for the run, and the data feeding prescribed reporting must be captured at origination, preserved untruncated through clearing, and retrievable for the full retention window. Thresholds and filing mechanics belong to the dedicated compliance coverage and current government guidance; this chapter's contribution is the placement rule — capture at initiation, preserve through clearing, report from complete data.
Oversight and audit complete the control plane. The Bank of Canada oversees ACSS under the Payment Clearing and Settlement Act; participant-bank controls still need governance over clearing operations, documented procedures, tested resilience, incident reporting and evidence that controls run every window. Supervisors and audit will ask for exactly what this chapter has been building: who instructed, who approved, what was checked and when, which window carried it, how it settled, where it posted, how exceptions were handled. A bank that keeps that evidence as a by-product of disciplined processing answers easily.
8. Exceptions, investigations and recovery
Every pay cycle breaks differently somewhere in the country, but every break is managed the same way: detect fast, classify correctly, contain within the rail's rights, recover as a new linked event, and reconcile with evidence — while remembering that the employee is still owed pay. Banks that classify first recover cheaply. Banks that act first — re-sending, manually crediting, editing a settled record — create duplicate payments and audit breaks that dwarf the original error. This section teaches the classification and the recovery discipline for payroll. Each mechanism in full — timelines, codes, adjustment flows — belongs to the programme's exceptions coverage; this section summarizes and points there throughout.
Start with the taxonomy, because precise words are the cheapest control in exception handling. A reject happens before clearing: the bank's processing, the gateway or the receiving side refuses the instruction for invalid routing, a closed account, a limit breach, failed screening, missing funding or incomplete data. Nothing settled; the employer repairs and re-originates, and the communication states the reason, the repair path and the next window. A return happens after exchange/processing: the receiving side sends the credit back for a closed or invalid account, an unpostable item, or a defined error condition, with reason codes and timeframes defined by the rulebook. A return may be received after settlement in the employer-facing workflow, but the exact timing depends on the stream and rule. Returns are normal batch traffic, not scandals — but in payroll each return is also an unpaid employee, so the return queue needs a same-day employer notification discipline that other batch flows can soften. A reversal corrects a bank or system error through a defined mechanism — a duplicate file, a wrong amount released by the bank — never by silent editing of a settled record. An adjustment handles the small-value consequences the rulebook allocates: fees, compensation and corrections that keep the economics fair without relitigating the item. An investigation tracks an uncertain outcome: a credit with no confirmation, a return without a matching original, a settlement figure that does not agree.

Return reasons in payroll cluster into a short list worth learning by shape. Account reasons — closed, invalid, frozen — say addressing or account state failed; recourse is master-data repair and a linked re-payment, and the employer's banking-detail verification process gets the audit attention. Administrative reasons — ineligible items, malformed records, duplicates — say the bank's or bureau's own processing failed; recourse is internal, and the employer communication owns the failure plainly. Duplicate-file events deserve special dread in payroll: a file released twice pays everyone twice, and recovery requires defined reversal mechanics plus employee-level communication through the employer, because the bank cannot unilaterally pull settled credits back. Code-level detail and per-stream timelines live in the exceptions coverage; the payroll skill is triage at speed, because the category decides the next step, the owner and the employer message.
Recovery follows one bank-control rule: never mutate history; always create a linked new event. A rejected item is repaired and re-originated with linkage to the original instruction. A returned credit is re-paid as a new linked credit — off-cycle where timing demands it — carrying the original instruction identifier, the clearing trace of the returned item and the new event's own identifier where those references are available. A duplicate file is reversed through the defined mechanism with the original preserved for audit, and any employee communication about returning the duplicate goes through the employer with care and legal awareness. An adjustment is raised as its own entry referencing the original. This linkage is what makes reconciliation possible and what auditors verify. The bank that re-sends the same payment again without linkage has created two payments and will discover the second one from the employer, at the worst moment.
Investigations run on evidence assembled from the participant chain in Section 2. Start from the bank's release record — when, which window, which references — check clearing and posting records, and only then contact the counterparty or agent with a precise, reference-carrying query. For indirect clearers, the agent is part of the investigation path by contract. Status communication follows the vocabulary rule from Section 6: state what is known and what is being done, never upgrade tracked to resolved before the evidence arrives. In payroll, investigation status needs one additional element every other batch flow can soften: the employee impact statement — who is unpaid, what interim arrangement the employer has made, and when the linked re-payment will reach them. Most payroll investigations close within return and reporting cycles; the ones that do not are usually reference failures — which is why Section 5 called reference discipline decisive.
Containment deserves a final word because payroll scale punishes slow containment. A corrupt file, a compromised employer credential, a duplicated release: first stop the bleeding — hold pending releases from the affected source, quarantine the repair queue, notify agents or counterparties where required — and only then diagnose. Containment decisions need pre-assigned authority reachable during every window, not an escalation tree that convenes tomorrow. Classify, contain, recover as linked events, reconcile with evidence — and keep the employer informed at each step, because the employer's workforce is informing itself in real time.
9. Posting, accounting, liquidity, reporting and reconciliation
After settlement comes the reckoning: did every dollar the employer intended arrive where it should, is every ledger entry evidenced, and can the bank prove it. This section follows payroll through posting, accounting, funding and reporting into the four-way reconciliation that closes the run — and introduces the direct deposit advice, the document employees actually read, in its proper place as reporting rather than payment.
Posting is the bank's books catching up with the system's settlement. On the originating side, the employer's funding account is debited for the run total plus any fees, with value dating and narrative references that let the employer's reconciliation match the debit to the file. On the receiving side, each employee account is credited per the receiving bank's posting policy, with availability governed by that policy and the account terms. Posting and settlement are different events on different books — the system's books move interbank value, each bank's books move customer balances — and payroll operations must never describe one as the other. The employer's debit and the employees' credits do not move simultaneously; they are linked by references, not by simultaneity.
Direct deposit advices deserve careful treatment because they are the most-read document in payroll and the least understood by payments newcomers. The advice — the electronic pay stub — is not the payment. It is the explanation of the payment: gross earnings, deductions, contributions, net pay, pay period, year-to-date figures, and the reference linking it to the credit. The payment moves through AFT and ACSS; the advice moves through payroll software, employer portals, email or print, on a parallel track with its own integrity requirements. The two tracks must agree exactly — same net amount, same pay date, same employee — and the reconciliation that checks this agreement is a first-class control, not a cosmetic one. A mismatch between advice and credit generates the most corrosive payroll complaint of all: the employee whose stub says one number and whose account shows another. Advice integrity controls — sequence completeness, amount matching, restricted reprint and reissue, tamper-evident distribution — belong in the bank's review of bureau and employer arrangements wherever the bank has a view, and in employer onboarding everywhere else.
Accounting for the run spans three books. The employer's books recognize salary expense, deduction and contribution payables, and the bank settlement of the net. The originating bank's books recognize the funding debit, fee income, suspense positions for rejects and returns in transit, and settlement entries against clearing accounts. The receiving banks' books recognize the incoming settlement and the employee credits. Each book closes on evidence from the others, and the suspense accounts — holding the value of items neither cleanly posted nor cleanly returned — are where payroll incidents sleep. Suspense needs ownership, ageing and escalation: an unreconciled suspense balance after a pay run is an open promise to someone, and operations should know to whom by name.
Liquidity in payroll is a forecasting discipline with a fixed-date spike. The bank must confirm that available funds or an agreed credit arrangement covers the run under the product terms; many payroll services require employer prefunding, but that is a bank-specific service condition, not an ACSS rule imposed on every employer. The direct clearer funds its net ACSS position on settlement mornings through Lynx legs, with payroll volume forming a predictable component of the net that treasury forecasts by cycle — biweekly peaks the liquidity team can set its calendar by. Indirect clearers fund through their agents under agreed timetables and collateral or limit arrangements. The failure mode to respect is the large run funded late: not a technical default but a cascade — missed window, shifted pay date, six hundred explanations. Funding confirmation before release is the control; everything else is commentary.
Reporting closes the loop to the employer: file acceptance, release confirmation with window assignment, edit rejects with reasons, settlement confirmation, returns with reason codes, and the periodic statements that tie the run together. Good payroll reporting answers four questions without a phone call: did you get my file, when will employees be paid, what failed and why, and what must I do about it. Banks that report this way keep the repair work with the employer during the cheap window; banks that report cryptically inherit the repair work during the expensive one.

Reconciliation is the proof, and payroll reconciliation has four ties, each of which must hold before the run is signed off. Tie one, gross to net: payroll calculations foot and cross-foot, deductions and contributions account for every dollar between gross and net, and the payroll register balances to the pay file. Tie two, net to bank debit: the sum of employee net credits equals the employer funding debit plus separately identified fees, and the bank statement matches the release record. Tie three, bank to clearing totals: released file totals match exchange confirmations and net position entries, with every edit reject explained item by item. Tie four, clearing to employee credits: every released credit is accounted for as posted, returned or rejected, advices match posted amounts, and there are no silent gaps — no credit that left the file and never arrived anywhere on paper. Returns and reversals reconcile as linked pairs, original plus recovery, both referencing the same employee and pay date. Year-end reporting, covered functionally in Section 11's context and the references, reuses this chain: each slip total must trace back through the same four ties, which is why disciplined pay-cycle reconciliation is also year-end preparation. No tie, no sign-off — an unexplained difference is an open investigation, not a rounding.
10. Bank implementation, testing and resilience
Offering payroll services is a commitment to be correct on fixed dates under load, and banks should implement it with that commitment explicit. This section describes what a bank must build, test and sustain to carry employer payroll — people, process, systems and contingency — at the functional level a product owner or operations lead needs. Technical build detail belongs to implementation programmes; the architecture of readiness belongs here.
Implementation starts with the service definition: which employers the bank will serve directly and which through bureaus, which file and message standards it accepts, which rule family each flow runs under, what cutoffs apply per channel and clearer capacity, what funding arrangements apply, what advices and reporting the bank provides or relies on others for, and what the exception service promises — notification times, repair support, re-payment paths. Each element needs an owner and a published statement the front line can quote without improvisation. The bureau programme needs particular care: bureau onboarding standards, file authentication per bureau, the written allocation of duties from Section 2, change-of-detail verification rules, and the right to suspend a bureau feed that repeatedly fails validation. A bureau that files cleanly for a hundred employers is leverage; a bureau that files dirty for a hundred employers is systemic to the bank's operations queue.
Systems readiness spans intake channels, the payment hub or payroll module, screening engines, the ACSS gateway, posting and reporting, and reconciliation tooling — each with capacity planned for payroll peaks, the compressed windows before common pay dates, not for average load. The hub needs the five validation gates from Section 3, screening integration with item-level hold capability, window assignment logic that knows direct and agent timetables separately, and release records that capture every field investigations will later need.
Testing must prove the service before employers depend on it: functional testing of each gate and return reason, connectivity and negative-case testing with each bureau and host-to-host employer, exchange-level testing proving files survive the clearing path, master-data conversion validation before the first live run, and full-cycle dress rehearsals — intake to advices to reconciliation — including a holiday-week variant. Regression testing runs with every format, platform or screening change, since payroll is where a mapping defect becomes six hundred defects at once.
Resilience is the promise that pay date survives failure. Contingency connectivity and alternative file paths cover channel outages. Alternative release and authorization paths cover approver unavailability — named, reachable, time-bound, never improvised. Agent-failure playbooks cover the indirect bank's nightmare: the agent unable to exchange or settle, with pre-agreed rerouting, communication trees and employer messaging drafted before it is needed. Fraud-containment playbooks cover the compromised credential and the diverted file: hold, quarantine, notify, diagnose, in that order. Communication resilience matters as much as technical: employer notification templates for late files, partial releases, return waves and revised pay dates, written in the vocabulary of Section 6 and ready before the incident. And the service must be reviewed after every incident and every peak: what validated well, what repaired slowly, what the employer heard versus what operations meant. Payroll reliability is not a system property. It is a habit of preparation, rehearsal and honest review.
11. Practical Canadian examples
Theory earns its keep in cases. The three examples below are fictional — simplified, anonymized illustrations built from common industry patterns — and each is labelled as such. They are designed to be worked, not just read: trace each on the cycle diagram, name the owner of each stage, and state what evidence each decision left.
Example (fictional): the mid-size manufacturer's payday. An Ontario manufacturer with about six hundred employees runs biweekly payroll through a bureau. The bureau transmits the file to the employer's bank three working days before the Friday pay date. The bank's validation catches fourteen items with account triples that fail reachability — a batch of new-hire details keyed with transposed digits. The bank rejects those fourteen items back to the bureau the same day with reasons, releases the clean balance into the AFT exchange for the cycle, and confirms the window to the employer. The bureau repairs twelve items the next morning and the bank releases them as a linked follow-on file for the same pay date; two items cannot be verified in time and are held for the off-cycle run the following week, with the employer's written agreement and interim arrangements for the two affected staff. Friday morning, five hundred and ninety-eight credits post; returns over the following days are zero. The control lessons: validation caught the defect while repair was cheap; item-level reject-and-release saved the pay date for the clean majority instead of holding the whole file hostage; the linked follow-on file preserved identity end to end; and the two deferred employees were a managed exception with employer agreement, not a surprise discovered on Friday. Ask yourself: where would this story have broken if the bank had released the whole file unvalidated to protect the deadline.
Example (fictional): the failed employee account. A national retailer's payroll includes a long-tenured employee whose account was closed after a fraud incident and replaced — but the employer's master still carries the old account. The credit passes the bank's format checks (well-formed but closed is not detectable by format alone), exchanges normally, and returns after settlement with the closed-account reason. The bank's return process matches the return to the original item through the return linkage, notifies the employer the same day with the reason and the re-payment path, and the employer verifies the new banking details through its HR channel, corrects the master, and authorizes a linked off-cycle credit. The employee is paid three working days after pay date with an apology and, where the employer's policy provides, consideration for any charges the delay caused. The control lessons: format validation cannot catch state failures, which is why master-data verification and return discipline are separate controls; the return linkage made matching instant instead of a research project; the re-payment travelled as a linked new event, keeping the four reconciliation ties intact; and the employer fixed the master, not just the item, so the next cycle did not repeat the failure. Ask yourself: what would the investigation have cost if the return had carried no linkage to the original credit.
Example (fictional): the bonus run on a compressed timetable. A technology company approves annual bonuses on a Monday for payment that Friday alongside nothing else — a standalone run with variable amounts far above normal net pay. The file arrives Tuesday with funding confirmed but with anomaly flags everywhere: totals multiples of the usual, dozens of amounts outside any historical band. Under a naive limit regime this file blocks; under the bank's pre-agreed off-cycle procedure it routes to the named approvers, the employer confirms the run's legitimacy and its funding with dual authorization, screening completes with item-level holds available, and the file releases into the cycle with the window communicated explicitly. Two credits return for invalid accounts; both are re-paid by linked off-cycle credits after verification. Friday holds. The control lessons: anomaly detection did its job by flagging rather than silently passing; pre-agreed off-cycle procedures converted flags into verification instead of into delay or override; approvals were staffed rather than skipped; and the returns were handled by the standard linked-recovery path, proving the exception process works under peak attention as well as routine. Ask yourself: which would have been worse — delaying the verified run to re-check every line, or releasing the flagged run without the employer's explicit confirmation.
Year-end reporting sits behind all three examples as the quiet consumer of payroll discipline. Functionally, the year produces information slips for employees and summaries for the authorities — the documents that state what each employee was paid and what was deducted, contributed and withheld through the year. The payment chain's contribution is evidence: every slip total must trace back through the four reconciliation ties of Section 9 to released files, clearing confirmations, settlement entries and posted credits, with linked recoveries visible as pairs rather than hidden as edits. Banks do not prepare the employer's slips and this chapter gives no tax advice — rates, thresholds, deadlines and filing mechanics belong to current Canada Revenue Agency guidance and the employer's professional advisers. The bank's functional duties are narrower and exact: preserve complete, untruncated records; keep references tying reporting queries to payment evidence; and ensure late-year corrections flow through the same linked-event discipline as every other recovery, so reported totals and moved money agree.
12. Key takeaways and authoritative references
Payroll is the batch flow where operational discipline is most visible and most punished when absent. Keep these takeaways where you can see them on a Thursday afternoon.
- Payroll travels as AFT credit push transactions cleared through live ACSS batch and settled through live Lynx legs to Bank of Canada accounts — deferred net settlement, not real-time finality.
- The employer calculates, authorizes and prefunds; the originating bank validates, screens, approves, releases and warrants; clearing exchanges and positions; the Bank of Canada settles; receiving banks post. Bureaus process but never absorb the bank's duties.
- Validate before release across five gates — employee master, account and routing, amounts and totals, funding, approvals and controls — and repair-or-reject while repair is cheap.
- Timing is relative: files move working days in advance, settlement follows on a later business morning, and employee availability depends on settlement plus receiving-bank posting. Exact cutoffs come from bank schedules and the system closure calendar, never from this chapter.
- Functionally, Rule F1 governs Standard 005 file-based AFT and Rule F4 governs ISO 20022 message-based AFT; know which family your flow runs under and engineer the coexistence mapping with care.
- The advice is not the payment: direct deposit advices explain the credit on a parallel track, and advice-to-credit matching is a first-class control.
- Off-cycle and bonus runs use the same rails, gates and warrant on a compressed timetable — staff the controls, do not skip them.
- Rejects happen before release and repair cheaply; returns happen after settlement and recover as linked new events that still get the employee paid. Never mutate history.
- Reconcile four ties — gross to net, net to bank debit, bank to clearing totals, clearing to employee credits — with no sign-off on unexplained differences.
- Communicate in the six exact words: sent, accepted, settled, posted, available, final. Most payroll complaints are vocabulary failures.
- Year-end reporting consumes the evidence your pay-cycle discipline preserved; this chapter gives no tax advice and states no thresholds — follow current official guidance.
- Test the service before employers depend on it, rehearse holiday weeks and agent failures, and review every peak and incident.
Authoritative references below are official sources only. Rules and standards change; always confirm currency in the current published versions rather than relying on training material.
- Payments Canada — Retail batch payment system: ACSS/USBE scope, direct and indirect clearers, net-balance calculation and morning settlement. https://www.payments.ca/systems-services/payment-systems/retail-batch-payment-system
- Payments Canada — Rules and documentation: current ACSS rule/standard versions and effective updates, including By-law No. 3, Rule F1 and Rule F4. https://www.payments.ca/systems-services/rules-documentation
- Payments Canada — Rule F1, Rules Applicable to Automated Funds Transfer (AFT) Transactions (current PDF): Standard 005 exchange, serviceability, processing, settlement and exception provisions. https://www.payments.ca/sites/default/files/f1eng.pdf
- Payments Canada — Automatic funds transfer: ISO 20022 AFT onboarding, Rule F4 message portfolio, testing and implementation for direct and indirect clearers. https://www.payments.ca/payment-resources/iso-20022/automatic-funds-transfer
- Bank of Canada — Payment systems the Bank oversees: definitions of exchange, clearing and settlement; ACSS and Lynx roles; direct and indirect participation; RTR modernization. https://www.bankofcanada.ca/regulatory-oversight/financial-market-infrastructures/payment-systems-the-bank-of-canada-oversees/
- Bank of Canada — Settlement account access policy for Lynx and ACSS: ACSS net obligations met by Lynx payments, settlement accounts, collateral and contingency requirements. https://www.bankofcanada.ca/core-functions/financial-system/bank-canadas-settlement-account-policies-for-payments-canada-payment-systems/
- Payments Canada — Real-Time Rail payment system: current Q4 2026 launch-phase status, testing and onboarding; not current AFT production. https://www.payments.ca/systems-services/payment-systems/real-time-rail-payment-system
- Payments Canada — System closure schedule: current ACSS business-day and holiday calendar. https://www.payments.ca/system-closure-schedule
- Canada Revenue Agency — File payroll information returns (slips and summaries): current T4/T4A filing, distribution and correction guidance. https://www.canada.ca/en/revenue-agency/services/tax/businesses/topics/payroll/file-information-returns-slip-summaries.html
- FINTRAC — Record keeping requirements for financial entities: applicable client, transaction, EFT record and retention requirements. https://fintrac-canafe.canada.ca/guidance-directives/recordkeeping-document/record/fin-eng
- OSFI — Third-Party Risk Management Guideline: FRFI accountability and controls for outsourced payroll-bureau arrangements. https://www.osfi-bsif.gc.ca/en/guidance/guidance-library/third-party-risk-management-guideline
- Interac — Interac e-Transfer: official product description for the separate consumer/business transfer service. https://www.interac.ca/en/consumers/products/interac-e-transfer/
- Justice Canada — Association By-law No. 3 — Payment Items and the ACSS. https://laws-lois.justice.gc.ca/eng/regulations/SOR-2003-346/index.html
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.