Bank Integration in ERP: Matching Collections and Reconciliation
Where the real difficulty lies
The difficulty is not pulling the statement but matching: which account and which invoice does an incoming payment belong to? The description field is free text, the person sending the transfer is often not the debtor company, and a single payment can close several invoices. Success is measured by the automatic match rate and by how quickly unmatched items are cleared.
Four integration types, planned separately
- Statement retrieval: read-only, and the lowest-risk starting point.
- Payment instruction: write access, requiring authorisation, an approval flow and limit checks.
- Direct debit and supplier finance schemes: collection is delegated to the bank, with different reconciliation rules.
- Virtual POS / hosted payment page: takes customer payment online, with card-data scope assessed separately.
Treating all four as one "bank integration" item breaks both testing and authorisation design.
Practical ways to raise the automatic match rate
- A company-specific payment reference printed on the invoice, which the customer is asked to enter in the description. This single practice raises automatic matching more than anything else.
- Virtual account numbers per dealer or customer, so the sender is known without reading the description.
- Tax number or IBAN matching: link the sender IBAN to the customer record so matching becomes automatic from the second payment.
- Amount plus due-date combination: close automatically when exactly one combination of open invoices gives the amount, otherwise present it as a suggestion.
Unmatched items should land in a queue whose age is monitored — the waiting time of the oldest item matters more than the queue length. How collection data feeds the cash forecast is covered in the [cash flow guide](/en/blog/cash-flow-tracking-guide).
Duplicates and repeated retrieval
Statements are pulled several times a day. Store the bank's unique reference for each movement and do not create a new record when the same reference arrives again. Where the bank issues no reference, use a composite key of date, amount, counterparty account and sequence number.
Authorisation and approval
For integrations that send payment instructions, the authorisation model must be designed before the technical connection: who can create an instruction, who approves it, above which amount a second approval is required, and whether an approver may approve their own instruction. These rules belong inside the ERP, with every step logged.
What the reconciliation output should look like
The daily report has three sections: automatically matched, suggested, and unmatched. It should also show which rule produced each match — without a visible rule you cannot diagnose an incorrect one.
Frequently asked questions
How often should statements be retrieved?
Several times a day is enough at low collection volume. Where dealer payments release blocked orders, frequency must increase, because delay turns directly into waiting orders.
Can one payment close several invoices?
Yes, and the data model must support it from the start with a many-to-many matching table between a collection record and invoices. A model built on a single-invoice assumption breaks on partial payments.
How does exchange rate affect matching?
A foreign-currency invoice settled in local currency will not match exactly. Define an acceptable variance band and the account the difference is posted to in advance, otherwise every payment is closed by hand.