Funds Transfer Batch File Specifications ¶

Version 2.3

March 3, 2023

PDF download

Table of Contents

Funds Transfer Batch File Specifications

Funds Transfer Processing Overview ¶

Payroc supports batch-based merchant processing for the following payment types:

PAD - Pre Authorized Debit Transactions (client to merchant)
DBP - Direct Bank Payment Transactions (company to merchant)
CHQ - Electronic cheque image transactions (client to merchant)

Payroc supports real-time merchant processing for the following payment type:

PAD - Debit Transactions (client to merchant)
PAD - Account verification credit transaction (merchant to client, small amounts only)
EFT - Credit payments (merchant to vendor)

Processing flow summary:

Depending on the payment type, merchant submits real-time transaction request (PAD,EFT) or merchant creates batch file in PAD, DBP, CHQ format and submits to Payroc for processing.
If the file structure is bad and the entire file is rejected, it needs to be corrected and re-submitted. The same file creation number can be re-used in that case.
Payroc validates transactions, accepts good transactions and rejects bad transactions.
Real-time response is generated or Acknowledgement report for each batch file submitted and sent back to merchant.
Only good transactions are accepted for further processing the following way:
Payroc submits debit part of a transaction to the bank.
If debit was successfull, Payroc submits credit part of a transaction to the bank.
If debit was rejected, no credit will be sent to the bank.
If debit was returned later (after credit was issued), credit payment is reversed.
Payment Reconciliation report is generated after credit part is submitted to support reconciliation of payments per Terminal ID.
For PAD payments, if client debit was successful but merchant credit part gets rejected by the bank, Credit Reject report will be created and sent back to the merchant. Merchant should contact Payroc helpdesk in order to resolve the issue, provide correct account number and get payment adjustment processed by our merchant services.
For EFT payments, if merchant debit was successful but vendor credit part gets rejected by the bank, an automated attempt will be made by Payroc’s system to return money back to merchant’s account by issuing credit adjustment transaction. Credit Reject report will be created and sent back to the merchant for informational purpose.

PAD/DBP Batch files are submitted using SFTP Upload to Payroc server. In order to obtain SFTP account set up, you need to provide Payroc with the IP address that you will be connecting from. Payroc will set up your SFTP account and provide the server name, user ID, and key to be used for file delivery and retrieval of the reports.

Once you connect to Payroc’s SFTP server you will find 4 sub-directories:

pad_in
pad_out
dbp_in
dbp_out

The “in” directories are used for uploading or dropping off batch files for processing. Batch files must be submitted prior to the daily cut-off time specified by Payroc.

The “out” directories are used for downloading or retrieving report files. Once report files have been retrieved, you should remove them from “out” directories.

File Naming Convention ¶

File naming conventions for PAD/DBP batch types:

Batch Type	Naming Style
PAD files	YYYYMMDDhhmmss_pad.COMPANYID
PAD Acknowledgment Report	YYYYMMDDhhmmss_pad.COMPANYID_acknowledgement.csv
PAD Payment Reconciliation Report	YYYYMMDDhhmmss_reconciliation_rpt_pad.COMPANYID or YYYYMMDDhhmmss_reconciliation_rpt_v2.0_pad.COMPANYID
DBP files	YYYYMMDDhhmmss_dbp.COMPANYID
DBP Acknowledgment Report	YYYYMMDDhhmmss_dbp.COMPANYID_acknowledgement.csv
DBP Payment Reconciliation Report	YYYYMMDDhhmmss_reconciliation_rpt_dbp.COMPANYID

Notes: Merchant incoming file name contains file creation date and time followed by batch type. Acknowledgement report will be created for each file received by Payroc system and will reflect the same file. Payment Reconciliation report name contains date and time when Payroc has issued payments to merchants.

PAD/DBP Batch File Format ¶

Incoming batch files are comma separated values (CSV) files and all fields must be present, even if empty. All characters entered must be ASCII 7 bit (Unicode is not supported).

Each file consists of five record types with all fields required in each record type.

File Structure ¶

Each batch file must have one file header record, one or more batch header records, one or more detail debit records within a batch, one or more batch trailer records, and one file trailer record.

This table details the record types:

