Bank Integration

Bank integration means retrieving bank movements automatically and matching them to customer accounts and invoices. The goal is not to print a statement on screen but to let the system determine which collection settles which receivable.

Collections arrive from the bank, are keyed into accounting by hand, and the customer account is updated on another screen. Differences surface at month end and reconciliation is manual. That costs three things: delayed information, human error, and showing customers the wrong balance.

Movements are pulled from the bank on a schedule, and each is stored with a unique bank reference. If the same movement arrives again, that reference prevents a second record.

Matching runs through an ordered rule set: reference number first (where present), then description patterns, then amount plus date range. If no rule matches, the record lands in the unmatched list — it is never posted somewhere automatically. Hiding unmatched records is the most common mistake in reconciliation systems.

Commission, holds and value-date differences are not buried in the collection amount; they are recorded as separate lines. Otherwise the customer account closes short and the customer sees a wrong balance.

• Connection: account definitions, retrieval schedule, connection health monitoring.
• Parsing: splitting statement descriptions into fields, extracting payer details.
• Matching: rule set, priority order, partial and bulk collections.
• Difference handling: unmatched list, manual matching, recorded justification.
• Reporting: receivable ageing, cash projection, commission checks.

The channels banks offer (direct API, file-based transfer, or corporate online banking export), accounting and ERP, cash flow tracking, the dealer portal account screen, fintech infrastructure and retail POS end-of-day reconciliation.

On bank coverage: which banks can be connected by which method varies by bank and changes over time. We therefore make no "all banks" coverage claim; the banks to be connected and the method are listed at the start of the project.

• Bank credentials are not stored alongside application code.
• Every retrieval is logged: when, which account, how many records.
• Every manual match is recorded with the user and a justification.
• A dropped connection is not silent; a missing day raises a warning.

• Wholesale and dealer networks: automatic matching of collections from many customers.
• Retail chains: comparing bank POS totals with till totals.
• Subscription billing: tracking failed charges and retries.
• Group companies: several legal entities and accounts in one panel.

1. Scope: which banks, accounts, methods and latency tolerance.
2. Parsing and rules: description patterns and matching priority.
3. Pilot: run on one account and measure the match rate.
4. Roll-out: remaining accounts, reports and alerts.

Which connection method should be preferred?

It depends on the bank: a direct API gives the fastest feedback, while file-based transfer (MT940 and similar) is more widely supported. The choice follows the channel the bank offers and the latency tolerance required.

What match rate can we expect?

That depends on how consistent the statement descriptions are and varies by customer. We therefore commit to no figure; we measure it with real data during the pilot and build the rule set accordingly.

What if a collection is matched to the wrong account?

The match can be reversed, and the reversal leaves a trail. For that reason matching does not finalise the accounting entry directly; an approval step can be defined.