In stores where customers pay by proforma invoice or bank transfer, the same task repeats every single day. Someone opens the bank statement, works down the rows, finds each payment among the orders, checks the amount and the reference, then manually issues an invoice in Magento. At ten payments a day that is half an hour. At a hundred payments it is somebody's entire job.
We kept running into this same task at several clients, so we built a module for it. Below is how the statement gets into the store, how the module links a payment to an order, and where its limits are.
How the statement reaches the store
Most banks can email the statement. The module connects to that mailbox over IMAP and checks every thirty minutes whether anything new has arrived. If it has, it picks the statement up on its own, with no click from you. The mailbox credentials are stored encrypted, and there is a button in the settings to test the connection before you leave it running.
If that approach does not suit you, or your bank does not send statements by email, you upload the file manually in the Magento admin. Processing is identical either way.
Two formats are supported. The first is CAMT.053, the ISO 20022 standard statement format that essentially every bank offers today. The second is CSV or Excel, where the module detects the delimiter itself and locates the columns for date, amount, reference and payer name. That matters for banks that format their exports their own way.
How a payment gets linked to an order
This is the heart of it, and also where manual work produces the most mistakes. The module tries three routes, in descending order of reliability, and assigns every match a confidence percentage.
- By payment reference. If the reference matches the order number and the amount agrees as well, the match is one hundred percent. If the reference matches but the amount does not, the module does not gloss over it and does not guess: it marks the match with lower confidence and sends it for review. That case is almost always a partial payment or a payment for the wrong amount, which is a decision for a person, not for a machine.
- By amount and date. When there is no reference, or it is wrong, the module looks for orders with the same amount around the payment date. You set how many days either side it may consider. The closer the date, the higher the confidence.
- By payer name and amount. The last resort, when the first two turn up nothing. Confidence is lowest here, because names on a statement and names on an order are often not written the same way.
The example is fictional.
The result is a list in the Magento admin showing, for each payment, which order it is linked to and how reliable that link is. Instead of going through the whole statement, you only look at what is not obvious.
When an invoice is issued automatically
Automatic invoicing is tied strictly to one hundred percent matches, meaning cases where both the reference and the amount agree. Everything else waits for you.
That is deliberate. An invoice is a document that goes to the customer and into the accounts, so we do not think guesswork should trigger it. If even that level is more than you want, switch automatic invoicing off and use the module purely for preparation, keeping the decision yourself.
The module emails you once a statement has been processed. You choose the recipients, so your accountant can receive the notification too, not only the person who runs the store.
What the module does not do
It is only fair to say this part too. The module is not accounting software and does not replace it. It deals with incoming payments that belong to orders in the store, not with your entire set of business records. Outgoing payments, payroll, costs and tax obligations are outside it and it does not touch them.
It also does not remove the need for a person. What it removes is the purely mechanical part, leaving you only the cases where something genuinely has to be judged: partial payments, payments with no reference, refunds, payments for orders that were cancelled in the meantime. In most stores those come up a few times a week, not a few times a day.
Who this makes sense for
It pays off most where payment by bank transfer is a meaningful share of revenue. That often means wholesale and B2B stores, stores selling higher-priced goods where buyers prefer a transfer over a card, and anyone working with public institutions, since those practically always pay against an invoice.
If nearly all of your payments run through cards and online payment providers, there is nothing to reconcile by hand and the module will not do much for you.
The module is already built and available. Details and pricing are on the Automatic bank payment reconciliation page. If you are not sure whether it is worth it at your volume, write to us and we will look together at how many payments you actually process in a month and where the time goes.