Record Identifier	Fields	Description
A	7	FILE HEADER RECORD The file header record contains information about the entire file. There is one file header for each file, and it must be the first record in the file.
X	9	BATCH HEADER RECORD The batch header record contains information about the merchant. This record must precede detail transaction records for associated merchant. Multiple merchant batches allowed per file.
D	7	DETAIL DEBIT RECORD The detail debit records contain information about the client’s transaction. Multiple detail records allowed per batch.
Y	4	BATCH TRAILER RECORD The batch trailer record contains summary of the merchant batch. This record must occur at the end of each batch, and it’s compared to matching batch header record for validation.
Z	3	FILE TRAILER RECORD The file trailer record contains summary of the entire file. There is one file trailer record per file, and it must be the last record in the file.

The following is an example of record sequence within a file:

⇓ File Header (A)
⇓ Batch Header for Merchant 1 (X)
⇓ Detail Debit Record (D)
⇓ Batch Trailer for Merchant 1 (Y)
⇓ Batch Header for Merchant 2 (X)
⇓ Detail Debit Record (D)
⇓ Detail Debit Record (D)
⇓ Batch Trailer for Merchant 2 (Y)
⇓ Batch Header for Merchant 3 (X)
⇓ Detail Debit Record (D)
⇓ Detail Debit Record (D)
⇓ Detail Debit Record (D)
⇓ Batch Trailer for Merchant 3 (Y)
⇓ File Trailer (Z)

Record Layouts ¶

All fields in each record are required.

Two data types are used in the file:

N: Numeric
A/N: Alphanumeric

Character set permitted for each data type is as follows:

N: Numbers 0-9
A/N: Letters, numbers and special characters including “=”, “-“,”_”, “.”, “*”, “$”

File Header ¶

#	Field Name	Length	Type	Req	Description
1	Record Type	1	AN	Y	“A” - fixed
2	Company ID	10	AN	Y	Value to be provided by Payroc
3	File Creation Number	6	N	Y	File creation number must be incremented by one per each payment type submitted (PAD or DBP)
4	File Creation Date	8	N	Y	Date the file was created, in YYYYMMDD format.
5	File Type Indicator	4	AN	Y	“PROD” or “TEST” Depending on whether the file is a test or production file
6	Version Indicator	4	AN	Y	“0020” - fixed value for version 2.0
7	Payment/Batch Type	3	A	Y	“PAD”: Pre-Authorized Debit batch “DBP”: Direct Bank Payment batch

Batch Header ¶

#	Field Name	Length	Type	Req	Description
1	Record Type	1	AN	Y	“X” - fixed
2	Batch Number	6	N	Y	Must be incremented by one for each batch submitted within a file
3	Batch Payment Type	1	AN	Y	“D” - debit payments “C” - credit/refund payments**
4	Transaction Type Code	3	N	Y	“431” - fixed value
5	Merchant Terminal ID	8	AN	Y	Terminal ID provided by Payroc
6	Charge Description	30	AN	Y	Payee description to appear on client’s statement, typically merchant business name
7	Bank ID	3	N	Y	Merchant’s bank ID
8	Branch Transit Number	5	N	Y	Merchant’s transit number
9	Account Number	12	AN	Y	Merchant’s bank account number

Detail Debit/Credit Record ¶

#	Field Name	Length	Type	Req	Description
1	Record Type	1	AN	Y	“D” - debit transaction “C” - credit transaction**
2	Client ID	29	AN	Y	A unique value to represent the client / payor
3	Amount	10	N	Y	Total transaction amount 10-digit field with 2 implied decimal places ($1.00 should be submitted as “100”); No decimal point or dollar sign allowed
4	Bank ID	3	N	Y	Client’s bank ID
5	Branch Transit Number	5	N	Y	Client’s transit number
6	Account Number	12	AN	Y	Client’s bank account number
7	Reference Number	15	AN	Y	Unique value used to represent each transaction/payment for a merchant
8	Effective Date	8	N	N	Date when the debit transaction is to be processed If date is not specified then the debit will be included in the next daily run Effective Date can only specify a date up to 30 days in future

Note: Credit/refund transactions can only be submitted if a debit transaction is submitted in error and needs to be reversed. Credit/refund will be validated and rejected if a debit transaction with matching Terminal ID, Reference Number, and Amount was not previously processed.

Batch Trailer Record ¶

#	Field Name	Length	Type	Req	Description
1	Record Type	1	AN	Y	“Y” - fixed
2	Batch Payment Type	1	AN	Y	“D” - debit payments “C” - credit/refund payments**
3	Batch Record Count	8	N	Y	Total number of detail debit or credit records in the batch
4	Batch Amount	14	N	Y	Total value of the batch 14-digit field with 2 implied decimal places ($1.00 should be submitted as “100”); No decimal point or dollar sign allowed

