Bank payment reconciliation

“Every morning I open online banking and look for who paid which order. Then I issue the invoices by hand.” Anyone who sells with payment by bank transfer (UPN QR, Hub3, plain transfer) does this every day.

What changes

• The statement reads itself. CAMT.053 XML of any version and CSV. The module recognises format, character set and columns; if it cannot recognise the columns, you tell it once and it remembers.
• A preview before anything is written. You see how many credits the file has, how many duplicates and what would happen to each. Debits are not stored.
• It finds the order. By reference (SI00, HR00, RF or just the order number, also in the text of the transfer), amount, date and payer name. For every suggestion you see why the module suggests it.
• An invoice only when it is certain. Auto-invoice is off by default; turn it on after you have checked a few imports. The invoice is issued only if reference, amount and payment method match exactly one open order.
• Partial payments and overpayments. Payments for the same order are summed up and the invoice is created once the order is covered. An overpayment invoices the order amount, and you see the difference until you mark it as done.
• A payment for a canceled order. Its own state, no automatic changes. You decide: refund or a new order.
• Statements arrive by themselves. By upload, from a dedicated mailbox (no PHP IMAP extension, verified certificate) or from a server folder where your bank automation drops them.
• Careful with personal data. The payer’s IBAN is encrypted, source files are deleted after the time you set (14 days by default), the payer’s name is removed after the time you set (24 months by default), roles without the permission see the payer as “M**** N****”. The module is a controller's tool: you are the controller of the payers' personal data.
• No duplicates. You can upload the same file twice and statements can overlap: every payment is recognised and stored once.

How you set it up

In Stores › Configuration › Magelan › Bank reconciliation you enter the shop’s IBAN and pick the payment methods to reconcile. Then in Sales › Operations › Bank reconciliation › Upload statement you upload one statement and read the preview. The mailbox and the server folder can follow later. If you like, we do the first import together and check that your bank reads correctly.

Good to know

• The parsers follow public standards (ISO 20022 CAMT.053) and typical online-banking exports. They are tested on prepared sample files; we will publish the list of banks tested with real statements as soon as we have one. The preview shows what the module read before anything is written.
• Gmail and Microsoft 365 mailboxes usually need an app password or OAuth. We recommend a dedicated mailbox for statements.
• Flik and card payments are not on the bank statement and are not part of the module.
• The module itself does not stop the reminder or cancel modules from canceling an unpaid order before the money arrives; such a payment gets the state “Cancelled order” and waits for your decision. Once the invoice is issued, they no longer cancel the order.
• The module is not an archive of statements. Source files are deleted after 14 days (configurable, also at once) and the payer's name and IBAN are removed after 24 months (configurable); amount, date and the link to the order stay, and the invoice in Magento stays. Keep the original statements in your bookkeeping as the law requires (in Slovenia generally 10 years). Agree the anonymisation period with your accountant.
• Verified with real CAMT.053 statements from Delavska hranilnica and Intesa Sanpaolo (former Banka Koper): 900+ incoming payments, 780+ SI00 references recognised. Other banks and CSV exports follow ISO 20022 and common layouts and are tested with synthetic files.