Payroll Through AFT and ACSS. Follow employer payroll from file release through AFT and ACSS processing, settlement, employee posting, rejects and reconciliation.
Block 15 · Chapter 71 of 75
Payroll is where a payment system stops being abstract.
For an employer, the business requirement sounds simple: every employee should receive the right amount on payday. For the bank, that one promise becomes a chain of controlled events involving payroll calculation, file creation, approvals, bank validation, Automated Funds Transfer (AFT) processing, Automated Clearing Settlement System (ACSS) exchange and clearing, settlement, employee posting, returns, reporting and reconciliation.
A payroll run can contain ten payments or tens of thousands. Most items may be perfectly valid while one account is closed, one employee has changed banks, one file is duplicated, one control total is wrong, or one receiving institution returns an item. The operating model therefore has to preserve both the file-level story and the item-level story.
The most useful way to understand Canadian payroll is:
The employer creates a business obligation, the originating financial institution turns that obligation into valid AFT items, ACSS supports exchange and clearing among participants, settlement completes between the relevant clearing participants, receiving institutions post employees, and reconciliation proves that every employee-level outcome agrees with the file, settlement and books.
This final payment story brings together the earlier chapters on AFT, ACSS, payroll, cutoffs, returns, accounting and reconciliation. It does not repeat those chapters. It uses them to run one realistic payroll from Monday preparation to Friday payday, including what happens when the run is imperfect.
At the October 2026 course baseline, current Payments Canada retail-batch rules include Rule F1 for AFT transactions, Rule F4 for AFT transactions exchanged using ISO 20022 messages, Standard 005 for AFT file exchange, Standard 007 for AFT transaction and return-reason codes, and the broader ACSS rules framework. Payments Canada’s July 27, 2026 amendments included F1/F4 changes for stopping and resuming notices of change and a Standard 007 transaction-code update. Banks must use the current rules and standards in production rather than hard-coding examples from training material.
Evidence and scope note
This is a fictional implementation example, not a bank product specification: Northern Maple, its employee population, amounts, dates, file IDs and return IDs are illustrative. Payments Canada rules, standards, ACSS By-law No. 3 and applicable legislation are regulatory or scheme requirements; channels, APIs, approval models, limits, funding models, posting mechanics, status vocabulary and service levels are bank- or product-specific unless this chapter says otherwise. The chapter describes AFT/ACSS, not RTR. As of the October 5, 2026 audit, Payments Canada describes RTR as launching in Q4 2026 and still refers to industry solution-assurance testing; no payroll flow below should be treated as an RTR production capability.
What you should be able to do after this chapter
After working through this chapter, you should be able to:
- trace a Canadian payroll file from employer ERP/payroll system to employee account;
- distinguish employer payroll calculation from bank payment processing;
- explain AFT credit processing within the ACSS retail batch environment;
- explain why file acceptance is not proof that every employee credit succeeded;
- distinguish file validation, item validation, exchange, clearing, settlement and posting;
- explain direct clearer, group clearer and indirect participant responsibilities;
- identify the information and controls needed before payroll release;
- explain payroll cutoffs and why employer-facing cutoffs can be earlier than system deadlines;
- describe how returned payroll credits are handled and reconciled;
- explain how duplicate files should be detected before they become duplicate salaries;
- connect payroll processing to liquidity, accounting, statements and customer reporting;
- identify fraud and operational risks in beneficiary-master changes and file release;
- design a payroll reconciliation model from file control totals to employee-level outcomes;
- describe how ISO 20022-enabled AFT can coexist with legacy AFT formats;
- create realistic functional, integration, operational and resilience test cases for payroll.
Chapter navigator
- The business story
- Participants and responsibilities
- From payroll calculation to bank instruction
- Bank validation and release
- AFT and ACSS processing
- Settlement and employee posting
- Returns, rejects and payroll exceptions
- Accounting, reporting and reconciliation
- Fraud, compliance and operational controls
- Architecture and implementation considerations
- End-to-end payroll scenarios
- Testing, takeaways and authoritative references
1. The business story
Northern Maple Manufacturing is a fictional Canadian employer with 4,800 employees across Ontario, Alberta and British Columbia.
Its payroll cycle closes on Tuesday afternoon for Friday payday.
The payroll team calculates:
- regular salary;
- overtime;
- bonuses;
- deductions;
- expense reimbursements;
- net pay.
By Tuesday evening, the payroll application has produced 4,800 net-pay instructions with a total value of CAD 14.76 million.
The employer does not send “salary” through ACSS. It sends payment data to its bank. The bank validates the file and creates or processes AFT credit items according to the applicable product, format and Payments Canada rules.
The employer's objective is not merely “file accepted.”
The employer needs:
- all intended employees paid;
- no duplicates;
- correct due date;
- clear exceptions;
- returned value identified;
- reconciliation to payroll liabilities.
The bank's objective includes:
- valid customer authority;
- file integrity;
- funding;
- duplicate prevention;
- correct routing;
- rule compliance;
- safe exchange;
- settlement;
- accurate customer accounting;
- exception reporting.
The receiving financial institution's objective includes:
- valid incoming item;
- correct employee account;
- correct posting;
- correct return where posting cannot be completed;
- customer reporting.
ACSS supports the exchange/clearing and settlement framework among clearing participants. It is not the employer's payroll application and it does not maintain employee payroll records.
Why payroll is operationally different
Payroll has five characteristics that increase operational importance.
Concentration.
Thousands of items are released together.
Deadline sensitivity.
Payday is visible immediately to employees.
Data dependency.
One stale bank account can affect one employee while the other 4,799 succeed.
Repeatability.
The same population is sent every cycle, so duplicate detection matters.
Customer impact.
A late salary can affect rent, mortgage, direct debits and overdraft positions.
That is why banks often treat payroll as a priority batch product even though the underlying AFT mechanics are also used for many other disbursements.
2. Participants and responsibilities
A payroll story usually contains more participants than the employee realizes.
Employer
The employer owns:
- payroll calculation;
- employee master data;
- authorization;
- file release;
- payroll funding;
- employee communication about payroll calculation.
The employer should not expect the bank to verify whether an employee's salary amount is correct from an HR perspective.
Payroll/ERP provider
May:
- calculate payroll;
- generate bank file;
- connect via host-to-host, portal or API;
- store account details.
The employer remains responsible for governance over its provider.
Originating financial institution
The employer's bank:
- authenticates employer;
- validates entitlement;
- receives payment instructions;
- validates format and business rules;
- checks duplicates;
- applies product controls;
- processes AFT items;
- participates directly or indirectly in clearing;
- reports status;
- handles returns.
Direct clearer or group clearer
If the employer's bank is not the direct clearer for the relevant settlement relationship, a sponsoring/group clearer may:
- exchange items;
- manage clearing position;
- settle externally;
- report positions to the indirect participant.
The customer still deals with its own bank.
Payments Canada / ACSS
Payments Canada owns and operates ACSS and publishes the rules, standards and procedures governing the retail batch system.
ACSS supports the calculation and settlement of positions arising from eligible retail payment items.
Receiving financial institution
The employee's bank:
- receives eligible payment information;
- identifies beneficiary account;
- posts credit or returns when required;
- reports on employee account.
Employee
The employee's relationship is primarily with:
- employer for pay calculation;
- employee's bank for account posting/service.
The employee normally does not investigate ACSS directly.
Bank of Canada
Payments Canada says the previous day’s ACSS net balances settle during the morning of each business day. Direct clearers maintain ACSS settlement accounts at the Bank of Canada; an ACSS settlement-account holder that is not a Lynx direct participant arranges for a Lynx direct participant to make the settlement payments on its behalf. Direct and indirect structures must therefore be distinguished; not every employee’s bank settles directly at the Bank of Canada.
3. From payroll calculation to bank instruction
The payment process starts before the bank receives anything.
The payroll-timeline diagram above is an illustrative control sequence, not a universal ACSS calendar: miss the applicable product cutoff and the plan changes, not the network speed.
Employee master data
Typical fields:
- employee ID;
- account number;
- financial institution number;
- transit/branch information;
- payment amount;
- pay date;
- employee/reference information.
Sensitive payroll data requires strong access control.
Beneficiary changes
A change of employee bank account is high risk.
Fraud pattern:
- attacker compromises HR email;
- asks payroll to change account;
- next salary goes to mule account.
Controls:
- independent employee verification;
- dual approval for bank-detail changes;
- change audit;
- cooling period where appropriate;
- first-payment monitoring.
The payment bank can add fraud controls, but the employer's master-data governance remains the first line of defense.
File generation
The employer produces a file or ISO 20022 instruction according to its banking arrangement.
Important file-level controls:
- unique file ID;
- creation timestamp;
- originator ID;
- due date;
- item count;
- total amount;
- hash/checksum where channel supports it.
Important item-level controls:
- employee identifier;
- account/routing data;
- amount;
- transaction code/type;
- reference.
Legacy and ISO 20022 coexistence
Payments Canada publishes both:
- Rule F1 for AFT transactions;
- Rule F4 for AFT transactions using ISO 20022 messages.
The bank may therefore need mapping/coexistence between:
- traditional AFT file formats;
- ISO 20022 initiation/processing.
The business meaning must survive mapping.
A richer format does not fix a wrong employee account.
Employer approval
A controlled business payment flow often uses:
- maker;
- checker;
- final releaser.
For very large payrolls, additional approval may be required by employer policy.
The bank should capture evidence of:
- who approved;
- when;
- which file version;
- total value;
- due date.
If a file changes after approval, approval should normally be invalidated and re-obtained.
4. Bank validation and release
A bank should treat payroll release as a sequence of gates.
File integrity
Check:
- file structure;
- encoding;
- record count;
- control total;
- customer/originator ID;
- duplicate file ID;
- valid date.
A mismatched total is not a minor warning. It means the bank cannot prove the submitted population.
Item validation
Check:
- required fields;
- valid institution/transit data;
- account data format;
- amount;
- transaction type;
- due date;
- unsupported characters/data.
Some errors can reject one item. Others can reject the file depending on product and rule.
Customer authorization
Check:
- account entitlement;
- file-release authority;
- signatures/approvals;
- channel authentication.
Funding
Banks use different payroll funding models.
Possible:
- prefunded;
- debit employer on release;
- debit on processing date;
- credit facility.
The bank should know whether employer has funds/credit before it creates settlement exposure.
Duplicate control
Duplicate payroll is one of the highest-impact preventable errors.
Useful duplicate signals:
- same file ID;
- same hash;
- same employer;
- same item count/total;
- same due date;
- repeated employee/amount population;
- resubmission within short window.
Do not reject legitimate off-cycle payroll merely because employee amounts resemble prior file.
Fraud and sanctions
Payroll credits are domestic payments but still need bank controls appropriate to:
- customer;
- beneficiary;
- legal/regulatory policy;
- suspicious activity.
Sanctions/compliance sequencing depends on bank design and applicable obligations.
Fraud controls focus heavily on:
- changed beneficiaries;
- unusual payroll size;
- new destination concentration;
- account takeover;
- file manipulation.
Release
Once validated and authorized, the bank creates the AFT processing population and releases it according to the product's processing calendar.
Customer status should distinguish:
- received;
- validated;
- scheduled;
- released;
- processed;
- returned items.
“Accepted” should not be interpreted as “all employees paid.”
5. AFT and ACSS processing
AFT credits are a major Canadian retail payment type.
Payments Canada Rule F1 governs applicable AFT transactions, while Rule F4 covers AFT exchanged using ISO 20022 messages. Standard 007 defines transaction and return reason-code usage in AFT files. It lists, for example, transaction code 200 as Payroll Deposit and code 900 as an edit reject; the actual code and treatment depend on the transaction and current rule/specification set. Current versions should always be checked in the Payments Canada rules catalogue.
Exchange
The originating participant exchanges eligible items through the ACSS framework.
The payment flow is not:
Employer → Employee
It is more accurately:
Employer
→ Originating FI
→ clearing/exchange arrangement
→ Receiving FI
→ Employee
The settlement relationship sits behind that exchange.
Clearing positions
ACSS is a deferred-net retail batch environment rather than a payment-by-payment RTGS rail.
The 4,800 payroll credits contribute to:
- originating participant's position;
- receiving participants' positions;
- overall settlement calculations.
A bank therefore reconciles:
- individual items;
- aggregate stream/cycle totals;
- participant settlement position.
Direct and indirect participants
If Northern Maple's bank is an indirect clearer:
- its sponsor/group clearer may exchange and settle;
- the employer still sees one bank;
- sponsor position must reconcile to the indirect's customer population.
The implementation should not tell an indirect bank that it owns a direct Bank of Canada settlement account if it does not.
Processing dates
The requested payday must be translated into an eligible processing schedule.
The employer-facing cutoff can be earlier than the system-level exchange timeline because the bank needs time for:
- validation;
- repairs;
- approvals;
- funding;
- operational release.
This is why employers should not submit payroll at the last possible technical moment.
6. Settlement and employee posting
The payroll story has two different financial layers.
Participant settlement
ACSS calculates participants’ net positions from exchanged items. Payments Canada’s public system description says previous-day net balances settle during the morning of each business day, and the Bank of Canada says ACSS settlement-account holders meet net obligations by Lynx payments. This is participant-level settlement, not one Bank of Canada RTGS settlement per salary item.
A direct clearer manages its settlement obligation and funding. A direct clearer that is not a Lynx direct participant uses a Lynx direct participant for the settlement payment.
An indirect clearer manages its position through its clearing agent or group clearer under the applicable arrangement; the sponsor/agent’s external ACSS and settlement responsibilities must not be attributed to the indirect clearer.
Employee posting
The receiving institution receives the item and attempts to credit the employee account.
Possible outcomes:
- valid account → credit;
- account closed → return;
- invalid account → return/reject under applicable processing;
- restricted account → receiving-bank handling under law/policy;
- technical posting delay → exception requiring controlled recovery.
Posting date and value date
Bank implementation determines customer ledger mechanics within applicable rules/product obligations.
The receiving bank must not confuse:
- item received;
- settlement completed;
- employee account credited.
These are related but distinct events.
Employee statement
The employee normally sees:
- payroll credit;
- employer name/reference;
- booking/value date;
- amount.
The statement entry should preserve enough reference information for support.
7. Returns, rejects and payroll exceptions
No payroll chapter is complete without the imperfect run.
Closed employee account
Friday morning:
- 4,799 employees credited;
- one account is closed.
Under Rule F1, an AFT item accepted in the initial file edit and subsequently unposted, dishonoured or refused is returned using the applicable Standard 007 return reason. Subject to rule exceptions, the return is due no later than the business day after the first organizational unit able to decide to dishonour or refuse receives it.
The return travels back through the relevant AFT/clearing process.
The originating bank:
- matches return to original employee item;
- credits or otherwise accounts returned value to employer according to product model;
- reports return reason.
The employer then:
- corrects employee master data;
- pays employee through an appropriate new instruction.
The whole payroll did not fail.
Invalid routing detected before release
If the bank detects invalid account/routing data before exchange:
- item may be rejected/repairable;
- no return exists because payment never reached the receiving side.
Customer reporting should say rejected, not returned.
NSF is not the normal payroll-credit issue
Payroll AFT credit is a push credit funded by the employer.
An employee-side “NSF” concept is not the ordinary reason an incoming salary credit fails. Insufficient funds is more relevant to debit/pull payments.
This distinction helps avoid generic return language.
Duplicate file
If duplicate is detected before release:
- reject/hold duplicate;
- notify employer;
- preserve original file.
If duplicate file has already been externally processed:
- now there may be duplicate employee credits;
- recovery becomes a payment-recovery problem;
- employer/customer remediation must be coordinated.
Wrong employee account
If employer sent wrong but valid account:
- payment may credit another account;
- this is not a format reject;
- employer bank investigates/recovery;
- potential fraud/customer error classification.
Technical uncertain outcome
Suppose the bank sends the payroll file and loses its acknowledgement.
Unsafe:
Controlled:
- identify whether original exchange occurred;
- use file ID/hash;
- reconstruct state;
- only reprocess items proven unsent.
Return reason codes
Standard 007 exists so AFT return reasons are structured.
The bank should preserve:
- external return code;
- normalized internal reason;
- customer-friendly description.
Do not map everything to “payment failed.”
8. Accounting, reporting and reconciliation
Payroll reconciliation should prove the file from employer liability to bank books.
Employer payroll reconciliation
Employer starts with:
4,800 employees
CAD 14,760,000
Bank report:
4,800 accepted
CAD 14,760,000
Later:
4,799 completed
1 returned
Returned amount CAD 3,842.17
The payroll liability should now reconcile to:
- 4,799 employee credits;
- one returned amount awaiting corrective payment.
Bank file reconciliation
Compare:
- file count;
- item count;
- total amount;
- rejected items;
- released items;
- returns.
Clearing reconciliation
Compare:
- outgoing AFT population;
- external exchange/clearing reports;
- participant position.
Settlement reconciliation
Direct clearer:
- ACSS settlement obligation;
- Bank of Canada settlement evidence.
Indirect:
- sponsor settlement report/position.
Customer ledger
The employer account should reflect:
- payroll debit/funding;
- returned credits;
- fees.
General ledger
Bank's GL should tie:
- customer deposit liability;
- settlement position;
- fee income;
- suspense;
- returns.
Exact postings vary by bank.
Three-way control
A powerful payroll control is:
Employer file
↔ bank processed population
↔ external/settlement evidence
↔ customer/GL
Any difference becomes a break with owner.
9. Fraud, compliance and operational controls
Payroll fraud often targets data before the bank payment is created.
Employee-account change fraud
Control at employer:
- authenticated change request;
- independent confirmation;
- maker-checker;
- audit trail.
Control at bank:
- new-account concentration;
- unusual destination;
- changed beneficiary pattern;
- file anomaly.
Payroll account takeover
Attacker compromises corporate banking.
Controls:
- MFA;
- device/session controls;
- dual approval;
- transaction limits;
- file signing where used;
- anomaly monitoring.
Insider risk
An employee with file-generation access may:
- add fake employee;
- change bank details;
- increase amount.
Segregate:
- payroll calculation;
- master-data maintenance;
- payment approval.
Sanctions/AML
This is a bank compliance control, not a claim that ACSS itself screens every payroll beneficiary. Banks should follow applicable requirements for:
- customer due diligence;
- transaction monitoring;
- sanctions screening;
- reporting.
Do not claim that “payroll” exempts a payment from controls. FINTRAC’s definition of electronic funds transfer excludes a transmission carried out by direct deposit or pre-authorized debit, so a domestic payroll credit must not be described as automatically triggering an Electronic Funds Transfer Report. Other PCMLTFA record-keeping, suspicious-transaction, sanctions and institution-specific controls can still apply according to the entity and activity.
Data privacy
Payroll files contain:
- employee names;
- accounts;
- pay amounts;
- identifiers.
Controls:
- encryption;
- least privilege;
- retention;
- masking in support tools;
- secure transmission.
Privacy obligations depend on the employer, bank and province; do not reduce them to one universal statute or imply that an AFT rule sets the privacy policy.
Operational risk
Key risks:
- wrong due date;
- duplicate file;
- late release;
- bank cutoff miss;
- receiving-bank outage;
- return-processing delay;
- settlement funding issue.
10. Architecture and implementation considerations
A real bank payroll architecture may look like:
Employer ERP / payroll
↓
Corporate channel / H2H / API
↓
File intake + validation
↓
Payment orchestration
↓
Fraud / compliance / limits
↓
AFT formatting / mapping
↓
CSN / clearing agent or group clearer (where applicable)
↓
Settlement + receiving FIs
↓
Ledger / statements / reconciliation
File intake service
Responsibilities:
- secure upload;
- virus/security checks;
- schema/format;
- hash;
- customer identification;
- duplicate detection.
Validation engine
Rules:
- routing;
- date;
- amount;
- account pattern;
- transaction code.
Orchestration
Maintains:
- file state;
- item state;
- approvals;
- release;
- external references.
Format layer
Supports:
- legacy AFT;
- ISO 20022 mapping where offered;
- rule-version control.
Reconciliation platform
Must support:
- file;
- item;
- return;
- clearing position;
- settlement;
- ledger.
Observability
Monitor:
- file intake volume;
- rejected files;
- item reject rate;
- duplicate alerts;
- release latency;
- return rate;
- reconciliation breaks;
- payroll cutoff risk.
Scaling
Payroll peaks:
- month-end;
- biweekly cycles;
- holiday adjustments;
- bonuses.
Capacity testing should include concentrated release windows.
Idempotency
Use:
- file ID;
- content hash;
- item identity.
Retrying a technical call must not create a second salary.
11. End-to-end payroll scenarios
Scenario A: clean payroll
Tuesday 18:00:
Wednesday:
Bank:
- validates 4,800 items;
- confirms funding;
- no duplicates;
- schedules processing.
ACSS:
- items exchanged;
- participant positions calculated.
Settlement:
- bank/sponsor fulfills obligation.
Friday:
Reconciliation:
- 4,800 / CAD 14.76m matched.
Customer:
- employer receives completed report.
Scenario B: one closed account
One employee changed banks after payroll master was frozen.
Receiving FI:
- cannot credit;
- returns item with applicable reason.
Originating FI:
- matches return;
- credits returned amount to employer/control account;
- reports employee item.
Employer:
- contacts employee;
- updates account;
- sends off-cycle payment.
Scenario C: payroll submitted twice
Employer user clicks upload twice after first browser response freezes.
Bank receives:
Duplicate engine:
- accepts first;
- blocks second.
No duplicate salaries.
Customer sees:
- original scheduled;
- duplicate rejected as duplicate submission.
Scenario D: bank loses external acknowledgement
File released.
Gateway times out.
Operations does not resend.
It reconstructs:
- external state;
- file/item population.
If accepted:
If not accepted:
- controlled resubmission using original business instruction.
Scenario E: beneficiary-master fraud
Attacker changes 12 employee accounts to one mule account.
Controls detect:
- multiple employees changed to same destination;
- unusual master-data pattern;
- first payroll after change.
File is held for employer verification.
Loss prevented before clearing.
Detailed operating timeline: Monday to Friday
A payroll story becomes easier to control when the bank and employer share a timeline.
Monday: payroll data preparation
HR/payroll teams finalize:
- starters and leavers;
- unpaid leave;
- overtime;
- benefits;
- bonuses;
- tax/deduction inputs;
- bank-detail changes.
A payment problem can be created here even though no bank file exists yet.
Example:
- employee changes account on Monday;
- update is keyed incorrectly;
- Tuesday file contains a valid-looking but wrong account.
The bank cannot infer that the employer intended a different destination.
Tuesday: payroll calculation and approval
The employer:
- runs gross-to-net;
- validates employee count;
- validates total payroll amount;
- reviews exception reports;
- locks payroll.
At this stage useful business controls include:
- comparison to prior payroll total;
- new employee count;
- terminated employee check;
- changed bank details;
- unusually high net pay;
- duplicate employee IDs.
These are employer controls, not ACSS rules.
Wednesday: bank file release
Employer creates bank payment file and obtains approvals.
The bank:
- receives;
- authenticates;
- checks format;
- calculates control totals;
- checks duplicate;
- validates dates/routing;
- confirms funding model;
- schedules.
If something is wrong, Wednesday gives time to repair before Friday.
Thursday: processing and settlement preparation
Depending on the specific product and processing arrangement:
- files/items progress through AFT processing;
- clearing positions develop;
- treasury monitors expected settlement position;
- operations monitors rejects or technical exceptions.
The training point is not to memorize a universal Thursday cutoff. Banks and system rules determine current processing windows.
Friday: employee availability and reconciliation
Receiving FIs post eligible credits according to their processing.
Employer and bank monitor:
- completed items;
- returns;
- employee complaints;
- reconciliation.
A Friday employee complaint should begin from item identity, not from the whole file.
Payroll calendars and holiday risk
Payroll before a holiday requires earlier planning.
Example:
- regular Friday payday;
- Friday is affected by bank/system calendar arrangement.
Employer must know:
- product cutoff;
- valid due date;
- bank processing date.
The bank should calculate dates centrally using governed calendars.
Hard-coding “submit two days before” into payroll software is fragile.
Employer-facing status model
A useful corporate status model separates:
RECEIVED
VALIDATING
REJECTED
SCHEDULED
RELEASED
PROCESSING
COMPLETED_WITH_EXCEPTIONS
COMPLETED
Item status:
VALID
REJECTED
RELEASED
RETURNED
POSTED/COMPLETED where bank evidence supports it
The exact external status vocabulary depends on channel/API.
The principle is that file and item status should not contradict.
Corporate reporting design
Employer needs three reporting layers.
Submission report
- file received;
- count;
- total;
- validation errors.
Processing report
- accepted/rejected items;
- schedule;
- references.
Post-processing report
- returned items;
- return reason;
- amount;
- employee reference.
For large corporates, reports may be, if the bank offers them:
- portal download;
- API;
- ISO 20022 status/reporting;
- host-to-host file.
The report should preserve employer employee/payment references to support payroll reconciliation.
The bank contract controls the actual interface. Payments Canada’s public corporate pain.001/pain.002/camt examples are marked draft or information-only and must not be treated as a production API or message mandate without the bank’s current specification.
File-control totals
Control totals are one of the simplest high-value controls.
Example:
File ID: PAY-2026-09-001
Item count: 4,800
Debit total: CAD 14,760,000.00
Due date: 2026-09-25
The bank independently parses and calculates.
If the file declares 4,800 items but parser finds 4,799:
- reject/hold;
- investigate transmission/truncation.
Do not “fix” the control total.
Hash and non-repudiation
Where supported:
- cryptographic hash;
- digital signature;
- secure channel;
- file receipt timestamp.
These help prove:
- file received unchanged;
- exact version approved.
A bank should not claim a particular signature standard unless its channel implements it.
Maker-checker detail
A typical corporate payroll approval model might be:
Payroll preparer → Corporate approver 1 → Corporate approver 2 → Bank release
Bank may enforce:
- amount threshold;
- role segregation;
- transaction limit.
If approver changes file:
Funding model comparison
| Model | Employer experience | Bank risk |
|---|
| Prefund | funds placed before processing | low customer credit exposure |
| Debit on release | account debited as bank releases | timing/availability control |
| Credit line | payroll can process within facility | credit exposure |
| Sponsor funding | indirect participant funds sponsor | sponsor/client settlement risk |
These are bank/product choices, not one universal Canadian payroll rule.
Treasury view of payroll
Large payrolls can materially affect the bank's ACSS position.
Treasury can forecast using:
- known employer files;
- historical payroll cycles;
- pension/government flows;
- expected PAD inflows;
- returns.
A large file should feed liquidity forecast before settlement, not appear as surprise after clearing.
Direct clearer accounting story
If originating FI is a direct clearer:
- employer account debit/funding recorded;
- AFT credits contribute to ACSS position;
- ACSS net settlement obligation is funded;
- the ACSS obligation is settled by the applicable Lynx payment arrangement;
- customer and GL reconcile to clearing position.
Indirect participant accounting story
If the FI clears through a clearing agent/group clearer:
- employer file belongs to indirect FI;
- the agent/group clearer handles the applicable external exchange and settlement responsibilities;
- the agent reports the position to the indirect FI;
- indirect settles bilateral position;
- indirect reconciles employer account to sponsor report.
This is why participant model matters to accounting.
Employee bank posting controls
Receiving bank should prevent:
- duplicate credit;
- wrong-account mapping;
- posting without valid item;
- return plus credit simultaneously.
Idempotency key should be based on stable transaction identity available in the rail/bank processing.
Return accounting example
Original payroll item:
Employee: EMP-1742
Amount: CAD 3,842.17
Status: processed
Return:
Return ID: RET-991
Original item: EMP-1742 / bank payment ID
Amount: CAD 3,842.17
Reason: applicable account-related return reason
Bank:
- posts returned amount per product accounting;
- does not alter other 4,799 employees.
Employer:
- reopens payroll payable for one employee.
Return timing and customer communication
Do not promise:
“every invalid account will be known before payday.”
Some returns can emerge after processing.
Corporate reporting should distinguish:
- pre-release rejection;
- post-processing return.
Off-cycle payroll
Use cases:
- missed employee;
- termination pay;
- urgent correction;
- bonus.
Controls:
- separate file ID;
- separate approval;
- clear employee references;
- duplicate check against regular payroll.
Off-cycle payment should not be blocked simply because employee/amount resembles regular payroll if business intent is valid.
Bonus payroll
Bonus runs can create anomaly:
- much higher total;
- same employees;
- unusual date.
Fraud engine should avoid blindly declining legitimate bonus season.
Corporate pre-advice and expected-pattern models can help.
New-hire payroll
Risk:
- new account;
- first payment;
- data entry.
Control:
- verify HR master;
- employee self-service with secure verification where used;
- no email-only bank-detail change.
Terminated employee
Employer payroll system decides entitlement.
Bank does not infer termination.
But if employer has account closed/recalled file before release, bank follows valid instruction within product rules.
Payroll privacy and least privilege
Different users need different views.
HR:
Treasury:
- aggregate payroll funding.
Bank payments operations:
- payment data needed to process/support.
Technology:
- masked data where full account not required.
Support tools should not expose all employee salaries unnecessarily.
Fraud scenario: business email compromise
Attacker impersonates CFO:
“urgent payroll account update; use attached bank file.”
Controls:
- file comes through authenticated channel, not email attachment;
- approval workflow;
- bank does not accept arbitrary emailed replacement file.
Fraud scenario: credential compromise
Attacker logs into corporate banking.
Signals:
- new device;
- unusual IP;
- approval at unusual time;
- new payroll destination concentration.
Bank can:
- step up;
- hold;
- call back under risk policy.
Payroll incident: delayed processing
Suppose external connectivity outage delays file.
Operational steps:
- identify files not released;
- assess remaining processing window;
- coordinate with treasury;
- communicate employer;
- use contingency procedure where supported;
- reconcile after recovery.
Do not invent a manual bypass outside the rulebook.
Payroll incident: duplicate external exchange
One file was sent twice due retry defect.
Actions:
- stop further sends;
- identify duplicate population;
- confirm settlement/posting;
- open recovery plan;
- communicate employer;
- incident root cause;
- reconciliation.
The bank cannot solve by deleting second file if employees have already been credited.
Payroll incident: receiving institution outage
Originating side may be fully correct.
Receiving FI may have delayed posting.
Investigation:
- external processing evidence;
- receiving participant status;
- item returns;
- customer communication.
Employer should not resend employees blindly.
Reconciliation design by layer
Layer 1 — ERP to file
Payroll liability = file total
Employee count = file count
Layer 2 — file to bank
submitted count/amount = bank accepted + rejected
Layer 3 — bank to clearing
released items = external accepted + external rejected/unknown
Layer 4 — clearing to settlement
item populations aggregate to participant positions
Layer 5 — returns
processed items = successful outcome population + return population
Layer 6 — accounting
employer debit/funding - returned credits + fees = customer statement effect
Payroll break taxonomy
| Break | Example | Owner |
|---|
| File | count mismatch | employer/bank intake |
| Validation | invalid routing | employer/bank ops |
| Duplicate | same file twice | bank/client |
| External | missing acknowledgement | bank ops/technology |
| Settlement | position mismatch | treasury/recon |
| Posting | employee not credited | receiving FI/investigation |
| Return | unmatched return | payments/recon |
| Accounting | returned value not credited | ledger/recon |
Business analyst requirements pack
A BA should document:
Actors
- employer maker;
- employer checker;
- corporate channel;
- bank;
- sponsor;
- receiving FI.
States
Rules
- date;
- duplicate;
- routing;
- funding;
- limits.
Interfaces
- input;
- AFT;
- settlement;
- ledger;
- reporting.
Exceptions
- reject;
- return;
- unknown;
- duplicate.
Non-functional
- volume;
- security;
- DR;
- audit.
Developer implementation concerns
- streaming parser for large files;
- atomic file state;
- item-level errors;
- duplicate hash;
- idempotent release;
- retry-safe return posting;
- no floating-point money;
- timezone/business-date handling;
- observability.
Tester scenario matrix
| Scenario | Expected result |
|---|
| Valid 4,800 item file | all accepted and reconciled |
| One invalid account format | item/file treatment per rules/product |
| Same file ID twice | duplicate blocked |
| Same hash, different ID | duplicate risk flagged |
| Acknowledgement lost | state queried before retry |
| One account closed | one return, rest unaffected |
| Return duplicated | one customer correction |
| Ledger unavailable | no duplicate external send |
| Sponsor report delayed | recon incomplete, not zero break |
| DR replay | original payment identities preserved |
Performance testing
Test:
- expected largest employer;
- peak concurrent employers;
- holiday compression;
- return bursts;
- report generation.
A bank may process normal daily volume but fail when many employers release payroll within the same hour.
Resilience acceptance
A payroll platform should prove:
- no file loss;
- no duplicate release;
- recoverable item state;
- repeatable reports;
- reconciled external position after failover.
Operational runbook
Before release:
- file accepted;
- totals;
- approval;
- funding;
- cutoff.
During:
- monitor release;
- external acknowledgement;
- breaks.
After:
- returns;
- employer reports;
- settlement/ledger recon.
Final payroll practitioner questions
If one employee says unpaid, the operator should ask:
- Which employee item?
- Was item in submitted file?
- Did bank accept?
- Was item released?
- Was there a return?
- Did receiving FI post?
- Did employer receive exception report?
If 500 employees say unpaid:
- treat as potential incident/common cause;
- do not open 500 independent traces first.
Payroll data lineage: from HR record to employee statement
One of the most useful controls in payroll is end-to-end data lineage. The bank and employer should be able to explain how a field moved from source to destination.
For one employee:
HR employee ID
→ payroll calculation
→ bank payment item
→ AFT transaction data
→ receiving FI posting
→ employee statement
→ employer reconciliation report
Important fields include:
- employee/reference ID;
- account and routing data;
- amount;
- requested pay date;
- employer/originator identifier;
- transaction type;
- remittance/description.
The employee ID may not be transmitted in exactly the same field or format on every rail or bank interface. What matters is that the employer retains a reliable mapping from its payroll record to the bank's payment identity.
Legacy AFT and ISO 20022 semantic mapping
Where a bank supports both traditional AFT files and ISO 20022-based AFT under Rule F4, the integration team needs a canonical business model.
For example:
| Business meaning | Legacy-oriented source | ISO 20022-oriented source |
|---|
| Payroll file | file/batch identifier | group/payment information identifier |
| Employee payment | item/reference | transaction identification |
| Employee account | account field | creditor account |
| Receiving FI | institution/transit data | creditor agent / routing data |
| Pay date | due date | requested execution/settlement-related date as applicable |
| Employer reference | originator/customer reference | end-to-end/remittance-related data |
The exact element mapping follows the bank's implementation and current Payments Canada specifications. The important control is semantic equivalence: a richer ISO 20022 structure must not change who is being paid, how much, or when.
Mapping risks
Common defects:
- leading zeros removed from account/transit data;
- date format shifted;
- amount multiplied/divided by 100;
- reference truncated;
- batch total recalculated incorrectly;
- special characters rejected;
- duplicate item IDs created by conversion.
A bank should test conversion at transaction level, not only compare aggregate totals.
Payroll cutoffs as a customer promise
A bank may advertise:
“Submit payroll by X for Friday pay.”
That customer cutoff includes internal time for:
- file validation;
- repair;
- funding;
- risk controls;
- formatting;
- exchange.
The system-level ACSS processing window is not automatically the corporate-customer cutoff.
Product requirements should therefore identify:
Customer submission cutoff
Internal repair cutoff
Internal release cutoff
External processing window
Payday / requested due date
If the employer misses its product cutoff, the bank should not silently promise the original payday unless a valid alternate service is available.
Holiday-compressed payroll
Consider a week with a Friday holiday or year-end processing constraint.
A payroll team may need to:
- move calculation earlier;
- move approval earlier;
- choose earlier valid processing date.
The bank should provide:
- maintained payment calendar;
- customer-facing date validation;
- warnings before upload/release.
A static spreadsheet in the employer's payroll department is not a strong long-term control.
Payroll around year-end
Year-end payroll can combine:
- bonus;
- final regular salary;
- tax-year reporting;
- statutory deadlines;
- holiday calendars.
Operational risks:
- larger-than-normal total;
- early cutoffs;
- unusual payment date;
- higher support volume.
Fraud systems should understand expected seasonal behavior so a legitimate year-end file is not automatically treated as account takeover solely because the value is high.
Payroll corrections before file release
Suppose the employer discovers one employee should receive CAD 3,950 rather than CAD 3,850.
If the file has not been bank-approved/released:
- correct source payroll;
- regenerate controlled file;
- invalidate prior approval;
- reapprove.
Do not allow an operator to edit one payment directly in bank staging without employer authorization.
Corrections after release
If payment has already been processed:
- create separate corrective payment or recovery process;
- preserve original payroll history.
Examples:
- underpayment → additional off-cycle credit;
- overpayment → employer recovery process, not bank unilateral debit;
- wrong account → payment investigation/recovery.
Employee complaint workflow
Employee says:
“My salary is missing.”
Employer first checks:
- employee was in payroll;
- amount;
- account details;
- bank report.
If bank report shows item returned:
- employer resolves with employee.
If bank report shows processed/no return:
- employer bank traces item.
The employee should not be sent to Payments Canada.
Employer support workflow
Corporate service desk should have access to:
- file ID;
- item search;
- return codes;
- processing date;
- report version.
Support should not need to read raw clearing files for ordinary cases.
Bank operations dashboard
A payroll dashboard can show:
Files
- received;
- rejected;
- scheduled;
- released.
Items
- accepted;
- rejected;
- returned.
Value
- total;
- high-value clients;
- expected settlement impact.
Risk
- duplicate alerts;
- suspicious beneficiary concentration;
- missed cutoff risk.
Reconciliation
- unmatched files/items;
- aged returns.
Operational service levels
A bank can define internal service levels such as:
- file validation response;
- repair escalation;
- return reporting;
- high-severity incident response.
Do not turn internal targets into scheme guarantees unless the external rule actually requires them.
Payroll fraud-control matrix
| Risk | Preventive control | Detective control |
|---|
| HR account change fraud | independent verification | changed-account report |
| Corporate login compromise | MFA, device binding | session anomaly |
| Duplicate file | file ID/hash | duplicate population alert |
| Added fake employee | employer maker/checker | new beneficiary analysis |
| Insider file edit | immutable approved file | before/after audit |
| Mule concentration | beneficiary controls | many employees → one account |
| Bank retry defect | idempotency | external/ledger duplicate recon |
Sanctions and false-positive operations
A high-volume payroll may contain a beneficiary name that triggers sanctions screening.
A bank should:
- follow compliance policy;
- avoid holding the entire file unnecessarily if architecture can isolate an item and rules/product support that treatment;
- preserve the reason for any delayed item;
- avoid telling the employer sensitive screening details that should not be disclosed.
The exact screening model is bank- and jurisdiction-specific.
AML monitoring
Payroll itself is a legitimate high-volume activity, but transaction monitoring can identify:
- payroll company sending to unrelated high-risk accounts;
- sudden use of many new beneficiaries;
- employer account used for activity inconsistent with profile.
Fraud monitoring and AML monitoring can share data but have different purposes.
Payroll and customer limits
Corporate payment limits can apply at:
- file total;
- item;
- daily customer total;
- approver authority.
Limit hierarchy should be clear.
Example:
- user can approve CAD 5m;
- file is CAD 14.76m;
- two approvers/treasury role required.
Payroll and overdraft/credit
If employer uses credit:
- facility availability checked;
- payment release can consume facility;
- treasury/credit systems must agree.
A file should not be released based on a stale balance snapshot when settlement exposure is material.
Settlement forecast interface
Payroll system can publish expected value to treasury before release.
Illustrative event:
ExpectedPayrollSettlement
Client: Northern Maple
Amount: 14,760,000 CAD
ProcessingDate: YYYY-MM-DD
Confidence: approved
Treasury combines with other flows.
Sponsor/group clearer concentration
A group clearer may support many indirect institutions.
Payroll peaks across several clients can aggregate.
Sponsor controls:
- client funding;
- limits;
- net positions;
- concentration.
An indirect FI should know its sponsor cutoff and reporting model.
Reconciliation detail: one-to-many hierarchy
Use hierarchy:
PayrollRun
└─ File
├─ Item EMP-1
├─ Item EMP-2
└─ ...
Each item links to:
- bank transaction;
- return if any.
File links to:
- clearing cycle;
- settlement position.
This prevents a return from being lost in a batch-level summary.
Return matching algorithm
Preferred:
- original transaction identity/reference;
- account/routing + amount + date as secondary;
- manual review if ambiguous.
Do not match only by amount.
Payroll fees
Bank may charge:
- file fee;
- item fee;
- service plan.
Employer reconciliation should separate:
- payroll principal;
- bank fees.
A fee reversal or waiver is not payroll-item return.
Statement design for employer
Useful statement/reference:
- “Payroll file PAY-2026-09-001”;
- total;
- separate returned item credits.
Corporate detailed report can carry employee IDs.
Avoid exposing full employee salary detail on generic treasury statement if not necessary.
Audit evidence pack
For a material payroll run:
Employer file + hash
Approval evidence
Validation report
Funding evidence
Release record
External acceptance
Clearing/settlement report
Return report
Customer ledger
Reconciliation sign-off
Incident/case records if any
Production change control
A change to:
- parser;
- mapping;
- duplicate logic;
- holiday calendar;
- return code mapping
can affect thousands of salaries.
Release controls:
- regression data;
- parallel comparison;
- rollback;
- post-deployment monitoring.
Example implementation acceptance criteria
Given a 4,800-item payroll with valid control totals,
when bank accepts and releases it,
then every item has immutable bank identity and the file status derives from item states.
Given the same file is retried after a timeout,
when its original state is already accepted,
then no second external population is created.
Given one employee account is closed,
when a return arrives,
then only that employee item is marked returned and the returned value is reconciled to employer.
Disaster recovery test
Scenario:
- 4,800 item payroll;
- 2,000 items released;
- data centre fails;
- system restarts.
The recovery design must know:
- which 2,000 were externally sent;
- which 2,800 were not;
- which acknowledgements were received;
- whether any settlement occurred.
Do not restart from item 1.
Cyber containment
If corporate channel compromise suspected while payroll is staged:
- freeze unreleased files;
- verify employer;
- preserve evidence.
If already released:
- identify external state and recovery options.
High-volume incident management
If multiple employers affected by same bank defect:
- open central incident;
- link customer cases;
- communicate consistently;
- reconcile by employer/file.
Do not let 100 relationship managers independently instruct technology to resend files.
Payroll quality metrics
- file STP rate;
- item reject rate;
- return rate;
- duplicate attempts;
- average validation time;
- files near cutoff;
- reconciliation breaks;
- aged returns;
- customer complaints per 1,000 files.
Root-cause analysis
Examples:
- wrong routing data → employer master-data issue;
- duplicate file → channel timeout + retry;
- missing items → parser defect;
- late posting → receiving FI incident;
- settlement mismatch → clearing/reconciliation issue.
Root cause should drive prevention, not simply close the customer case.
Final payroll story
Northern Maple's first run completes:
- 4,799 credits;
- one returned closed account.
The bank's final corporate report states:
- file processed;
- returned item EMP-1742;
- CAD 3,842.17 returned;
- reason;
- reference.
Employer:
- reopens payable to employee;
- updates account;
- sends off-cycle payment.
Bank:
- reconciles original payroll;
- reconciles return;
- no unresolved suspense.
The payroll story is complete because every item has a provable financial outcome, not because a file once said “accepted.”
Roles and responsibilities at payroll go-live
A payroll implementation often fails at handoffs rather than at file syntax.
A practical RACI-style view is:
| Activity | Employer payroll | Employer treasury | Bank payments | Bank treasury | Receiving FI |
|---|
| calculate salary | accountable | informed | no | no | no |
| employee account data | accountable | informed | validates format | no | uses for posting |
| file approval | responsible | may approve | verifies entitlement | no | no |
| funding | provides/authorizes | accountable | checks | monitors settlement | no |
| AFT release | no | no | accountable | informed | no |
| ACSS position | no | no | monitors | funds | receives own position |
| employee posting | no | no | no | no | accountable |
| return handling | updates payroll | informed | coordinates originator side | no | creates return |
| reconciliation | payroll liability | cash position | payment/settlement | settlement account | own posting |
The exact organizational titles vary, but ownership must be explicit.
Payroll day operational checklist
Before the release window:
- confirm expected employer files;
- confirm system availability;
- confirm settlement calendar;
- confirm unusually large payrolls;
- confirm any known client funding concerns.
As files arrive:
- validate control totals;
- check duplicates;
- check scheduled date;
- confirm approvals;
- monitor risk exceptions.
After release:
- monitor external acceptance;
- identify any missing acknowledgement;
- feed expected settlement value to treasury;
- monitor returns.
At payday:
- prioritize employer/employee-impact incidents;
- reconcile file outcomes;
- publish final reports.
Payroll support triage by symptom
No employees paid
- likely file-level, release, settlement or major receiving incident.
One employee unpaid
- likely item data, return, receiving-bank posting.
Many employees at one receiving bank unpaid
- possible receiving-participant incident.
Employees paid twice
- duplicate file/item or posting issue.
Employer debit missing but employees paid
- serious bank accounting exposure.
This triage quickly narrows the investigation.
Payroll incident severity
High severity examples:
- duplicate salary population;
- major file not released near payday;
- settlement mismatch;
- mass employee non-credit;
- customer debit/credit inconsistency.
Lower-severity but still controlled:
- one returned closed account;
- one report description issue.
Severity should reflect:
- employee count;
- value;
- payday proximity;
- financial exposure;
- regulatory/customer impact.
Employer file versioning
If the employer replaces a file before release:
PAYROLL-001 v1 → cancelled/superseded
PAYROLL-001 v2 → approved/released
The bank should not keep both active.
Controls:
- explicit supersession;
- new hash;
- reapproval;
- audit.
Partial repair policy
Some banks may permit correction of non-economic technical fields under controlled operations.
The policy should define:
- which fields;
- who can change;
- whether customer reapproval is required.
Never let operations change:
- amount;
- employee account;
- pay date,
without the appropriate customer authorization process.
Payroll reconciliation sign-off
A final sign-off can record:
File count/value: matched
Bank accepted population: matched
External/clearing population: matched
Settlement position: matched
Returns: matched
Employer ledger: matched
Open breaks: 0 / documented
This turns “payroll went fine” into evidence.
Audit questions
An auditor or control reviewer should be able to ask:
- How did the bank know the employer approved this exact file?
- How did it prevent the same file being sent twice?
- How did it prove all accepted items entered processing?
- How did it reconcile net settlement to item populations?
- How were returns matched?
- How did it recover from a lost acknowledgement?
- Can it reproduce the business date/cutoff decision?
A mature payroll platform answers from stored evidence, not employee memory.
Implementation anti-patterns
Avoid:
- manual file renaming as duplicate control;
- spreadsheet-only cutoff calendar;
- one batch status with no item state;
- direct database edits to repair employee accounts;
- reuploading whole file after a timeout;
- hard-coded return reason text;
- treating settlement total as proof every employee was credited;
- nightly-only reconciliation for a high-priority payroll incident.
Migration from one payroll bank/channel to another
A corporate may move from:
- portal upload to host-to-host;
- legacy AFT file to ISO 20022;
- one sponsoring bank to another.
Migration controls:
- parallel test files;
- beneficiary/account preservation;
- date mapping;
- control totals;
- duplicate protection across old/new channels;
- cutover freeze;
- reconciliation.
The largest migration risk is sending the same payroll through both old and new paths.
Parallel-run testing
During implementation, use a masked/test payroll population and compare:
source payroll count/amount
old output
new output
mapped bank item data
Every employee item should be equivalent.
Non-functional acceptance
A payroll solution should meet:
- volume peak;
- timely validation;
- secure file handling;
- recoverability;
- traceability;
- reporting;
- audit.
The best payroll implementation is not the one with the prettiest upload screen. It is the one that can prove, under pressure on payday morning, exactly what happened to every employee payment.
Final bank-readiness review for payroll
A payroll service is ready only when the bank can demonstrate the whole control chain under production-like volume.
The release review should confirm:
- corporate entitlements and approvals work;
- the largest expected file parses within the operating window;
- file and item duplicate controls are independent;
- AFT format/version mapping is controlled;
- dates and holiday calendars are configuration-driven;
- employer funding is visible before settlement exposure is created;
- direct or sponsor settlement positions reconcile;
- returned items are matched automatically where possible;
- employer reporting preserves employee references;
- disaster recovery does not resend already processed items.
Payroll risk scenario: one bank receives a large concentration
Suppose 1,100 employees use the same receiving FI and that FI has a posting incident.
The originating bank may see:
- the payroll file accepted;
- settlement progressing;
- a cluster of employee complaints.
A good incident process identifies the receiving-FI concentration and opens one common investigation while retaining all affected employee item identities. It does not resend those 1,100 credits.
Payroll risk scenario: employer funding reversal
An employer appears funded when the file is accepted, but a separate account event later reduces available funds before the bank's settlement obligation.
The bank's product/credit design must define:
- when funds become committed;
- whether funds are reserved;
- whether credit exposure exists.
Payroll processing should not rely on a non-binding balance check taken hours earlier.
Payroll quality gate
Before the bank marks a payroll run operationally closed, it should know:
- all accepted items have a final processing disposition;
- all returns received to date are matched;
- the settlement position is reconciled;
- employer accounting/reporting is correct;
- any open employee investigations are individually tracked.
That is the standard behind the phrase “payroll completed.”
Practical production acceptance workshop
Before signing off a payroll product, run one workshop with business, operations, treasury, technology and reconciliation using a single realistic file. Ask each team to identify the same employee item and show its state in their system.
The employer/business view should show:
- employee payment in approved payroll;
- bank file and due date.
Payments operations should show:
- file and item identity;
- validation;
- release;
- external state.
Treasury should show:
- expected settlement impact and actual position.
Reconciliation should show:
- item population;
- settlement evidence;
- employer ledger;
- any return.
Then deliberately inject one exception:
- account closed;
- duplicate file;
- lost acknowledgement;
- ledger outage.
The product is ready only if every team reaches the same financial conclusion without resending completed payments.
Payroll handover documentation
The production runbook should contain:
- current rules/source links;
- supported formats;
- customer cutoffs;
- escalation contacts;
- file/item states;
- duplicate handling;
- return reason mapping;
- settlement model;
- reconciliation steps;
- incident procedures.
Runbooks should be versioned. A payroll team using last year's calendar or an obsolete return mapping can create customer harm even when the application code is correct.
Final learning check
If you remember only five things:
- payroll file acceptance is not employee credit;
- file and item states must both exist;
- ACSS settlement is a participant-position story, not one RTGS settlement per salary;
- returned employees are handled individually without rewriting successful credits;
- duplicate prevention and reconciliation are as important as the file format.
12. Testing, takeaways and authoritative references
Functional tests
- valid payroll file;
- invalid file control total;
- invalid institution/transit;
- future due date;
- duplicate file;
- duplicate item;
- employer insufficient funding;
- one rejected item;
- account closed return;
- wrong valid account;
- off-cycle payroll.
Integration tests
- channel to payment hub;
- payment hub to AFT formatter;
- external acceptance;
- return intake;
- ledger;
- corporate reporting;
- reconciliation.
Resilience tests
- file upload interrupted;
- acknowledgement lost;
- gateway outage;
- duplicate retry;
- ledger outage after settlement;
- return file delayed;
- DR replay.
Data-quality tests
- employee account leading zeros;
- invalid characters;
- duplicated employee ID;
- amount precision;
- due-date holiday;
- truncated remittance.
Operational acceptance
Before launch:
- payroll runbook;
- cutoff calendar;
- emergency contacts;
- manual fallback;
- reconciliation sign-off;
- high-value employer escalation;
- fraud playbook;
- duplicate controls.
Final takeaways
Payroll is not one payment. It is a controlled population of individual credits tied to one employer business event.
The bank must preserve:
- file identity;
- item identity;
- processing date;
- clearing/settlement evidence;
- employee outcome;
- returns;
- accounting;
- reconciliation.
The strongest payroll operation can answer, for any one employee:
Was this item authorized, released, cleared, settled, credited or returned, and what evidence proves it?
Authoritative references
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.