File Trailer Record ¶

#	Field Name	Length	Type	Required	Description
1	Record Type	1	AN	Y	“Z” - fixed
2	File Trailer Count	5	N	Y	Total number of detail debit and credit records in the file
3	File Trailer Net Amount	14	N	Y	Total value of the entire file calculated based on total debits minus total credits. 14-digit field with 2 implied decimal places ($1.00 should be submitted as “100”); No decimal point or dollar sign allowed Trailing negative sign is included if the file total is negative.

Batch File Validation - Acknowledgement ¶

Once the batch file is received and processed by Payroc’s system, the Acknowledgement report is created and placed in corresponding “out” directory on the SFTP server. The acknowledgement report will indicate whether the file was accepted for processing or if there were any errors with the file.

If the file structure is bad and the entire file is rejected, it needs to be corrected and re-submitted. The same file creation number can be re-used in that case.
If partial rejects are found (transactions or batches), Payroc will not do any further processing for these items. Such transactions will be included in Acknowledgement report with reject code and reason.

For details about report layout and reject types, refer to bellow section:

* Acknowledgment Report

Payment Processing - Reconciliation ¶

Only good transactions are accepted for further processing the following way:

Payroc submits debit part of a transaction to the bank.
If debit was successfull, Payroc submits credit part of a transaction to the bank.
If debit was rejected, no credit will be sent to the bank.
If debit was returned later (after credit was issued), credit payment is reversed.
Payment Reconciliation report is generated after credit part is submitted to support reconciliation of payments per Terminal ID.
For PAD payments, if client debit was successful but merchant credit part gets rejected by the bank, Credit Reject report will be created and sent back to the merchant. Merchant should contact Payroc helpdesk in order to resolve the issue, provide correct account number and get payment adjustment processed by our merchant services.
For PAD Account verification credit transaction, if merchant debit was successful but client credit part gets rejected by the bank, an automated attempt will be made by Payroc’s system to return money back to merchant’s account by issuing credit adjustment transaction. Credit Reject report for terminal id will be created and sent back to the merchant for informational purpose.

For details about report layout and reject types, refer to bellow sections:

* Payment Reconciliation Report - Version 1.0

* Payment Reconciliation Report - Version 2.0

* Reject Codes - associated with PAD,DBP,EFT processing

* Return Codes - associated with PAD,DBP,EFT processing

* Credit Reject Report

CHQ Image Processing ¶

Batch File Submission ¶

CHQ Batch files are submitted using SFTP Upload to Payroc server. In order to obtain SFTP account set up, you need to provide Payroc with the IP address that you will be connecting from. Payroc will set up your SFTP account and provide the server name, user ID, and key to be used for file delivery and retrieval of the reports.

Once you connect to Payroc’s SFTP server you will find 2 sub-directories:

chq_in
chq_out

The “in” directories are used for uploading or dropping off batch files for processing. Batch files must be submitted prior to the daily cut-off time specified by Payroc.

The “out” directories are used for downloading or retrieving report files. Once report files have been retrieved, you should remove them from “out” directories.

File Naming Convention ¶

File naming conventions for CHQ batch types:

Batch Type	Naming Style
CHQ files	YYYYMMDDhhmmss_chq.COMPANYID
CHQ Acknowledgment Report	YYYYMMDDhhmmss_chq.COMPANYID_acknowledgement.csv
CHQ Payment Reconciliation Report	YYYYMMDDhhmmss_reconciliation_rpt_chq.COMPANYID YYYYMMDDhhmmss_reconciliation_rpt_v2.0_chq.COMPANYID

Notes: Merchant incoming file name contains file creation date and time followed by batch type. Acknowledgement report will be created for each file received by Payroc system and will reflect the same file. Payment Reconciliation report name contains date and time when Payroc has issued payments to merchants.

CHQ Batch File Format ¶

Submitted client document shall follow X9 file specification details, implementing the Accredited Standards Committee’s X9-100-187-2008 image exchange file format. In addition, Payroc Canada will use the Payments Canada (PC) Standard 015 standards, in sending or receiving Image Cash letters. Please note, Payments Canada was formerly known as the Canadian Payments Association (CPA).

This file supports only Cheque Debit transactions. No credit/refunds can be submitted this way.

File Structure ¶

Each batch file must have one File Header record, one or more Cash Letters within File, one or more Bundles within each Cash Letter, one or more Detail records and Image records within each Bundle, and one File Trailer record at the end.

