How to Investigate Unmatched Bank Transactions

An unmatched bank transaction is a booked bank entry that has not been linked to the corresponding ledger entry, invoice, payment batch or other business event. “Unmatched” is a workflow status, not a diagnosis. The item may be valid, duplicated, incomplete, incorrectly recorded, or simply awaiting evidence.

The safest response is to classify and investigate it. Automatically assigning the nearest amount can close the wrong invoice and make the real problem harder to find.

Start with the source record

Capture the bank account, currency, signed amount, booking date, value date, transaction status, bank transaction identifier, debtor or creditor information, remittance text, bank transaction code and original payload or statement line. Do not edit this record during investigation. Store normalised names and references separately.

Confirm that the item is booked. A pending entry may change or disappear. Confirm that the import is complete and not duplicated before searching the accounting system.

Classify the exception

Useful categories include:

• missing ledger entry: a fee, interest item, receipt or payment exists at the bank but has not been posted;
• timing difference: the corresponding ledger item exists in another bank period;
• unapplied customer receipt: cash is recorded, but the paying customer or invoice allocation is not established;
• ambiguous allocation: several invoices or customers are plausible;
• duplicate: the same real transaction or ledger entry was loaded twice;
• reversal or return: the item reverses an earlier transaction;
• inter-account transfer: the opposite side is in another company account;
• processor settlement: supporting detail sits in a card, marketplace or payment-service-provider report;
• bank or counterparty query: the source itself may be incorrect or disputed;
• out of scope: valid transaction, but not part of invoice-to-payment matching.

Classification makes ownership clear. Accounts receivable may own an unidentified receipt; treasury may own a transfer; accounts payable may own a supplier debit; accounting may own fees and interest.

Investigation sequence

1. Check exact identifiers. Search transaction IDs, end-to-end references, invoice numbers and structured remittance fields in source systems.
2. Check lifecycle relationships. Look for pending-to-booked changes, reversals, chargebacks and returned direct debits.
3. Search accounting populations. Include recently posted and adjacent-period entries, not only current open invoices.
4. Validate payer identity. Compare legal names and known accounts, but recognise that group companies, payment agents and personal accounts can pay on a customer’s behalf.
5. Assess amount and currency. Consider partial, grouped, net-of-fee and overpayment scenarios without assuming them.
6. Obtain external evidence. Request remittance advice, processor settlement detail or customer confirmation when internal data is insufficient.
7. Record the conclusion. Link evidence, post an approved correction or allocation, and preserve the history.

Worked example

A €2,400 credit arrives from NORTHSTAR HOLDING with no invoice number. The receivables ledger contains two €2,400 invoices: one for Northstar France and one for another customer. Amount and date do not distinguish them.

The preparer finds that Northstar France’s customer master lists Northstar Holding as its parent, but that still does not prove the payment purpose. A remittance advice from an authorised customer contact identifies the invoice. Finance attaches the advice, records the payer relationship, allocates the receipt and documents the decision.

Without that advice, the receipt should remain unapplied under the organisation’s policy. Marking the most likely invoice paid would create unsupported evidence and could trigger incorrect collections activity against the other customer later.

Ageing and escalation

Age exceptions from the original booking date, not the date they were imported into a new tool. Define escalation based on risk, materiality and operational impact. A small unidentified receipt can still matter if it exposes systematic missing references or customer-credit obligations.

For each open item record:

• category and amount;
• owner and next action;
• evidence requested;
• last action date;
• target resolution date;
• accounting treatment, including suspense if policy permits;
• escalation status.

Suspense is a temporary accounting treatment, not resolution. Reconcile and age the suspense account itself.

Integration controls

Open-banking interfaces can expose date filtering, pagination and transaction status. Enable Banking documents these concepts in its API reference. Integration teams should test missing optional fields, delayed booked transactions, retries, identifier changes and overlapping fetch windows for each supported connection.

PSD2 enables regulated account-information access with consent, but does not ensure that every bank supplies the same narrative detail. See the European Commission’s payment services overview and the EBA’s PSD2 material.

In Invunion

Invunion alpha is focused on matching issued invoices to incoming bank transactions. An unmatched item may therefore mean no supported invoice candidate was found, or it may simply fall outside that scope.

Verify the current alpha’s available transaction fields, status handling, search, notes, ownership, correction and export features. Keep ambiguous items unmatched until evidence supports a decision. Continue to manage fees, supplier payments, transfers and full bank-to-ledger exceptions in the appropriate finance process unless current product support is expressly confirmed.

Sources

• Enable Banking, API reference
• European Commission, Payment services
• European Banking Authority, PSD2 interactive single rulebook

Updated 5 August 2026

Was this article helpful?

Feedback helps us improve the next version of this article.

Yes Not yet Tell us what is missing