Processing CODA files

CODA, or geCOdeert DAgafschrift is a bank statement or ‘Coded statement of account’ filetype used in Belgium.

The reconciliation process allows you to update and confirm your payment data in Salesforce. FinDock turns CODA files into a Transaction Set with Transaction records that are processed using Guided Matching.

Like other bank statements, CODA files are uploaded to a specific Salesforce Chatter group to be parsed by FinDock. FinDock requires a SEPA target for the bank account from which you receive CODA files.

For more information on the general Processing bank statement processing flow, please read our Processing bank statements article.

CODA reconciliation process

FinDock automatically picks up new CODA files that are uploaded to Chatter and processes them as illustrated below.

1. Processing is started by uploading a CODA bank statement file to the Chatter group designated for file exchanges.
2. ProcessingHub picks up the file from Chatter and extracts the contents into a Transaction Set and Transaction records that are added to Salesforce.
3. Based on the file type of the Transaction Set record, the appropriate Guided Matching setup is attached to the Transaction Set record.
4. Guided Matching is triggered by the Transaction record insert.
5. Guided Matching completes matching and enriching based on the specified rule set.

CODA file structure

FinDock parses CODA files following the structure set out by Febelfin, the Belgian Federation for the Financial sector, as documented in the Coded statement of account (CODA) description (PDF). This document contains every detail on CODA, so it’s worth checking out if you wish to understand CODA reconciliation further.

Fixed Width files

CODA files are structure Fixed Width data files. Fixed Width files are arranged in columns, but instead of the columns being separated by a character like a comma or semicolon every row is the same length. Every column has their own fixed width.

ID(10) Name(15) Address(25) Amount(7)

This is complicated by the fact that, in the case of CODA, what data is available can be determined by the content of other columns. So unlike with a CSV or Excel file, each row in the file can have a different structure, and not every row is a separate transaction.

Transaction types

A CODA file consists of transactions identified by a transaction ID. A transaction can consist of several cash movements, for instance when fees are deducted or exchange rates are applied, captured by movement records.

When the transaction type code starts with 0 or 1, FinDock creates Transaction records for the transaction entries. However, if subtype 5 is present, FinDock skips the type 1 entry and instead creates a Transaction record with the details from the subtype 5 entry.

When the transaction type code starts with 2 or 3, the transaction is treated as a summary transaction and ignored. Only the underlying transactions subtypes 6 or 7 lead to Transaction records in Salesforce.

Coded Statement of Account 3.1 Type

Movement and Information records

A transaction contains detailed data in the form of movement records, which can in turn have information records with additional information. A transaction’s movement and information data stored in the Raw XML field on the Transaction record could look like follows:

21000100009876546498751245     00000001976111801912180015000007013X000001mAZbQAM/abcdefg                           19121823801 0
2200010000                                                     0000123456                         KREDBEBB                   1 0
2300010000BE12345687952177                  EURJAN JANSEN                                                                    0 1
31000100019876546498751245     001500001001JAN JANSEN                                                                        1 0
3200010001JAARGETIJDENLAAN 150 B16           1050 BRUSSEL                                                                    0 0

The rows starting with a 2 are movement records, where 21 is the main movement record and the rows starting with 22 and 23 store additional data about the movement. The rows starting with a 3 are information records, where 31 is the main information record and the rows start with 32, and possibly even 33 store additional information.

Each type of record (21, 22, 23, 31, 32, 33) has its own structure. A movement record starting with 21 for instance has the following structure.

2|1|0001|0000|2007211901244519 |0000000000506000|210720|00150000|0 |210720|198|0|1| |0|

The detailed structure of all records can be found in Annex I of the Coded statement of account (CODA) starting at page 14.

Example: Data record 2.1 - "movement record"

Guided matching for CODA

FinDock provides managed and suggested Guided Matching rules for CODA. You can add your own Guide Matching rules to the predefined rule sets.

Using Guided Matching for CODA

To start reconciliation of CODA, upload your file to Chatter. The file is picked up by FinDock and transformed into Transaction records. FinDock creates a Transaction record in Salesforce for each transaction record in the CODA file, with the movement records as data in the Raw XML field.

Transactions can also be grouped or summarized in a transaction record in the file. In those cases FinDock only creates Transaction records from the detailed records and the summary transaction is left out. For more information about summarized transactions, please read section 3. Coding of the transaction, specifically section 3.1 type of the Coded statement of account (CODA) description linked above.

Matching rule behavior of managed rules

Once Transaction records have been created, Guided Matching will take over. With a set of pre-configured Guided Matching rules, FinDock:

1. Maps fields from the CSV (as stored in the ‘Raw Message’ field) to the Transaction
2. Extracts relevant data (see below for mapping)
3. Searches for existing Installments based on the extracted data
   1. If found, sets the Contact based on the existing Installment
   2. If not found:
      1. Ask the user for Contact information by providing a search bar that allows you to both search and select an existing Contact, as well as create a new Contact.
      2. Creates a new Installment with the selected contact
4. Processes the Installment by updating the amount and changing the status if applicable.

The managed rules create mapping for Transaction as outlined in the table below.

Extending Guided Matching rules for CODA

FinDock does not parse bank specific rules for unstructured communication out of the box. You can however parse this data by extending the out-of-the-box provided Guided Matching rules yourself or executing business logic on the Additional Entry Information field where the communication is stored.

For instance, if you know that the first 18 characters of the (unstructured) communication contains the CampaignId present in your Salesforce environment, you could either:

• extract the CampaignId from the Additional Entry Information with a Regex rule on Campaign into a free field on the Transaction record and then Query the campaign based on the extracted Id.
• directly parse the CampaignId with a Fixed Width rule of your own on the RAW XML field where the original CODA movement and information records with regards to this Transaction are stored.

Or if you want to parse the address of a detailed information record (starting with 31 and 32) with structured communication, you could use the Fixed Width rule to get the Street based on its position in the record. You can limit the extraction of these characters to when the record itself indicates the communication is structured and contains a specific set of data to prevent extracting data from records that do not provide the right data.

For instance, in the example below we extract the Street from positions 11-45 on line 32 in the Raw XML field, but only when position 40-43 on line 31 is ‘1001’: a structured communication (1) with data concerning the counter party (001) as per the Febelfin CODA rules.