This table details the record types:

Record Type	Description
01	FILE HEADER RECORD The file header record contains information about the entire file. There is one file header for each file, and it must be the first record in the file.
10	CASH LETTER HEADER RECORD The cash letter header record contains information about the company. Multiple cash letter batches allowed per file.
20	BUNDLE HEADER RECORD The bundle header record contains information about the merchant. Multiple bundle batches allowed per cash letter.
25	CHEQUE DETAIL RECORD The cheque detail record contain information about the client’s transaction. Multiple detail records allowed per bundle.
26	CHEQUE DETAIL ADDENDUM A RECORD Additional transaction information. One record for each record 25.
28	CHEQUE DETAIL ADDENDUM C RECORD Additional transaction information. One record for each record 25.
50	IMAGE VIEW DETAIL RECORD This record should be created for both front and back of the image file.
52	IMAGE VIEW DATA RECORD This record should be created for both front and back of the image file.
70	BUNDLE CONTROL RECORD The bundle trailer record contains summary of the merchant batch.
90	CASH LETTER CONTROL RECORD The cash letter trailer record contains summary of the company batch.
99	FILE TRAILER RECORD The file trailer record contains summary of the entire file. There is one file trailer record per file, and it must be the last record in the file.

Payroc Canada specific Fields to submit ¶

Cash Letter Header Record (Type 10),Field Nr.10 : Expected value is Company Name, should match CHQ Batch File extention COMPANYID. See the “File Naming Convention”.
Bundle Header Record (Type 20),Field Nr.7: Expected value is Terminal ID assigned by Payroc Canada.
Bundle Header Record (Type 20),Field Nr.8: Expected value is Bundle Sequence Number(Batch Number). Incremental value, unique within the whole CHQ file.
Cheque Detail Record (Type 25),Field Nr.8: Expected value is Client reference number. Should be unique per merchant and client, unique identifier for each transaction.

The following is an example of record sequence within a file:

⇓ File Header (01)
⇓ Cash Letter Header for Company (10)
⇓ Bundle Header for Merchant 1 (20)
⇓ Cheque Detail Record (25)
⇓ Cheque Detail Addendum A Record (26)
⇓ Cheque Detail Addendum C Record (28)
⇓ Image View Detail Record Front (50)
⇓ Image View Data Record Front (52)
⇓ Image View Detail Record Back (50)
⇓ Image View Data Record Back (52)
⇓ Bundle Trailer for Merchant 1 (70)
⇓ Bundle Header for Merchant 2 (20)
⇓ Cheque Detail Record (25)
⇓ Cheque Detail Addendum A Record (26)
⇓ Cheque Detail Addendum C Record (28)
⇓ Image View Detail Record Front (50)
⇓ Image View Data Record Front (52)
⇓ Image View Detail Record Back (50)
⇓ Image View Data Record Back (52)
⇓ Cheque Detail Record (25)
⇓ Cheque Detail Addendum A Record (26)
⇓ Cheque Detail Addendum C Record (28)
⇓ Image View Detail Record Front (50)
⇓ Image View Data Record Front (52)
⇓ Image View Detail Record Back (50)
⇓ Image View Data Record Back (52)
⇓ Bundle Trailer for Merchant 2 (70)
⇓ Cash Letter Trailer for Company (90)
⇓ File Trailer (99)

Batch File Validation - Acknowledgement ¶

Once the batch file is received and processed by Payroc’s system, the Acknowledgement report is created and placed in corresponding “out” directory on the SFTP server. The acknowledgement report will indicate whether the file was accepted for processing or if there were any errors with the file.

If the file structure is bad and the entire file is rejected, it needs to be corrected and re-submitted. The same file creation number can be re-used in that case.
Cash Letter Rejects and Bundle Rejects will both be treated as a Batch-level Reject.
Cash Letter Reject will cause rejects for all Bundles under the same Cash Letter and all incorporated transactions.
Bundle Reject will cause reject for a single Bundle and its transactions.
Transaction Reject will cause single transaction reject.
Accepted transactions will be saved to Payroc’s Database for further processing.
Rejected transactions will temporarily be saved to Payroc’s Database with “rejected” status for reporting purpose. No further processing will be done.
Rejected transactions will be included in Acknowledgement report with reject code and reason.

For details about report layout and reject types, refer to bellow section:

* Acknowledgment Report

Payment Processing - Reconciliation ¶

