CAMT.053 instead of MT.940

Could it be that is just a matter of recognizing the file extension? In my case I have the same error but the file extension is xml. That type of file extension is not in the list of possible file extension whithin File Manager.

I think that is something to be resolved by the developper when a new format is added to the list of supported formats.

Yeah. Extension is the first issue but that’s easily solved. I can add xml extension to the list.

The bigger issue is that these exports can contain transactions for multiple bank accounts. I find this super convenient. But this means I will need to add new built-in field IBAN so when importing, Manager can correctly split the bank transactions in that file across all bank accounts.

I’m running v 22.8.30.345 and I can confirm that a CAMT.053 file from the Dutch bank Rabobank produces an error: “The file you are trying to import is invalid”.

Here is a link to their CAMT.053 specsheet (PDF).

It’s based on the “XML message for Bank to Customer Statement (camt.053) Implementation Guidelines for the Netherlands (PDF)


I have been using the MT940 Structured files up till now but they have never really work correctly.
A sample of the description looks like this:

  • /TRCD/003/BENM//NAME/BACHE RENE MONACO MCO/REMI/Betaalautomaat 10 00 pasnr. 124 Apple Pay NONREF
  • /TRCD/003/BENM//NAME/CHRISTIAN.DIOR MONACO MCO/REMI/Betaalautomaa t 18:27 pasnr. 124 Apple Pay NONREF
  • /TRCD/003/BENM//NAME/EXPL HOTEL SBM MONACO MCO/REMI/Betaalautomaa t 20:07 pasnr. 124 Apple Pay NONREF

It’s good enough for the bank rules to work but it’s not pretty :slight_smile:


Slight off-topic

For PayPal I’m downloading the CSV files but I have to heavenly modify them to be able to import them (at least I think so).
I presume there might be many people exporting from PayPal so it would be amazing if these files could be imported without having to work on them, but I might be wrong.

Hello, in my case (ASN bank) i didn’t get a error message. Alle the transactions were imported, but - the import does not detect that I already imported some payments on the start import date…

  • alle the amounts are wrong, instead of 17,50 it says 1750,–

Can some help?

I found out that when the xml code says:
<Amt Ccy**=** “EUR”> 15****

DBIT****

it is imported as 15,00 euro’s; which is right,

but there was another transfer which says:

<TtlAmt Ccy="EUR">14.44</TtlAmt>
                    <CdtDbtInd>DBIT</CdtDbtInd>
                </Btch>

and this is imported as 1444,00 euro’s; which is wrong.

So there is something wrong with the dot “.” , maybe it has to be a comma “,”

Then change to comma and see what happens when importing.

The format in the spreadsheet should match your numbers preference.

Hello,

I changed in the xml file the dot for a comma. It helped. Now the amount 14,44 was imported as 14,44 euro.

Tut says that the number preference should match te spreadsheet, but the xml is given by my bank. There by the number format which my bank account uses is not in the preferences. For example a big amount like thenthousend is presented as 10000.55 and not as 10,000.55. In the preferences there is no number format without dashes and commas for the whole numbers.

Before CAMT.053 my nymber format was 123456789,00 That is the one I want to use. So I think there is something wrong with the interpretation of the xml file. The dot has to be interpreted as a comma.

The imported file will be interpreted according to the number preference you have set in the program. If the bank statement uses a different format, you will have to modify with spreadsheet tools or a text editor to put it into the right format. This is one of the problems with importing bank statements. No one establishes or enforces rigid formats that users can depend on. Even the best standards are either highly flexible or are ignored by the banks. Banks have no incentive to produce a statement directly importable to any other program. In fact, they would rather keep you dependent on them.

Thank you for your reaction, but it isn’t very helpfull. It is not easy to edit the xml file. Because we are talking about a dot that has to be changed into a comma. A dot is in many places in the xml file, not only in numbers. It’s not a matter of simply search and change.

Besides I’m a simple user that do not have the knowledge to change a xml file with tools or codes or whatever.

Would it not be a solution to add to the preferences the number format:
123 456 789.00

That format is not supported yet.

In additon to my former post: my bank (ASNbank) descrisbes amounts of money exactly according the ISO standard 20022, which states:

• CurrencyAmount
The number of fractional digits (or minor unit of currency) must comply with ISO 4217.

Note: The decimal separator is a dot.

I just successfully imported this example CAMT.035 file from ING.My sample business has these settings:

image

EDIT: I used the 31-12-2022 date setting and the import was successful too. However, the above number format multiplies the amounts by 100. The amounts are only imported correctly when changing the format to 123,456,789.00

@HvS What version of Manager are you using? I tried the import in v22.9.1.350

I’ve did a test import using the latest 22.9.1.350 version of manager, and a copy of my company administration (so not a new/clean administration).
Normally, my settings are in Dutch (comma seperated), so ive changed them to dot seperated. When you change the number format, the import function works fine.

However, i noted that debited amounts where reflected in manager under credit transactions, and credited amounts under debit.

Just to verify, i also tested it using a fresh administration, but the issue (debit → credit) is still there.

Please explain exactly what you mean. (Many users confuse debit/credit terminology.) A bank deposit, for example, is a debit in your accounts, but is often thought of as a credit, because banks refer to transactions from their accounting perspective, in which a deposit to your account is a liability for the bank and, therefore, a credit on the bank’s books.

XML/CAMT.053 format is well-defined standard. It should import properly regardless of your date or number format preferences in Manager.

Therefore this is fault in Manager.

This issue will be fixed in the next version.

You are right, let me clarify what I mean.
An amount received on my bank account is reflected in manager as a payment from my account.

Looking at the CAMT file for a single transaction, it states that the “credit debit indicator” ( CdtDbtInd) is set at CRDT.
Knipsel1

This transaction is reflected in manager under a payment, although it is an amount received on my account

The issue is persistent for all transactions, so to me it seems that the import should be ammended to ensure that CRDT transactions go to “receipts” and “DBIT” are routed to “payments”.

When looking at the documentation for CAMT provided by the Dutch banking sector, it states the following for this field: "code CRDT is used if the value is zero or positive. DBIT is used if the value is negative.

@Ben80 I’d need to see your sample file that doesn’t import properly. Can you send it to me to lubos@manager.io ? Manager already understands CdtDbtInd so there is some other issue.

@lubos
Have sent file from RABO bank this morning by privat email
Manager updated to 22.9.1.350
Windows 10 Pro
rgds
Huib

edit error message ““The file you are trying to import is invalid””

I’ve send you the file via email. I’ve also tried a CAMT file from a different bank (ABN AMRO), and it had the same issue… If im the only user having this issue it must be related to my local settings in some strange way. On the other hand, I had no issue using the MT940 file format…