Canadian EFT (ACH)

I am really happy that I stumbled upon this post. I thought that I just wasn't smart enough to figure this out. But in fact the configuration of a data exchange definition to work with CPA005 is not supported by BC out of the box and requires custom development. At least I can stop banging my head against the wall and look to a solution that involves custom coding. Thank you laroslav and I hope that MS is listening.

I can confirm that Canadian EFT out of the box for BC requires coding 99% of the time. Data Exchange definitions tables should at least have the information needed for us to be able to map the format. MS should include a CPA005 format, which is used by BNC, Desjardins and TD https://www.payments.ca/sites/default/files/standard-005.pdf Thanks

Hi all We're beginning to look into this area (EFT in general) and would like to create a small V-team with partners to make sure we're making the right changes. If interested, could you please send me an email at soalex@microsoft.com Thanks in advance! Best regards Søren Alexandersen Program Manager, Business Central Localization

We are in the first phase of our implementation project to move from NAV 2013 to BC SaaS and are just now working on the Canadian EFT setup with our partner. During our testing we have discovered that the OOB data exchange definition which is supposed to be for Royal Bank of Canada (RBC) does not actually follow the RBC ACH specification for some fields as per the document posted on their website (https://www.rbcroyalbank.com/ach/file-451772.pdf). The exported file uses a Julian date with two-digit year, but the RBC spec requires a four-digit year (I confirmed this with our account manager at RBC). There are also several fields which RBC requires to be populated for payments destined to US-based banks, and the OOB file contains blanks for these fields. While confirming with our account manager these differences, they also noted that if a customer submits a file with any errors which result in the file being rejected, the bank will charge a service fee. This has real-world financial implications for customers who do not realize these discrepancies exist in the 'RBC compatible' OOB data exchange definition and attempt to use it as-is.

I'm not sure why this has gone down as a localisation for NA only, it appears that banks in other areas have similar issues - HSBC (and some other banks that use the BACS Standard 18) in the UK require YYDDD formats. Looks like another extension is required...

Can anyone tell me the data format I need to put on the data exchange definition for CYYDDD?