Only good transactions are accepted for further processing the following way:

Payroc submits debit part of a transaction to the bank.
If debit was successfull, Payroc submits credit part of a transaction to the bank.
If debit was rejected, no credit will be sent to the bank.
If debit was returned later (after credit was issued), credit payment is reversed.
Payment Reconciliation report is generated after credit part is submitted to support reconciliation of payments per Terminal ID.
For CHQ payments, if client debit was successful but merchant credit part gets rejected by the bank, Credit Reject report will be created and sent back to the merchant. Merchant should contact Payroc helpdesk in order to resolve the issue, provide correct account number and get payment adjustment processed by our merchant services.

For details about report layout and reject types, refer to bellow sections:

* Payment Reconciliation Report - Version 1.0

* Payment Reconciliation Report - Version 2.0

* Reject/Return Codes - associated with CHQ processing

* Credit Reject Report

EFT Payments Processing ¶

Transaction Submission ¶

EFT payments are Credit payments submitted by merchant in order to pay their vendor or supplier.

Transactions are available only by submitting real-time request with Payment API application. Payroc validates transaction, accepts good transaction and rejects bad transaction. Real-time response is generated and sent back to merchant.

Payment Processing - Reconciliation ¶

Only good transactions are accepted for further processing the following way:

Payroc submits (merchant) debit part of a transaction to the bank.
If debit was successfull, Payroc submits (vendor) credit part of a transaction to the bank.
If debit was rejected, no credit will be sent to the bank.
Credit delay (default of 3 days) is applied to these transactions to allow enough time for debit rejects to arrive from the bank.
Payment Reconciliation report is generated after credit part is submitted to support reconciliation of payments per Terminal ID.
For EFT payments, if merchant debit was successful but vendor credit part gets rejected by the bank, an automated attempt will be made by Payroc’s system to return money back to merchant’s account by issuing credit adjustment transaction. Credit Reject report will be created and sent back to the merchant for informational purpose.

For details about report layout and reject types, refer to bellow sections:

* Payment Reconciliation Report - Version 1.0

* Payment Reconciliation Report - Version 2.0

* Reject Codes - associated with PAD,DBP,EFT processing

* Return Codes - associated with PAD,DBP,EFT processing

* Credit Reject Report

Reports ¶

Acknowledgment Report ¶

This report will be generated for every funds transfer batch file processed. If the entire file is processed successfully, then the report will contain only a file header record with the file status code of “0000”.

If a batch is rejected then the file status code in report header contains the error code (not “0000”), followed by Batch Reject record.

If a transaction is rejected then the file status code in report header contains the error code (not “0000”), followed by Batch Reject record, followed by Transaction Reject record.

CSV format is used for report files with Length column in tables specifying the maximum field length.

File Header Record ¶

#	Field Name	Length	Type	Req	Description
1	Record Type	3	AN	Y	Record Type: “FHD”
2	Company ID	10	AN	Y	From the incoming batch’s file header.
3	File Creation Number	4	N	Y	From the incoming batch’s file header.
4	File Creation Date	8	N	Y	From the incoming batch’s file header.
5	Batch Header Record Count	12	N	Y	Total number of batches received.
6	Detail Record Count	12	N	Y	Total number of payments received.
7	Total File Amount	14	N	Y	Total value of the file received. Trailing negative sign will be included if the file total is negative.
8	File Status Code	4	N	Y	File Acknowledgement Status Codes: “0000”: Accepted “0001”: File out of balance “0002”: Batch level reject “0003”: Transaction reject “0004”: Batch and transaction reject “0005”: Detail Record Count out of balance “0006”: Invalid File Format “0007”: Invalid File Header “0008”: Invalid Version Number NOTE: Status Codes 0001, 0005, 0006, 0007, and 0008 will cause the entire file to be rejected.
9	Reject Reason	60	AN	Y	Details of the rejection reason.

Batch Reject Record ¶

