background

Introduction

Tags:reconciliationafpuntenafletterenafpuntingreconciliatiemenu

Reconciliation is essential to determine whether customers have paid and whether payments are correctly registered in your accounting system. Twikey provides the tools to simplify this process as much as possible — both for clear customer communication and accurate backend processing.

Bank file formats: CAMT vs. CODA

When processing bank transactions, two common formats are used for reconciliation: CAMT.053 and CODA.

CAMT.053

CAMT.053 (ISO 20022 XML format) is a structured and highly detailed file format aligned with SEPA standards.
It provides:

  • Detailed transaction information
  • Payment statuses
  • Rejection reasons
  • References to original mandates or invoices

CAMT is ideal for precise tracking and reconciliation of payments.

CODA

CODA is a traditional format, mainly used in Belgium. It provides a clear transaction overview but includes fewer structured details compared to CAMT.053, especially regarding detailed rejection reasons or a complete transaction history.

Which one should you use?

  • If you operate across multiple European countries, CAMT.053 is recommended due to its broader support and structured format.
  • If you mainly work with Belgian banks and accounting tools, CODA may be sufficient and easier to integrate.
  • Some organizations use both formats to ensure compatibility with different financial systems.

Starting point : an invoice

Reconciliation usually begins with an invoice (or another payable item).

Example:
Customer Alice needs to pay merchant MyCorp an invoice for January:

  • Invoice number: 2020-0001
  • Amount: €100

To automate reconciliation, MyCorp includes a structured reference. While an internal reference also works, a structured message has the advantage that some banking applications validate it automatically.

Now, there are 2 parties involved that will look at the information provided by the bank from a different angle. We allow you to customize both offering you the best experience.

Customer perspective - Alice's story

Alice has lots of transactions on her account information. It's full of payments, but since she's very conscious of today's dangers of paying online she always carefully scans the transactions. So for Alice it would be good to know that the 100 euros she paid is for the January invoice of MyCorp. If she noticed a transaction of 100 euros without the proper info she could start calling her bank to reverse the payment causing MyCorp to bear the costs.

In Twikey, the message shown to the customer is called the Title.
This ensures transparency and reduces the risk of chargebacks or refund requests.

Best practice:

  • Avoid using only a number.
  • Use a clear description such as:
    • Invoice January
    • Invoice January – 2020-0001

Merchant faperspective - MyCorp story

MyCorp manages many customers and needs efficient automation to track payments internally.
For this reason, MyCorp sends its internal reference to Twikey via the Remittance field.

This reference allows:

  • Faster internal matching
  • Easier integration into accounting or ERP systems

How the Title and Remittance appear in bank information depends on the payment method used.

Payment methods and message usage

Customer (Alice) pays via Direct Debit

With Direct Debit, the transaction occurs directly between the merchant’s and the customer’s bank accounts.
In this case:

  • The Remittance is used on the bank statement.
  • If no remittance is provided, the Title is used.

Because this information appears on the customer’s account statement, it must clearly describe the payment information to avoid disputes.

Read here how to reconcile Direct Debit collections

When a customer pays via a payment link:

  • The Title is forwarded to the payment service provider (e.g. Mollie, MultiSafePay, Ingenico) as the description.
  • If supported, the Remittance is also forwarded, enabling you (MyCorp) to search for your internal reference in the PSP dashboard.

Read here how to reconcile payment links

Accounting and reconcilation tool

From the customer’s perspective, the Title ensures clarity, so everything should be clear from their point of view.

For the merchant however, this is just the start. In order to be sure that all transaction feedback is correctly processed into their backend the reference they provided earlier in the 'Remittance' field should now be provided into the feedback coming from Twikey.

The Remittance reference you originally provided is returned in the reconciliation feedback files generated by Twikey. These files can be generated and accessed via Reconciliation > Files menu

Matching menu

The Matching menu displays incoming payments that could not automatically be linked to an invoice or Direct Debit transaction.

Typical scenarios:

  • One payment covering multiple invoices
  • Multiple partial payments for a single invoice
  • Wrong details used while wiring the money
  • Payment done on an account unknown to Twikey
  • Wrong reference used
  • ...

Using this tool, you can manually reconcile payments to the correct invoice(s).
If a payment does not need to be linked (e.g. duplicate payment, non-customer payment), you can archive it.

Read here how to use the matching screen

Reconciliation files menu

The Reconciliation files menu allows you to :

  • Search
  • Generate
  • Download

CAMT.053 and CODA files for both Direct Debit transactions and payment links.

Read here how to generate the reconciliation files

Access rights

The matching and reconciliation files menus are only available to users with the Controller role.
See Users for information on managing user roles.

Last Update: 2025-12-22