#	Field Name	Length	Type	Req	Description
1	Record Type	3	AN	Y	Record Type: “BRJ”
2	Batch Number	3	N	Y	From the incoming batch’s file header. This field will be blank, in case the Cash Letter rejected.
3	Terminal ID	8	AN	Y	From the incoming batch’s file header.
4	Batch Reject Reason Code	4	N	Y	Batch Reject Reason Codes: “1001”: Invalid count “1002”: Batch out of balance “1003”: Invalid terminal ID “1004”: Invalid bank ID “1005”: Invalid transit number “1006”: Invalid bank account number “1007”: Bank Information Mismatch “1008”: Invalid Payment Type “1009”: Invalid Batch Number “1010”: Invalid Charge Description “1011”: Count Exceeds Threshold “1012”: Amount Exceeds Threshold Note: Following reject codes are associated with CHQ processing: “1019”: Images within Bundle Count Error “1021”: Bundle Count Error “1022”: Items within Cash letter Count Error “1023”: Cash Letter Total Amount Error “1024”: Images within Cash Letter Count Error
5	Batch Total	14	N	Y	From the incoming batch’s file header. From the Cash Letter Control Record, (Type 90),in case of CHQ processing.

Transaction Reject Record ¶

#	Field Name	Length	Type	Req	Description
1	Record Type	3	AN	Y	Record Type Value “TRJ”
2	Terminal ID	8	AN	Y	From the incoming batch’s Batch Header record.
3	Client ID	29	AN	Y	From the incoming batch’s Detail Debit or Credit record.
4	Reference Number	15	AN	Y	From the incoming batch’s Detail Debit or Credit record.
5	Payment Type	1	A	Y	“D”: represents debit. “C”: represents credit/refund
6	Amount	10	N	Y	Total transaction amount
7	Effective Date	8	N	N	Date when the debit transaction is to be processed.
8	Transaction Reject Reason Code	4	N	Y	Transaction Reject Reason Codes: “2001”: Invalid Amount “2002”: Invalid Bank ID “2003”: Invalid Bank Transit Number “2004”: Invalid Bank Account Number “2005”: Invalid Reference Number “2006”: Duplicate Reference Number “2007”: Invalid Client ID “2008”: Invalid Effective Date “2009”: Refund No Match “2010”: Amount Exceeds Limit “2016”: MTD Count Exceeds Limit “2017”: MTD Amount Exceeds Limit Following reject codes are associated with CHQ processing: “2020”: Images missing “2021”: Invalid Image Data “2022”: Invalid Image Serial Number “2023”: Invalid External Processing Code “2024”: Invalid Endorsement Date “2025”: Invalid Image Creator Date “2026”: Invalid Image View Format Indicator “2027”: Invalid Image View Compression Algorithm “2028”: Invalid View Side Indicator “2029”: Invalid View Descriptor “2030”: Invalid Digital Signature Indicator

Payment Reconciliation Report - Version 1.0 ¶

CSV format is used for report files with Length column in tables specifying the maximum field length.

Version 1.0 supports debit transactions only - Payment type “D”.

Merchant Summary Record ¶

#	Field Name	Length	Type	Description
1	Record Type	4	AN	“SUMM” - fixed value
2	Payment Date	10	AN	YYYY-MM-DD
3	Terminal ID	8	AN	Value from the incoming batch’s Header Record.
4	Gross Payment Amount	14	AN	Total value of payments processed Negative amounts will have a leading minus sign.
5	Gross payment Count	5	N	Total number of payments processed
6	Gross payment Fee	12	N	Total amount of fees deducted.
7	Reject Item Amount	12	N	Total rejected item amount.
8	Reject Item Count	5	N	Total count of rejected items.
9	Reject Item Fee	12	N	Total amount of fees deducted for rejecting items.
10	Return Item Amount	12	N	Total returned item amount.
11	Return Item Count	5	N	Total count of returned items.
12	Return Item Fee	12	N	Total amount of fees for returned items.
13	Net Amount	14	N	The net amount per terminal ID. Negative amounts will have a leading minus sign.
14	Adjustments	14	N	The adjustment to the merchant balance. Negative amounts will have a leading minus sign.
15	Previous Balance	14	N	The merchant’s previous balance. Negative amounts will have a leading minus sign.
16	Current Balance	14	N	The merchant’s current balance. This is the previous balance plus adjustments plus current days net amount. Negative amounts will have a leading minus sign.
17	Funds Transferred	14	N	The credit amount transferred to the merchant’s bank account. Negative amounts will have a leading minus sign. If the merchant is setup for fees to be billed separately then the total fees will be included in optional Fees Billed field. If “Payment Status” field is HOLD then the funds released will be zero. If “Payment Status” field is PENDING then the funds released will be zero.
18	Payment Status	8	AN	Status of payment. Values: PAID/HOLD/PENDING
18	Fees Billed	8	N	Total amount of fees collected via debit posted to merchant account. Field is optional and only included if the merchant is setup for fees to be billed separately Leading negative sign is included to specify that the amount is a debit.

Transaction Details Record ¶

#	Field Name	Length	Type	Description
1	Record Type	4	AN	“TDTL” - fixed value
2	Payment Date	10	AN	YYYY-MM-DD
3	Terminal ID	8	AN	Value from the Summary Record.
4	Client ID	10	AN	Value from the incoming batch’s Detail/Credit Debit Record.
5	Reference Number	15	AN	Value from the incoming batch’s Detail/Credit Debit Record.
6	Amount	12	N	Value from the incoming batch’s Detail/Credit Debit Record.
7	Status	10	AN	Status of payment. Values: PROCESSED/RETURNED/REJECTED/DUPLICATE
8	Reason Code	4	N	If the payment has been rejected or returned, then this field will contain the reason code of the returned or rejected item from the bank.
9	Reason Text	256	AN	If payment has been rejected or returned then this field will contain the description of the reject or returned item from the bank.
10	Reject/Return Item Fee	12	N	This field will contain the fee for the reject or returned item.

Note: For Reason Code more details please refer to following Reason Codes section.

Adjustment Details Record ¶

#	Field Name	Length	Type	Description
1	Record Type	4	AN	“ADTL” - fixed value
2	Adjustment Date	10	AN	YYYY-MM-DD
3	Terminal ID	8	AN	Unique ID assigned to the merchant. Same value with the Summary Record.
4	Adjustment Reference Number	15	AN	Reference number for the adjustment automatically generated by Payroc.
5	Amount	12	N	Adjustment amount. Negative amounts will have a leading minus sign. Value from PAD Admin website inputs.
6	Transaction Reference Number	10	AN	Reference number for the original transaction will be included if applicable. Field will be blank for merchant level adjustments.
7	Reason	256	AN	Details on reason for the adjustment.

Note: Adjustment Details are optional records, are only included when company Reconciliation Report Adjustment Show is setup.

Payment Reconciliation Report - Version 2.0 ¶

CSV format is used for report files with Length column in tables specifying the maximum field length.

Version 2.0 supports debit and credit/refund transactions - Payment types “D” or “C”.

Merchant Summary Record ¶

#	Field Name	Length	Type	Description
1	Record Type	4	AN	“SUMM” - fixed value
2	Payment Date	10	AN	YYYY-MM-DD
3	Terminal ID	8	AN	Value from the incoming batch’s Header Record.
4	Gross Payment Amount	14	AN	Total value of payments processed Negative amounts will have a leading minus sign.
5	Gross payment Count	5	N	Total number of payments processed
6	Gross payment Fee	12	N	Total amount of fees deducted.
7	Reject Item Amount	12	N	Total rejected item amount.
8	Reject Item Count	5	N	Total count of rejected items.
9	Reject Item Fee	12	N	Total amount of fees deducted for rejecting items.
10	Return Item Amount	12	N	Total returned item amount.
11	Return Item Count	5	N	Total count of returned items.
12	Return Item Fee	12	N	Total amount of fees for returned items.
13	Net Amount	14	N	The net amount per terminal ID. Negative amounts will have a leading minus sign.
14	Adjustments	14	N	The adjustment to the merchant balance. Negative amounts will have a leading minus sign.
15	Previous Balance	14	N	The merchant’s previous balance. Negative amounts will have a leading minus sign.
16	Current Balance	14	N	The merchant’s current balance. This is the previous balance plus adjustments plus current days net amount. Negative amounts will have a leading minus sign.
17	Funds Transferred	14	N	The credit amount transferred to the merchant’s bank account. Negative amounts will have a leading minus sign. If the merchant is setup for fees to be billed separately then the total fees will be included in Fees Billed field. If “Payment Status” field is HOLD then the funds released will be zero. If “Payment Status” field is PENDING then the funds released will be zero.
18	Payment Status	8	AN	Status of payment. Values: PAID/HOLD/PENDING
18	Fees Billed	8	N	Total amount of fees collected via debit posted to merchant account. Value will only be provided if the merchant is setup for fees to be billed separately Leading negative sign is included to specify that the amount is a debit.

Transaction Details Record ¶

#	Field Name	Length	Type	Description
1	Record Type	4	AN	“TDTL” - fixed value
2	Payment Date	10	AN	YYYY-MM-DD
3	Terminal ID	8	AN	Value from the Summary Record.
4	Client ID	10	AN	Value from the incoming batch’s Detail/Credit Debit Record.
5	Reference Number	15	AN	Value from the incoming batch’s Detail/Credit Debit Record.
6	Payment Type	1	AN	“D”: represents debit. “C”: represents credit/refund
7	Amount	12	N	Value from the incoming batch’s Detail/Credit Debit Record.
8	Effective Date	8	N	Date in format YYYY-MM-DD when the debit transaction is to be processed. Value will only be included if an Effective Date was provided for Pending transaction.
9	Status	10	AN	Status of payment. Values: PROCESSED/PENDING/RETURNED/REJECTED/DUPLICATE Transactions with future Effective Date will be reported with status of PENDING.
10	Reason Code	4	N	If the payment has been rejected or returned then this field will contain the reason code of the returned or rejected item from the bank.
11	Reason Text	256	AN	If payment has been rejected or returned then this field will contain the description of the reject or returned item from the bank.
12	Reject/Return Item Fee	12	N	If payment has been rejected or returned then this field will contain the fee for the reject or returned item.

Note: For Reason Code more details please refer to following Reason Codes section.

Adjustment Details Record ¶

#	Field Name	Length	Type	Description
1	Record Type	4	AN	“ADTL” - fixed value
2	Adjustment Date	10	AN	YYYY-MM-DD
3	Terminal ID	8	AN	Unique ID assigned to the merchant. Same value with the Summary Record.
4	Adjustment Reference Number	15	AN	Reference number for the adjustment automatically generated by Payroc.
5	Amount	12	N	Adjustment amount. Negative amounts will have a leading minus sign. Value from PAD Admin website inputs.
6	Transaction Reference Number	10	AN	Reference number for the original transaction will be included if applicable. Field will be blank for merchant level adjustments.
7	Reason	256	AN	Details on reason for the adjustment.

Note: Adjustment Details are optional records, are only included when company Reconciliation Report Adjustment Show is setup.

Credit Reject Report ¶

The report shows credit rejects only. It can be created on two levels: * Company level - for EFT Payments (vendor credit transactions) * Terminal level - for PAD account verify credit transactions

Credit Reject report has the same format like Payment Reconciliation Report Ver 1.0. For details about report layout and reject types, refer to this sections:

* Payment Reconciliation Report - Version 1.0

Reason Codes ¶

Reject Codes - associated with PAD,DBP,EFT processing ¶

Reason Code	Reason Text
101	INVALID INST
102	INVALID ACCOUNT
900	EDIT REJECT

Note: Reject Codes are subject to change

Return Codes - associated with PAD,DBP,EFT processing ¶

Reason Code	Reason Text
901	NSF (DEBIT ONLY)
902	ACCOUNT NOT FOUND
903	PAYMENT STOPPED/RECALLED
905	ACCOUNT CLOSED
907	NO DEBIT ALLOWED
908	FUNDS NOT CLEARED (DEBIT ONLY)
909	CURRENT/ACCOUNT MISMATCH
910	PAYOR/PAYEE DECEASED
911	ACCOUNT FROZEN
912	INVALID/INCORRECT ACCOUNT NO
914	INCORRECT PAYOR/PAYEE NAME
915	NO AGREEMENT EXISTED
916	NOT ACCORDING TO AGREEMENT - PERSONAL
917	AGREEMENT REVOKED - PERSONAL
918	NO CONFIRMATION/PRE-NOTIFICATION - PERSONAL
919	NOT ACCORDING TO AGREEMENT - BUSINESS
920	AGREEMENT REVOKED - BUSINESS
921	NO CONFIRMATION - BUSINESS

Note: Return Codes are subject to change

Reject/Return Codes - associated with CHQ processing ¶

Reason Code	Reason Text
001	Account closed
004	Account transferred to you
008	Cannot trace
009	Intended payee not paid
013	Counterfeit item
014	Duplicate item
016	Drawer deceased
020	Forged/unauthorized signature
021	Forged endorsement
022	Funds frozen/not cleared
030	Insufficient funds (NSF)
031	ICP item unable to process
032	Lost or stolen prior to issue
033	Material alteration
034	MICR mismatch
035	Missing image or image not usable
036	No chequing privilege
037	Non conforming signature
038	Not eligible for clearing
039	Not for us
040	Payment stopped/recalled
041	Post dated
042	Refer to maker
043	Refused by payor/payee
044	Stale dated
045	Unauthorized PAD
046	Words and figures differ
047	Wrong amount/wrong currency
049	Wrong interest calculation

Note: Return Codes are subject to change